Coding got faster. Delivery didn’t. That gap has a name: the Verification Bottleneck. The constraint has moved from producing changes to confirming them, and review is where it lands.
For decades, writing a change took longer than reviewing it. That imbalance is one corner of a wider strain in verification capacity. The argument runs in four parts: cause, magnitude, mechanism, and the boardroom case. By the end you’ll be able to explain, with numbers rather than intuition, why faster code generation made delivery slower, and how to frame the fix.
Why did code review become the bottleneck the moment coding got faster?
Code review became the bottleneck because AI collapsed authoring time while verification stayed human-paced. Unattended coding agents open pull requests faster than senior reviewers can substantively confirm them, so the queue now backs up at the human gate, and that’s the constraint your team hits first. Review was never the constraint before because authoring was slower than reviewing; that ordering has now inverted.
The volume doesn’t come from inline autocomplete. It comes from agentic coding, unattended agents that generate code, commit and open the pull request on their own. A human builds a mental model of the code while writing it; an agent’s reviewer has to reconstruct that model after the fact.
Across 300 million work events at 700+ firms, AI agents raised lines of code by 30%, commits by 20% and pull requests by 23%, while Jira issue resolution barely moved. Output climbed, delivery didn’t.
Michael Fagan’s 1976 IBM inspections assumed changes arrive at a human pace, in a bounded size, with enough hours at the gate to read them. That design assumption is what no longer holds.
How much have PR size, review latency and unreviewed merges actually moved under high AI adoption?
Under high AI adoption, AI-Generated Pull Requests wait roughly five times longer for a first review than human-written ones. PR Size and Files Touched trend upward, and Unreviewed Merges have become routine. The figure compares agentic PRs with human-written work at the same point in time, so it measures queue position and change size.
Review Latency is the time from ready-for-review to the first substantive human response, narrower than cycle time, which spans far more than the review itself.
Agentic pull requests wait 17.6 hours at the 75th percentile for pickup, against 3.4 hours for unassisted work, a five-fold gap. The tail is what blocks delivery, which is why P75 matters more than the average. It’s one of the numbers your team should be tracking before you conclude anything about AI productivity.
Three movements, tracked separately. PR Size and Files Touched drifted up: Faros found average PR size up 51.3% and files per PR up 59.7% under high AI adoption, a proxy for reviewer cognitive load. Median time to first review rose 156.6%, and Unreviewed Merges, changes reaching the main branch without a substantive human approval, rose 31%, the clearest sign the human gate has stopped functioning. What happens to reviewers when volume outruns capacity follows from there.
The chain runs one way: agentic coding produces AI-Generated Pull Requests, which arrive larger and stretch Review Latency. DORA Delivery Stability shows throughput tracking up with AI adoption while stability does not, so throughput alone overstates delivery. That’s how the six pieces fit together.
One caution. Faros, DORA and Salesforce define “high AI adoption” differently: pipeline agent usage across 22,000 developers, self-reported survey intensity, one firm’s internal experience. Blending them into one “AI productivity” number is a category error. They’re enterprise-skewed proxies whose direction is consistent, but their magnitude isn’t a law for a smaller team.
The queue is longer now, and the changes sitting in it are harder to clear. Here’s why.
Why is AI-generated code harder to review than bad human-written code, even when it looks cleaner?
AI-generated code is harder to review because it fails silently. Bad human code fails legibly: it is clumsy, inconsistent, obviously incomplete. Plausible AI code is idiomatic, well-formatted, confidently commented, and wrong in a way you can only see by holding the whole change in mind. Reviewers triage by anomaly, and clean-looking code removes the signal.
Most bad code used to announce itself: clumsy naming or broken convention pointed reviewers straight at the problem. AI removes that signal. The failures sit beneath the surface: misunderstood requirements, plausible edge cases, logic that solves a nearby problem. Stack Overflow’s 2025 survey found 66% of developers describe AI output as “almost right, but not quite”. Almost right is the category that hides defects.
Volume multiplies the load. Correctness isn’t local: a change touching twelve files demands cross-file reasoning that a 200-line human diff rarely did. That’s PR Size and Files Touched acting as a cognitive-load multiplier. Verifying code you did not write is harder than writing it, because the mental model that authorship would have built has to be reconstructed afterwards.
Machine review enters the argument here as a bounded tool: automated review can catch certain mechanical classes of defect and leave senior hours for intent, design and risk.
How should I frame the review-capacity problem for the board when the ask is headcount?
The case to make is buying back verification capacity at a known cost per unit, against the unknown cost of unreviewed change. It lands on the metrics your board already tracks: change failure rate, escaped defects, time-to-market, incident cost. In that framing, headcount is one of four levers, with the other three cheaper to test.
Boards fund risk reduction and delivery predictability, and reviewer headcount reads as a cost line unless it’s tied to those outcomes. Review Latency maps to time-to-market; Unreviewed Merges map to change failure rate and escaped defects. Faros found incidents per pull request more than tripled under high AI adoption, a number to set beside any claim that unreviewed change is free.
Three objections come up, and each has an answer. “The tools will fix it”: capability is real but bounded. “The team should just review faster”: that’s the exploitation trap. “We shipped more, so it worked”: DORA Delivery Stability, covered above, says otherwise.
So headcount is the last of four levers to cost. Context engineering, machine review for mechanical defects, and risk-based governance matched to blast radius are cheaper to pilot than hiring, and they add no permanent fixed cost. The three cheap levers come first; the hiring case is whatever gap remains after them.
Faster code generation didn’t remove the bottleneck; it moved it. Authoring collapsed while verification stayed human-paced, and that separation is permanent until verification itself is re-engineered. “Just review faster” can’t be the answer, because silent failure defeats the anomaly signal reviewers rely on: clean-looking code hides its errors, and speed without understanding produces shallow approvals.
The decision your board faces is to pay a known cost to buy back verification capacity, or carry the unknown cost of unreviewed change. Headcount is one lever among four, and the cheaper three are worth testing first. The full map of what replaces review sets out how the four levers sequence against each other.
Frequently Asked Questions
Is code review slow because there aren’t enough reviewers?
Not primarily. Headcount is the visible symptom, but the cause is that authoring sped up while verification stayed human-paced. A team can add reviewers and still lose ground if agents keep opening larger pull requests faster than anyone can read them. The constraint moved from producing changes to confirming them, which means the fix is verification capacity, not simply more people reading diffs.
Does the 4.6 times longer wait prove AI-generated code is worse?
No. The figure compares AI-generated pull requests with human-written ones at the same point in time, not against an earlier baseline, so it captures queue position and change size as well as difficulty. It shows that AI-generated work waits longer for a first substantive response, not that it contains more defects. Treat it as evidence of a strained review queue, not a verdict on code quality.
What counts as an unreviewed merge?
An unreviewed merge is any change that reaches the main branch without a substantive human approval. That includes self-merges, approvals from a bot, and approvals given before later commits changed the diff. Teams define it differently, so measure the version that matters: changes merged with no human response, or with an approval that no longer matches the code. That count is the cleanest signal the gate has stopped working.
Will AI code review tools clear the backlog on their own?
No. Automated review is useful for mechanical classes of defect, but it does not absorb accountability, and it adds its own noise when precision is low. Tools can shorten the queue for the changes they handle well; they cannot confirm intent, product fit or architectural judgement at the volume agents now produce. Expect them to reduce load at the margin, not to replace verification capacity.
What can automated review catch, and what still needs a human?
Automated review is strongest on things a machine can verify: style, known vulnerability patterns, missing tests, unsafe API use and obvious logic errors. It is weakest on intent, trade-offs, product behaviour and whether the change belongs at all. The practical split is to let machines clear the mechanical layer so senior reviewers spend their hours on design and risk. Treat tool output as evidence, not approval.
Do smaller engineering teams see the same bottleneck, or is this an enterprise problem?
Smaller teams tend to feel it sooner, even though the published datasets skew large. With fewer senior reviewers, there is less slack to absorb a burst of agent-generated pull requests, and one person’s leave can stall the queue. The direction of the effect is consistent; the magnitude is not well measured below enterprise scale. Treat the figures as a warning, not a benchmark for a 50-person team.
Is the bottleneck temporary while teams adjust to the new tools?
No, not on current evidence. The inversion is structural: authoring time collapsed, verification remains human-paced, and better models do not restore the hours senior reviewers have in a week. Teams can adapt their process, but the gap persists until verification itself is re-engineered. Expect the pressure to ease only where review load is actively reduced, not because the industry is still adjusting.
How do I know whether review is genuinely our constraint?
Look for work waiting at the gate rather than at authoring. If pull requests sit ready-for-review while engineers wait, if the queue grows without a matching rise in headcount, and if reviewers spend their week context-switching between diffs, review is the constraint. Analyse where work stalls: authoring speed staying flat while latency climbs is the confirmation. If work waits on requirements or environments instead, review is not your bottleneck.
What is the senior engineer tax, and how do I spot it?
The senior engineer tax is the hidden cost of routing more review to the people whose judgement you can least afford to spend on triage. It shows up as review load concentrating on a handful of staff, design and mentoring time disappearing, and first-response times stretching while those reviewers look busy. Faros AI’s data points the same way, with time to first review up sharply as AI-generated volume rose. Watch who reviews, not just how many reviews happen.
What review latency should we be targeting?
There is no universal benchmark, so set the target by change risk. A workable default is a first substantive response within one business day for routine changes, and same-day for anything touching authentication, payments or customer data. Track P75 rather than the average, because the tail is what blocks delivery. Do not target near-zero: it rewards shallow approvals and pushes the cost downstream into incidents.
How do I put a cost on an unreviewed merge?
Start with the incidents you can trace back to changes that shipped without substantive review, then add the rework, rollback and customer impact. Divide that total by the number of unreviewed merges in the same period to get a cost per merge. The figure will be rough, but a rough cost beats an unknown one in a board paper. Use your own incident data, not vendor averages.
Should we just require a human approval on every merge?
A blanket rule without capacity produces rubber-stamping, not assurance. If reviewers are already over capacity, mandatory approval becomes a click, and the queue grows behind it. The stronger approach is risk-based: define which changes genuinely need human sign-off, make that review substantive, and measure the rest. Policy can force a signature; it cannot manufacture the attention behind it.
