When agents write the code, review becomes the bottleneck

A team adopts coding agents and the first month is remarkable. Tickets that took two days take two hours. Everybody is enthusiastic and the velocity chart supports it.

Around the second month something changes. Pull requests are larger. Reviews take longer and get shallower. A defect appears in an area nobody remembers deciding anything about. The velocity chart still looks good, which is part of the problem.

The arithmetic nobody does

Generation got roughly an order of magnitude faster. Review did not, because review is a human reading code and forming a judgement about whether it is right.

If a team could produce and review four changes a day, and can now produce forty, review capacity is unchanged. The options are to review four properly, forty superficially, or somewhere in between while telling yourself it is fine.

Most teams pick the third and do not notice, because superficial review looks identical to real review in every metric that gets collected.

What under-reviewed generated code looks like

Plausible and subtly wrong. Generated code is idiomatic and well-structured, which suppresses exactly the surface signals reviewers use to decide where to look harder.

Locally correct, globally inconsistent. Each change is sensible on its own. Twenty of them introduce three different ways of doing the same thing, and nobody saw all twenty.

Untested in the way that matters. Tests were generated alongside the implementation, from the same understanding, so they assert what the code does rather than what it should do.

Unowned. Nobody can explain why it works, because nobody decided anything — they approved something.

Treating review capacity as the constraint

The practice that works is unexciting and mostly about limits.

Cap the size of generated changes. Small enough to review properly. If a change cannot be made small, that is a signal about the specification rather than about the tooling.

Every change traces to a specification. Reviewers read intent and acceptance criteria first, then check the implementation against them. Reviewing a diff with no stated intent is proofreading.

Write tests from the specification, not from the implementation. Independently, ideally before. Otherwise the test suite is a mirror and approves of whatever it sees.

Measure review, not generation. Changes reviewed per day, and how long each took. If generation throughput is rising and review throughput is flat, the gap is accumulating somewhere.

Keep an unreviewed backlog visible. If it grows, generation slows down. That rule is unpopular for a week and saves a quarter.

Where the speed actually comes from

Not from writing code faster. From the distance between deciding what should be different and having it working — which shortens dramatically when implementation stops being the constraint, and only if the constraint that replaces it is managed rather than ignored.

That is the whole premise of spec-driven development: the specification becomes the artefact under review, review capacity is what the pipeline is sized against, and the accountability for what merges stays exactly where it was.