What code review has to catch once an agent is writing the code

Once an agent writes the code, what arrives at review changes. It nearly always compiles, nearly always passes lint, and often arrives with tests attached. A reviewer walking in with the old habits — hunting a typo, commenting on a variable name — will read the change, find nothing, and approve it.

The problems have moved up a layer. They are no longer in the line but in the structure: why is this a new file, why was a library added, and why does the case we discussed in the meeting appear nowhere. Those questions need familiarity with the system, which is why on a project where an agent writes a lot, an experienced reviewer becomes more critical rather than less.

The four questions that replace the old review

What worked for us was abandoning line-by-line reading in favour of a short list of structural questions. It is faster and it catches more.

1. Does something here already exist in the system under another name? The most common failure, because an agent cannot know what it has not seen.
2. Was a dependency added, and what does it save? Twenty lines does not justify a package somebody maintains for years.
3. Are the cases agreed in the meeting handled — especially failure states, which tend to disappear when they were not asked for explicitly.
4. Do the tests assert behaviour or merely execute the code? A test that calls a function and checks no error was thrown is not a test.

The fourth surprised us most. An agent generates tests happily, and they look convincing — until you read them and find they cover the lines without asserting a single business rule. High coverage that states nothing is worse than low coverage, because it manufactures confidence with nothing under it.

Why duplication is problem number one

A developer writing a new component feels friction: they remember something similar, go looking, find it, and extend it. An agent feels nothing. If it is not told where the existing pattern lives, it will produce a new one that works perfectly — and a month later the same behaviour turns out to be defined in three places.

The effective way to reduce that is not review but what precedes it: a short conventions file describing where things live and what already exists. For us that did more than any amount of writing better instructions for an individual task, because it gets read on every task afresh.

What about large changes?

Reviewing a two-thousand-line change is an inspection nobody genuinely performs, and that was true when humans wrote them too. The difference is that an agent produces such changes far more easily, which makes discipline about task size more important rather than less.

The rule we adopted is simple: define a task so its output can be reviewed in one sitting. If the output exceeds that, it is a sign the task was two tasks. We set out the gate and the process around it in our piece on working with an agent in a team.

The comparison is not a loose metaphor. In both cases production cost collapsed, in both cases volume jumped, and in both cases what decided the outcome was whether a gate existed to determine what passed. The only difference is that in code the gate is the build, the tests and the review — and all but the last can be run automatically.

And code the agent wrote a month ago

There is a whole layer nobody reviews: code that passed review at the time and that nobody understands today. This happens with human code too, at a lower rate, because whoever wrote it remembers something. When an agent wrote it there is nobody to ask — the only memory left is what went into the commit message and the tests.

The practical consequence is that commit messages and tests matter more, not less. A message explaining why a change was made, rather than only what changed, is frequently the only documentation that survives. We require it in review, and it is one of the changes that paid for itself fastest.

What no longer needs reviewing

Some things are worth ceasing to comment on, because a machine does them better. Formatting, import order, simple naming conventions — all of that belongs to a tool rather than to a person's time. A review full of such comments trains the team to skim comments, and that is precisely when the one that matters arrives.

If you are weighing which tool to adopt, we have a comparison of Claude Code and Cursor. But the decision that matters more than the tool is what exactly counts as a finished task, and that is the team's decision rather than the vendor's.