Why did code review become the slowest step in delivery?

Because production capacity rose while review capacity stayed the same, and a queue forms wherever an increased input meets an unchanged one. Reading a change with real understanding takes about as long as it always did, so the same reviewers now face several times the volume.

How can you tell whether the review queue is your constraint?

Measure the time between a change being opened and being merged, split by size, and watch it alongside change failure rate. A rising wait with a stable failure rate means you are throughput-limited, and a stable wait with a rising failure rate means changes are being approved without genuine reading.

Why does a slow review step stay invisible for so long?

Because the queue takes on the extra volume without producing any alert, and the obvious metrics keep looking fine. Approval rates stay high, throughput charts keep rising, and the only early signal is a slow increase in how long the median change waits, which almost nobody tracks.

Does adding more reviewers fix the problem?

Rarely, because the people qualified to review are the same senior people already doing specification and incident response, so adding reviewers usually means moving them off other constrained work. It also raises coordination cost, which is the mechanism behind Brooks's law and applies to review as much as to production.

Should large changes be rejected automatically?

Yes, and enforcing it with a bot rather than a guideline is what makes it work. Review quality falls with size, so a change too large for any reviewer to understand all at once has effectively skipped review no matter who clicked approve.

What does an agent-opened pull request need that a human one does not?

A written statement of intent: what was asked for, what approach was chosen, what was deliberately left out, and where the reviewer should look most carefully. Without the author available to answer questions, the reviewer has to infer the requirement from the implementation, which reverses the purpose of review.

How do automated checks shorten the review queue?

They remove whole categories of work from the human reviewer, so attention goes to intent and consequences rather than to formatting, null handling, or errors that are obviously being hidden. The checks have to be written from the specification rather than from the code, because a suite generated from the implementation passes automatically because of how it was made.

What review work should never be automated?

Whether the change should exist, whether it matches what was actually asked for, how much breaks when it fails, and what is missing that nobody would notice was missing. A check verifies a rule someone thought of, and it cannot notice a rule nobody thought of.

Does batching reviews into set times help or hurt?

It helps the reviewer's own focus and hurts the queue if the batch window is long, so the useful compromise is two fixed slots a day rather than one. What genuinely fails is treating review as something to fit around other work, because it then always loses to other work when time is planned.

Is a longer queue always bad?

A short queue is not free either, since driving it to zero usually means reviewers dropping their own work the moment anything arrives. The problem is an uncontrolled queue that nobody measures, because that is the state where the fastest-approved changes are also the least examined.

What is the first thing to change when the queue is already long?

Cap change size and require a statement of intent, because both are cheap to introduce and take effect immediately. Building automated verification is the lasting fix, but it takes weeks, and the two size and intent rules give you the time to do it properly.

The review queue is the new bottleneck: Reveneau

For most of the history of software delivery, the constraint was writing the code. Every process we built assumed it: estimation, sprint planning, capacity models, hiring plans. The whole structure of a delivery team was designed around production being the slow part.

Production is no longer the slow part. The bottleneck, meaning the step that limits the speed of everything else, is now the queue of changes waiting for a human being to read them, and that queue is the least measured thing in most engineering organisations.

The queue stays hidden for about a quarter

This is what surprises teams, and it is worth understanding the mechanism rather than just the outcome.

A review queue does not fail in an obvious way. It has no alert. It takes on additional volume by getting longer, and getting longer produces no visible symptom for weeks. Meanwhile every metric a leadership team actually looks at improves: more pull requests opened, more merged, higher throughput, good-looking velocity.

Then somewhere in the second or third month the problem becomes clear. The median change has been sitting for four days. Engineers are context-switching back into work they finished last week. And the changes that got approved quickly turn out to be the ones a tired reviewer approved without checking, because a queue creates pressure to clear it and clearing it means reading less carefully.

That is the specific failure: the fastest-moving work becomes the least examined work, and it happens quietly.

Three things that make the queue worse than the raw volume suggests

Review quality falls with change size, and nobody rejects a change for being large. A reviewer facing eight hundred lines reads the final two hundred materially worse than the first two hundred. Everyone knows this. Everyone approves anyway, because rejecting a change on size alone feels obstructive and the author has already done the work.

Intent is missing when an agent wrote it. Review has always been a conversation with someone who made decisions and can explain them. When a model produced the diff, there is no one who knows the reasoning, so the reviewer reconstructs the requirement from the implementation. That is exactly the work review was supposed to avoid, and it is slow.

Tidiness stopped being evidence of care. Experienced reviewers are fast because they recognise signs of carelessness: inconsistent naming, a function doing four things, a comment that disagrees with the code beneath it. Generated code applies the same clean style to the part that was carefully specified and the part that was invented. The tool that made review fast no longer works, and most reviewers have not noticed it. We wrote about this at length in why AI-generated code fails code review in a different way.

What the research supports and what it does not

Be careful here, because this is an area where confident claims go further than the evidence.

