Code Review Is the Bottleneck Now: Median Time in Review Rose 441.5%

Generation capacity has outrun review capacity. Faros AI telemetry across 22,000 developers shows task throughput up 33.7% while median time in pull request review rose 441.5%. The code review bottleneck is now the binding constraint on engineering velocity, and it is a workflow problem rather than a headcount problem. Review is where AI speed either converts or evaporates.

Where the bottleneck actually moved to

For thirty years the scarce resource in software was people who could write correct code. That is no longer the scarce resource on most teams.

The scarce resource is now the judgement required to decide whether a change is safe to merge. Generation is close to free. Verification is not, and verification did not get cheaper when generation did.

This matters because a bottleneck does not announce itself. It shows up as a queue, and a queue looks like normal work until you measure how long things sit in it. Your dashboards will show more pull requests opened, more commits, more activity. None of that is throughput.

My view, stated plainly: most engineering organisations adopted AI generation in 2025 and 2026 without changing a single line of their review process. That is the whole story. The tooling on one side of the pipeline changed by an order of magnitude and the tooling on the other side did not change at all.

The evidence that review, not generation, is the constraint

Two independent datasets published in 2026 point at the same place. They were collected differently, from different populations, and they agree on direction.

Faros AI: output up, review time up far more

Faros AI published The AI Engineering Report 2026 in April, drawing on two years of telemetry from 22,000 developers across more than 4,000 teams. Task throughput per developer rose 33.7%. Epics completed per developer rose 66%.

The review side moved differently. Median time to first review rose 156.6% and median time in review rose 441.5%. Code churn rose 861%. Incidents relative to pull request volume rose 242.7%.

Read those two groups together. A 34% gain in output bought a 441% increase in the time work spends waiting to be judged. That is not a productivity gain with a side effect. That is a bottleneck.

LinearB: the merge rate collapse

LinearB analysed 8.1 million pull requests from 4,800 teams across 42 countries, published in May 2026. The headline for a manager is the merge rate. Unassisted pull requests merged within 30 days at 84.5%. AI-generated ones merged at 32.7%.

Size explains part of it. At the 75th percentile, AI-assisted pull requests ran past 400 lines against 157 for unassisted work, roughly 2.6 times larger. Refactoring share at the same percentile fell from about 37% to close to zero, so the extra lines are new surface rather than tidied surface.

Why machine-written code costs more to review, not less

The intuitive expectation is that AI-written code should be easier to review. It is idiomatic, it is well named, it has comments, and it usually compiles. Every one of those properties makes review harder.

Almost right is the most expensive failure mode

Stack Overflow surveyed 48,904 developers in 2025. The leading frustration with AI tools, named by 66% of respondents, was solutions that are almost right but not quite.

That phrase is the whole review economics problem in six words. Obviously wrong code is cheap to reject. Correct code is cheap to approve. Code that is plausible, well formatted, and subtly wrong forces the reviewer to reconstruct intent from scratch.

Surface quality signals no longer correlate with correctness. A reviewer who learned to skim for smells is now skimming past the defects, because the smells were removed and the defects were not. This is the same trust gap that shows up in tool adoption data, covered in the analysis of developer trust falling while usage rose.

The author cannot answer the important question

Human review has always relied on a conversation. The reviewer asks why a decision was made, and the author explains the constraint that produced it.

With generated code that conversation often fails. The author did not make the decision, so there is no reasoning to recover. The reviewer is left auditing an artefact with no accessible design rationale, which is closer to reading a stranger's legacy code than to reviewing a colleague's work.

Size compounds this. A 400 line diff with no stated intent is not one review. It is a small archaeology project, and it lands in a queue alongside twenty others.

The failure nobody logs: review that never happens

The dangerous number in the Faros data is not 441.5%. It is 31.3%, the rise in pull requests merged with no review at all.

That is a capacity failure presenting as a policy. Nobody wrote it down. Reviewers hit a queue they could not clear and the organisation quietly redefined what counts as reviewed.

Academic work points the same way. Researchers at Nicolaus Copernicus University analysed the AIDev dataset of agent-authored pull requests on GitHub and published the results at EASE 2026. They found that most AI-generated pull requests receive no review, and that when review does happen it is largely dominated by AI agents rather than humans.

Their warning is the one engineering managers should take seriously. Human involvement now often appears as steering an agent rather than as standalone evaluation. So review metrics stop being a reliable indicator of human oversight. If your governance story rests on a review count, that story may already be hollow.

Google's 2025 DORA report, drawn from nearly 5,000 technology professionals, frames the same mechanism from the delivery side. AI adoption now correlates positively with throughput and still correlates negatively with stability. Their explanation is that AI amplifies whatever control systems already exist. A team with strong automated testing and fast feedback gets faster. A team without them gets faster at producing instability.

Four changes to a review workflow built for machine-written code

Everything above is diagnosis. Here is what I would actually change, in the order I would change it. None of these require buying anything.

1. Cap the diff, and enforce it at the pull request

