Review the intent, not just the code the agent produced

A tech lead at a fintech company described a review that passed every bar and still turned out to be a mistake. An engineer had asked an agent to add caching to a slow endpoint, the agent proposed a caching layer, the engineer accepted it, and the reviewer checked the implementation carefully. The cache was correct. The invalidation was correct. The tests were solid. What nobody asked was whether caching was the right fix at all. The endpoint was slow because of a missing database index, and the cache was now hiding a data-freshness problem that surfaced a month later as customers seeing stale balances.

The review checked the answer, not the question

Traditional code review is good at one kind of question. Is this code correct, is it clear, does it handle the edge cases, is it maintainable. Those questions all assume the change should exist. They evaluate the execution of a decision that was made before the review started.

Agents shift where decisions get made, and that breaks the assumption. When an engineer asks an agent to solve a problem, the agent often proposes an entire approach, not just an implementation. It picks the strategy. The engineer, moving fast, accepts the strategy and moves to the code. By the time the change reaches review, a real architectural decision has already been made, silently, by a tool, and the review process was built to check implementations, not decisions. So the reviewer does an excellent job on the wrong layer. They confirm the cache is well built and never ask whether caching was the right call.

This is a genuinely new gap. When a human proposed an approach, there was usually a conversation, a design note, a moment where the decision was visible and could be questioned. An agent proposes an approach inside a single work session, and the decision can pass into the codebase without anyone treating it as a decision. The intent went unreviewed because it never looked like something that needed reviewing.

Make the approach visible before the code

The lesson is that review has to reach up a level when agents are proposing approaches, and check the decision, not only the diff. The question is not only “is this code good” but “is this the right thing to build, and why did we choose it over the alternatives.”

What teams do to review intent, not just implementation.

Ask the author to state the approach and why they chose it, so the decision is visible and can be questioned before the code is judged.
Surface the alternatives the agent did not take, since the fastest path is not always the right one.
Review architectural choices as decisions, in design, before an agent turns them into a large change that is expensive to unwind.
Separate “is this well built” from “should this exist,” and make sure someone answers the second question.
Keep a person accountable for the approach, not just the implementation, so there is an owner for the decision the agent made.

The code being good is necessary. It was never the whole review, and with agents making more of the decisions, the part that got skipped is the part that costs the most to get wrong.

How we approach it at Density Labs

The expensive AI-assisted mistakes we see are rarely bad code. They are good code implementing a decision nobody reviewed, because the decision got made inside a work session and arrived disguised as an implementation. The reviewer did their job on the layer the process pointed them at, and the layer that mattered was one above.

When we help a team set up their AI-assisted workflow, we make the approach a reviewable artifact, separate from the code. The engineer says what they are going to do and why before the agent builds it, so a bad approach gets caught while it is still a sentence and not two hundred lines.

Reviewing the code tells you it was built well. Reviewing the intent tells you it should have been built at all.