The 2025 DORA report, drawn from around 5,000 respondents with 90 percent using AI at work, found AI adoption relating positively to software delivery throughput and negatively to delivery stability. Its summary line is that "AI doesn't fix a team; it amplifies what's already there". A team whose review process was already the constraint gets more volume arriving at the same constraint. That is amplification working exactly as described.

The same report found 30 percent of respondents reporting little or no trust in AI-generated code. Stack Overflow's 2025 survey puts it more strongly still: 46 percent actively distrust the accuracy of AI output, 66 percent name output that is "almost right, but not quite" as their biggest frustration, and 45.2 percent say debugging generated code takes longer than writing it themselves. Low trust plus almost-right output leads to slow review specifically. A reviewer who does not trust the source reads more carefully, which is correct behaviour and which costs time.

What the research does not show is a clean measurement of queue length across the industry, so treat the specifics of your own situation as something to measure rather than assume.

Four changes, in the order they give results

Cap change size, mechanically

Not a guideline. A rule enforced by a bot, with a documented exception process that requires someone to say why.

This is unpopular and it is the item on the list with the most effect, because every other improvement is defeated by a two thousand line diff. If the work genuinely cannot be split, that is important information and it is better to have it before the code is written than after.

The secondary benefit is that it changes how work gets planned. A team that knows large changes will be rejected starts decomposing at the design stage, which is where decomposition is cheap.

Require intent on every change

The description has to supply what an absent author would: what was asked for, what approach was chosen, what was deliberately not done, and what the reviewer should look at most carefully.

We treat a missing rationale as a reason to stop the merge, in the same way as a failing check. It sounds bureaucratic. It takes about ninety seconds to write and it removes the slowest part of review, which is the reviewer guessing at the requirement.

Move everything mechanical to a machine

A human should never be checking formatting, obvious null handling, or whether an error is being hidden silently. Those are machine jobs and a machine does them perfectly at any volume, at three in the morning, on the four hundredth change of the month.

Every minute a reviewer spends acting as a linter is a minute not spent on whether the change should exist. Most teams have done half of this and stopped.

Build verification that can actually fail

This is the lasting fix and it is the one that takes weeks rather than days.

Automated checks written from the specification, covering what the software must guarantee: authentication and permissions, anything that moves money, anything that writes or deletes customer data. Once those exist, a reviewer can accept generated work without reading every line, because the properties that matter are being asserted by something that does not get tired.

The mistake is generating the checks from the code. A suite written by reading the implementation asserts that the code does what it does, passes automatically because of how it was made, and shows passing results that mean nothing. The method is in writing specs an agent can verify and the list of failures is in when evals give false confidence. The simple test: break something on purpose and confirm the suite notices.

What review is for once machines do their part

Narrow the human job deliberately and it gets better rather than worse.

Should this change exist at all. Does it match what was actually asked for. How much breaks when it fails. What did somebody decide here that no test could encode. What is missing that nobody would notice was missing.

That last question is the entire argument for keeping people in the review. A check verifies a rule someone thought of. It cannot notice a rule nobody thought of, and no amount of coverage changes that.

Why hiring more reviewers usually fails

The instinct when a queue is long is to add more reviewers. It rarely works here, for two reasons.

The people qualified to review are the same senior people doing specification, incident response, and design. Moving them into review moves the slow step rather than removing it. And review capacity is subject to the same coordination penalty as anything else: Brooks's law describes adding people to a late project making it later, and a review process with eight people in it develops queueing behaviour of its own about who takes which change.

The version that does work is raising how much each reviewer can safely accept, which is what the fourth change above gives you. Our fuller treatment of the sizing question is in how to size a team when generation is cheap, and the guide version is in why adding engineers can slow you down.

Measure it, starting this week

Two numbers, tracked together, tell you almost everything.

Time from opened to merged, split by change size. And change failure rate in production. A rising wait with a flat failure rate means you are throughput-limited and the queue is the real limit. A flat wait with a rising failure rate means changes are being approved without being read, which is worse and much harder to see.

Neither number requires new tooling. Both are in your version control system already, and almost nobody looks at them.

Thanks to the teams who let us look at their queue data and were honest about what it showed. In every case the throughput chart looked fine and the waiting-time chart, which nobody had drawn before, had been climbing for a quarter.

Making code faster to write moved the wait to a place nobody was watching, and software reached production no faster.

Related guide: How to review AI-generated code.

Sources

2025 DORA report announcement, Google Cloud: around 5,000 respondents, 90 percent using AI at work, 30 percent reporting little or no trust in AI-generated code; positive relationship with throughput and negative with delivery stability.
Stack Overflow 2025 Developer Survey, AI section: 46 percent actively distrust accuracy; 66 percent name "almost right, but not quite" as their biggest frustration; 45.2 percent say debugging generated code takes longer.
Brooks's law: adding people to a late software project makes it later.

The review queue is the new bottleneck