Code Review When Most Code Is Agent-Written

Review practices were built around assumptions about the author: that they had a reason for each choice, that they understood the surrounding system, that a mistake would be idiosyncratic rather than systematic. Agent-written code violates all three, and the review checklist that worked before is now aimed at the wrong things.

What changes about the defects

Style and structure stop being findings. Generated code is generally idiomatic and well-formatted. Comments about naming and layout — a large share of traditional review comments — now catch almost nothing.

The bugs that survive look correct. An agent doesn't produce the obviously-wrong code a tired human does. What it produces is locally correct code resting on a wrong assumption. Those pass a skim, which is what most review under volume amounts to.

Errors are systematic, not idiosyncratic. A human makes one mistake in one place. An agent applies the same wrong pattern in twelve places consistently — which makes it harder to spot, because consistency reads as intent.

The author can't be asked why. "Why did you do it this way?" is the most valuable review question and there's no one to ask. The reasoning either arrives with the change or doesn't exist.

The questions worth asking now

Traditional review asks is this code good? That's mostly answered by tooling. The questions that earn attention:

Does this solve the actual problem? Not the ticket — the problem. Generated code is a faithful implementation of a specification that may have captured the wrong intent, and review is the last stage where that's catchable.

What did it not consider? The edge case nobody wrote down, the caller three modules away, the customer on the legacy plan. Absence is the characteristic defect, and absence doesn't appear in a diff.

Is this consistent with where we're going? A change that fits current conventions perfectly and contradicts next quarter's direction is a defect only a human with the roadmap can see.

Should this exist at all? ⚠️ Cheap generation means more code gets written, including code that shouldn't. "This adds a configuration option we'll support forever to solve a problem one customer has" is a review comment that matters more now than it used to.

Is the complexity load-bearing? Where the agent simplified something, was the thing it removed a workaround for a real problem?

Practices that need to change

✅ Require reasoning with the diff. The agent should state what it chose, what it considered, and what it's least sure about. That last field is the highest-value line in the PR — it points the reviewer at the risk directly.

✅ Automate everything mechanical, without exception. Every check a machine can do is attention returned for the questions above. This was good practice before; it's the difference between a working review process and a rubber stamp now.

✅ Review against the requirement, with the original request attached. Not the ticket as written — the original request. That's the only way to catch a specification error at review time.

✅ Cap the reviewable unit. Small, single-purpose diffs. Volume went up; per-diff attention has to hold, which means diffs get smaller.

✅ Sample the systematic patterns. For a repeated change across many files, review three instances properly and verify mechanically that the rest match. Reading all fifty badly is worse than reading three well.

❌ Stop commenting on style. It's noise, tooling handles it, and it consumes the attention budget the real questions need.

🔍 The metric that tells you review is failing

Time-to-approve, tracked against diff size. If approval time falls while diff size holds, scrutiny is dropping — and it drops silently, because a fast approval looks identical to a confident one.

The complementary number: defects found post-merge versus in review. A shift toward post-merge means review has become ceremonial, whatever the approval rate says.

💡 The capability problem underneath

Reviewing agent output well requires understanding the system deeply enough to notice a plausible-but-wrong change. That understanding comes from having built and debugged things.

If the building is increasingly delegated, the pipeline that produces good reviewers gets thinner — and reviewers are the constraint. There's no clean answer to this. Teams that notice it and deliberately keep people doing hands-on work, for the capability rather than the output, are making a defensible bet.

The takeaway

Review shifts from is this code good to is this the right change, and what did it miss. Automate every mechanical check, require the agent to state its reasoning and its uncertainty, attach the original request so specification errors are catchable, keep diffs small, and sample systematic changes rather than reading them all. Then watch time-to-approve — because the failure mode isn't reviewers rejecting more, it's reviewers approving faster.