The Review Bottleneck

A team adopts AI coding tools and, by every generation-side signal, it works. Engineers report finishing more tickets. Pull requests open faster and in greater numbers — the branch list on a Monday morning looks like a team twice the size. Leadership asks for the payoff in the metrics that are supposed to prove it: lead time for changes, deployment frequency, the DORA numbers on the quarterly review deck. Those numbers do not move. Not down, which would at least be a clear signal of something broken — just flat, stubbornly unchanged, as if the extra output evaporated somewhere between "opened" and "shipped."

This is not a measurement artifact and it is not a sign that AI coding tools underdeliver. It is one of the cleaner findings in the AI-assisted engineering literature, and it deserves more than the passing mention it got in Chapter 1: the speed did not disappear. It moved.

The finding

A 2025 analysis spanning more than 10,000 developers across 1,255 teams found that AI-assisted teams completed about 21% more tasks and opened nearly twice as many pull requests — roughly 98% more. Those are exactly the numbers a generation-side dashboard would show off. The same dataset found delivery metrics essentially unchanged and code review time up about 91%. Two engineers reviewing each other’s AI-assisted work were, on average, spending nearly double the time they used to spend, for a system that was supposed to be making everyone faster.

Read as a single number, "91% longer reviews" sounds like a regression — reviewers getting slower, or the review process degrading. Read as a system, it is closer to conservation of a bottleneck. Generation used to be the slow, expensive part of building software: writing the code took real developer-hours. AI made that part cheap. The theory of constraints has a blunt answer to what happens when you speed up a non-bottleneck step: the bottleneck does not vanish, it relocates to whatever was the next-most-constrained resource in the pipeline. In most software organizations that resource is human attention — specifically, the attention of the people qualified to verify that generated code is correct, safe, and consistent with the rest of the system. That attention did not get any more elastic just because the code arrived faster.

Why the code that arrives fast does not review fast

It would be a cleaner story if AI-generated pull requests were simply larger in volume but equivalent in quality per line — more of the same good code, just faster. The developer-sentiment data says the code is not equivalent. In the 2025 Stack Overflow Developer Survey, 66% of developers named AI output that is "almost right, but not quite" as their single biggest frustration with the tools — ahead of hallucinated APIs, ahead of security concerns, ahead of everything else on the list. And 45.2% of developers said debugging AI-generated code takes more time than debugging code a human wrote, not less.

"Almost right" is a uniquely expensive failure mode for a reviewer, because it does not announce itself. Code that is obviously wrong gets rejected in seconds — a missing import, a syntax error, a test that fails in CI before a human ever opens the diff. Code that is almost right passes the fast filters and requires the slow one: a person reading it carefully enough to notice the off-by-one in the edge case, the exception handler that swallows the wrong error, the refactor that quietly changed a default. That is exactly the kind of reading a reviewer cannot skim. It is plausible, on its face, that a meaningful share of the 91% is exactly this — not more pull requests requiring the same scrutiny, but pull requests that individually demand more of it, because the failure mode generation shifted toward is the one verification is worst at catching quickly.

The queuing evidence points the same direction independently. A 2026 benchmark spanning more than 250,000 developers across sixty-plus enterprises found AI-generated pull requests waiting roughly 4.6 times longer to be picked up for review than human-written ones, even as the time to open a PR fell sharply — reviewers were not simply slower per diff, they were structurally deprioritizing a growing pile of AI-authored work. Early academic research on the problem finds a similar shape from the other direction: a large sample of agent-authored pull requests splits into a tail that merges almost instantly and a much smaller, disproportionately expensive tail that consumes most of the review effort — a rough empirical fingerprint of the "almost right" pattern reviewers describe. There is a parallel, corroborating signal in code quality itself: large-scale repository analysis has found rising duplication and a shrinking share of refactoring commits since AI adoption accelerated — methodology contested, but if the direction holds, it means a reviewer’s diffs increasingly do not map onto a familiar existing pattern, which is its own tax on review speed independent of any single bug.

