What code review becomes when most code is generated
Review was designed for a world where writing code was slow and expensive. Both halves of that assumption have broken, and the ritual has not been redesigned to match.
Code review is the most successful process ritual our industry has ever adopted. In twenty years it went from a practice associated with NASA and safety-critical software to something a two-person startup sets up on day one without discussion. It is close to universal, it is rarely questioned, and it is now quietly failing in a way that most teams are experiencing as fatigue rather than recognising as a design problem.
The failure is not that review does not work on generated code. It is that review was built on four assumptions, all four are now false, and nobody rewrote the ritual.
The four assumptions
Writing was expensive, so review was cheap by comparison. A change that took a day to write took twenty minutes to review. That ratio is what made review economically obvious. When a change takes four minutes to generate and still takes twenty minutes to review, review is no longer a small tax on production, it is the production process, and it is being performed by the most expensive people you have.
The author understood the change. Review was a conversation between two people who both had a model of the code, one of whom had just built it. “Why did you do it this way?” was a question with an answer. When the author is an agent, or a human who prompted an agent and skimmed the result, that question has no reliable answer, and a large fraction of review’s value came from the answer.
Volume was self-limiting. No individual could produce more than a few changes a day, so review load per reviewer was bounded by the number of humans on the team. That bound is gone. Review load is now bounded by nothing except how many changes people choose to initiate.
Reading the diff was sufficient. A small diff by a colleague who understood the system could be assessed by reading it. A large diff produced quickly by something that is locally plausible and globally uninformed cannot be, because the errors are not in the lines, they are in the relationship between the lines and everything not in the diff.
What review assumed
- Writing is slow, review is a small tax
- The author can explain their reasoning
- Volume is bounded by headcount
- The diff contains the risk
- Reviewers are the scarce good
What is true now
- Writing is fast, review is the whole cost
- Often nobody can explain the reasoning
- Volume is bounded by nothing
- The risk is in what the diff does not show
- Reviewer attention is the only scarce good
What people are actually doing about it
Three responses are common. Two of them are bad and the third is incomplete.
Reviewing everything, more shallowly. The default. Nobody decides to do this; it is what happens when volume rises and nothing else changes. It preserves the appearance of governance and destroys the substance, which is the worst combination available, because the organisation now believes changes are reviewed. The measurable symptom is approval latency going down while defect escape rate goes up, and almost nobody watches those two numbers together.
Reviewing nothing, on the grounds that the tests pass. Rarer, more honest, and defensible in narrow contexts. It works where the test suite genuinely encodes correctness and the blast radius is small. It fails badly the first time something is wrong in a way the tests were never designed to notice, which is most of the interesting failures.
Having another model review it. Increasingly popular and genuinely useful for a specific class of problem: mechanical mistakes, missed edge cases, inconsistency with local convention. It is not useful for the question review actually exists to answer, which is whether this change should exist at all. A second model has no more access to intent than the first one did. Two systems with the same blind spot agreeing with each other is not verification, and treating it as such is how teams build confidence they have not earned.
The incomplete answer is the third one, and completing it requires deciding what review is for.
Separating the four jobs
Review, like most durable rituals, is doing several unrelated jobs at once under a single name. Volume forces them apart, and separating them is most of the work.
Once you see them separately, the design becomes obvious in outline. Push correctness and consistency in front of the human, so no person ever looks at a change that fails a check a machine could have run. Reserve human attention for appropriateness. Then deal with knowledge transfer deliberately, because it is the one that vanishes without anyone noticing.
That last point deserves more than a clause. In a team of six, review was how everyone stayed roughly aware of the system. Nobody put that on a list of benefits; it was a by-product. Now: sixty changes a week, review triaged by risk, most changes seen by no human at all. The by-product is gone. Six months later nobody can explain the notification subsystem because no human read the fourteen changes that built it. This is a slow-acting and expensive failure, and the teams I have seen handle it well do something explicit about it, usually a weekly session where someone walks the group through what changed in an area, chosen for interest rather than risk.
Risk-tiered review
The practical mechanism is to stop treating changes as interchangeable. Not all changes deserve the same attention, and pretending they do is what makes uniform review unaffordable.
Low blast radius, criteria verified
Merge on green. A human reading this is a waste of the scarcest input you have.
Low blast radius, criteria weak
The problem is the criteria, not the change. Fix the criteria, then the first box applies.
High blast radius, criteria verified
Human review, focused on appropriateness only. Correctness is already established.
High blast radius, criteria weak
Full human review and a conversation about why this path has no encoded expectations.
Blast radius is estimable without much sophistication: which paths were touched, whether they are on the auth or payment or data-deletion surface, whether the change alters a public interface, whether it touches migration code. A crude version of this classifier outperforms uniform review immediately, because uniform review is not a policy, it is the absence of one.
The uncomfortable part is that this requires someone to write down which parts of the system are dangerous. Teams resist this, partly because it feels arbitrary and partly because the list is embarrassing. It is still the highest-value document most teams do not have.
What good human review looks like now
When a change does reach a person, the questions worth asking have changed. Reading the diff line by line is mostly wasted effort, because line-level problems are exactly what tooling catches. The questions that remain are the ones tooling cannot reach.
Should this exist at all? A surprising share of generated changes are competent solutions to problems that should have been declined. The agent is not going to push back on the premise.
What is not in the diff that should be? Generated changes are systematically weak on the thing that had to change elsewhere: the migration, the feature flag, the documentation that is now wrong, the other caller that makes the same assumption.
What does this assume that is not stated? Generated code frequently encodes an assumption about ordering, uniqueness, or timing that is true today and undefended. These assumptions are invisible in the diff and cause incidents eighteen months later.
Is this the shape we want copied? Everything merged becomes training material for the next generation, in the practical sense that agents imitate the repository. A mediocre pattern merged once will reappear thirty times. This raises the cost of “fine, ship it” considerably.
Where this breaks down
Risk classification is a judgement, and it will be wrong. Something classified low-risk will cause an incident, and the response will be to reclassify everything as high-risk, which returns you to uniform review with extra machinery. Surviving the first bad miss without over-correcting requires senior air cover and an honest post-incident conversation about expected loss rather than blame.
Machine-checkable correctness is only as good as the criteria. All of this leans on criteria being strong enough that “verified” means something. In practice criteria quality varies enormously across a codebase, and a tiering system built on weak criteria is a confident lie. If you cannot say how good your criteria are on a given path, you cannot safely tier that path.
Knowledge transfer is easy to promise and hard to sustain. Every team I have seen adopt a weekly walkthrough has kept it for about two months. It is the first thing cut under pressure, and its absence is invisible for a long time before it becomes catastrophic.
Some regulated environments require human review by rule. Where a control says a human approved a change, tiering is not available regardless of whether it would be better engineering. The honest move is to say so and to focus effort on making that review fast and well-informed rather than pretending the constraint is negotiable.
The takeaway
Review is not obsolete. It is overloaded, and it is being applied uniformly to a population of changes that is no longer uniform.
The redesign is not complicated to state: let machines establish correctness and consistency before a person is involved, spend scarce human attention on whether the change should exist in this system in this form, tier by blast radius rather than treating everything alike, and rebuild knowledge transfer explicitly because it used to arrive free and no longer does.
If you take one thing into next week: look at the last thirty changes your team merged and ask how many needed a human at all, and then ask whether the ones that did got the attention they deserved. In most teams both answers are uncomfortable, and they point in opposite directions.
The next piece looks at quality assurance, a function that was widely predicted to disappear twice already and which is about to become more important than it has been in a decade.