The single highest-leverage constraint is size. LinearB's data puts AI-assisted work at 2.6 times the size of unassisted work, and review quality falls off a cliff as diffs grow.

Set a hard cap. 200 changed lines is a defensible starting point for application code, with generated migrations, lockfiles, and vendored dependencies excluded from the count. Anything over the cap needs a named exception or gets split.

The behavioural effect matters more than the mechanical one. A cap forces the author to decide what a change is about before opening it, which is the step generation tools let people skip.

2. Require a review brief, written by the human

Make the pull request description a short structured brief the author writes themselves. Three fields is enough: what changed, why this approach, and what you are least sure about.

The third field is the important one. It restores the design conversation that generated code removes, and it tells the reviewer where to spend attention. A reviewer who knows the author is unsure about the retry logic will read the retry logic properly.

Reject briefs that were obviously generated from the diff. A summary of what the code does is worthless to a reviewer who can read the code. Intent is the scarce input.

3. Route by blast radius, not by round robin

Most teams assign reviewers by rotation or by code ownership. Neither accounts for risk, so a copy change and a payment path change get the same treatment.

Route instead on two axes: how large the diff is and how much damage the touched code can do. Low risk and small gets a machine pass and an author merge. High risk and large does not get reviewed at all, it gets sent back to be split. That is not bureaucracy, it is the only way a finite reviewer pool survives an infinite generation pool.

4. Put machines on the first pass and humans on the last

Automated review is good at the class of defect that is mechanical and local. Style, obvious null handling, missing error paths, dependency issues, and common security patterns. Let it clear those before a human opens the file.

Keep humans on the things machines cannot judge: whether the change should exist, whether it fits the architecture, and whether the tests actually test the behaviour that matters. This division is closer to the real capability boundary described in the gap between benchmark scores and real repository work.

What AI reviewers can and cannot take off your plate

The obvious response to a review bottleneck is to point more AI at it. That helps, within a boundary worth naming before you buy.

Independent measurement of this category is thin and very new. Martian, a research lab, published an open benchmark that watches real open-source pull requests and asks whether a developer changed the code after a tool commented on it. Acted-on comments is a far better proxy for value than comment volume, and it is the right question to ask a vendor.

What the category is genuinely good at is breadth and patience. A machine reviewer reads every line of a 400 line diff at the same attention level, which no human does at 5pm on a Friday. It never skips the boring file.

What it cannot do is decide whether the change should exist. It has no access to the commercial context, the deprecation you agreed last quarter, or the fact that this service is being retired in March. Approving the wrong feature quickly is not a fix. That distinction sits behind the wider argument in the three separate scoreboards for AI coding tools.

There is also a noise ceiling. A reviewer who learns that most comments are not worth reading stops reading all of them, including the correct ones. So the metric to hold a review tool to is the share of its comments that produced a code change, and you should be prepared to turn off rule classes that fall below your threshold.

The numbers that tell you whether it worked

Most engineering dashboards measure the wrong side of this pipeline. Commits, pull requests opened, and lines changed all rise when generation improves, whether or not anything ships.

Four measurements actually answer the question. Take a baseline before you change the workflow, because without one you will not be able to tell.

All four are available from standard git and issue tracker data. None require a vendor platform, though a platform makes the cohort split easier.

Where this argument is weakest

Three genuine problems with the case above, stated before someone else states them.

First, the source base leans on vendor telemetry. Faros AI and LinearB both sell engineering analytics platforms, and both benefit commercially from a narrative in which engineering measurement is urgent. They publish sample sizes and methodology, which is more than most, and their customer bases are not random samples of the industry. Teams that buy engineering analytics are already teams with a measurement problem. Treat the direction as strong and the magnitudes as directional.

Second, the strongest experimental evidence is now dated. METR's randomised controlled trial found experienced open-source developers were 19% slower with AI tools while believing they were 20% faster, across 16 developers and 246 tasks. That is 16 developers, which is small, and METR itself now labels the result historical because the tools have moved. Anyone citing it as current evidence, including people who agree with me, is overreaching.

The case that this is a transition cost

The honest counter-argument is that review debt is temporary. Teams learned to write for other humans over decades. They have had about two years to learn to review machine output, and the practices are visibly immature.

On that reading the 441.5% is a spike, not a plateau, and it compresses as review tooling improves and as teams internalise habits like diff caps. I think that is partly right. What it does not explain is the merge rate collapse, which is a signal about the work itself rather than about reviewer skill.

What would change my mind is a dataset showing median time in review falling on teams with high AI adoption while merge rates hold. Nobody has published that yet. If you have it, publish it, because it is the most useful missing number in this debate.

Frequently asked questions

Where to start this week

Pull two numbers from your own repository history before you change anything. Median time in review for the last quarter, and the share of merged pull requests with zero review comments from a human. Both are a short git query away.

Then pick one repository, not the whole organisation, and set a 200 line cap with a named exception path. Run it for four weeks and compare the same two numbers. If time in review does not move, the constraint is somewhere else and you have learned that cheaply.

Related reading