The economic argument

Chapter 6 argued for cost per outcome as the unit that matters, and warned that measuring only the generation side of a session produces a misleadingly favorable picture. The review bottleneck is the pipeline-level version of the same warning. A dashboard that reports tasks completed and pull requests opened, without a paired figure for review time, will show unambiguous acceleration — and it will be true, and it will also be a fragment. The full pipeline runs from prompt to merge, and a team that only instruments the front half of that pipeline is measuring the part that got faster while remaining blind to the part that absorbed the gain.

This connects to a pattern named in Chapter 2: engineers can genuinely feel faster while the organization’s net cycle time has not improved at all. Individually, writing the code is less effortful — the drafting labor an engineer used to do personally now happens in the AI session, and that reduction in personal effort is real and reportable. But if the same or a smaller pool of reviewers absorbs nearly double the review load with the same tools and the same attention span, the organization has not gotten faster. It has redistributed the labor from the person who used to write the code to the person who now has to read it, and the person doing the reading is often the more senior, more scarce, more expensive engineer on the team. That is not obviously a win even before accounting for the quality risk of a rushed review.

Generation-side metrics vs. verification-side metrics

The practical fix starts with instrumenting both halves of the pipeline on purpose, not by accident. The two columns below are not competing metrics — they are the numerator and the denominator of the same question, and a team that reports only the left column has answered a different, easier question than the one it thinks it answered.

None of the right-column metrics are exotic. Most already exist in a team’s pull-request history and issue tracker; they are simply not on the same dashboard as the left column, and dashboards that are not built for a question tend not to get asked it. The instrumentation gap here is closer to Chapter 1’s than it looks: the token bill was cheap to measure and got measured obsessively, while cost per outcome required joining two systems and mostly did not happen. Review time is the same story with different systems — PR-open counts are cheap and visible, review-hours-per-merge requires joining the same two systems and mostly does not happen either.

What a review-bottleneck-aware team does differently

1. Report review time next to PR count, always, on the same chart. A throughput number without its verification cost beside it is an incomplete claim, not a conservative one.
2. Treat reviewer attention as the constrained resource it is. Adding more AI-generated pull requests without adding review capacity does not create speed — it grows a queue, and a growing queue is a hidden cost that does not show up until it becomes a missed deadline or a rushed approval.
3. Watch for the "almost right" failure mode specifically. A review process built for occasional human error is not automatically tuned for a steady stream of plausible-looking, subtly wrong diffs — the checklist a team used pre-AI may not catch what AI-generated code tends to get wrong.
4. Measure end-to-end lead time, not stage-by-stage speed. A faster generation stage feeding a slower review stage can leave the number that actually matters to users and stakeholders — time from request to shipped change — completely unchanged, which is exactly what the DORA-adjacent data shows happening across the industry.

The open question

One proposed fix deserves an honest hedge rather than a confident recommendation: shifting some review effort to AI-assisted review itself, using a second model to triage or pre-screen pull requests before a human looks at them. It is a coherent idea — if a model can catch the obviously-wrong cases at the same low cost it catches them in generation, human attention could concentrate on the "almost right" cases that actually need it. But it is also, structurally, LLM-as-judge evaluating LLM-as-generator, and this volume has not seen evidence rigorous enough to say whether that arrangement reduces the bottleneck or merely relocates it one more stage downstream, to whoever has to double-check the AI reviewer. This book does not have a settled answer here. Early researchers studying the human side of the problem describe reviewers falling back on surface heuristics — trusting confident-sounding AI output, or applying the same review posture they used for human colleagues — that do not obviously transfer to a fundamentally different source of errors; that alone is a reason for caution about outsourcing the judgment to another model. Treat any tool or vendor claiming a clean solution to the review bottleneck with the same skepticism this chapter has applied to generation-side throughput claims — and measure it, on both sides of the pipeline, before believing it.