Of all the numbers 2026 has produced about programming with AI, there is one that appears in no sales deck: pull requests merged with no review at all, neither human nor automated, are up 31.3%. The figure comes from Faros AI, across two years of telemetry from 22,000 developers in more than 4,000 teams. Over the same period, bugs per developer rose 54% and the ratio of incidents to pull requests more than tripled.
The easy reading is that people have become careless. The useful reading is different: review is not being skipped out of negligence, it is being skipped because the process asks for something that can no longer be given. When three times the changes arrive, each twice the size, and the person sending them cannot explain them any better than you can, review stops being a control and becomes a queue. And queues, under pressure, drain through the cheapest exit: approval.
This piece is not about reviewing faster. It is about the fact that reviewing generated code is reviewing something else, and about what has to change in the process when the author stops existing as a counterpart.
First, the serious objection
It is worth dealing with before building anything on top, because if it holds, half the industry is optimising the wrong place.
In June 2026, GitLab published a survey with The Harris Poll of 1,528 developers and technology buyers across six countries: 85% agree that AI has moved the bottleneck from writing code to reviewing and validating it. 78% say their developers write and commit faster since adopting AI, and 79% endorse what the report calls the paradox: individual productivity improved, overall delivery did not keep pace.
Steve Fenton, in July 2026, disputes the entire premise. His argument is that coding was not the bottleneck before and review is not the bottleneck now, and he offers a test you can answer in a minute: on the system you work on, how many changes have passed review and are still not deployed and enabled for users? If that number is well above zero, the constraint is not review — it is downstream. His signpost is batched deployment: on his data, 92% of teams deploy in batches and only 8% deploy changes independently. Accelerating code generation with AI, without touching that, produces bigger batches, not earlier delivery.
Fenton is right, and none of what follows contradicts him. They are measuring two different things and both matter:
What the data says, and whose data it is
Before the table, a note on provenance that is almost never made and that here changes how much weight each figure carries. Much of the available data on this is published by companies selling engineering analytics or code security tooling. That does not disqualify it — these are the only large longitudinal series that exist — but it is not peer review, and selection bias in their customer base is real. I flag it in the last column.
| What was measured | The number | What kind of source |
|---|---|---|
| Volume and defects | Epics per developer +66%; bugs per developer +54% (against +9% the previous year); incidents per pull request +242.7%; merges with no review at all +31.3% | Vendor telemetry (Faros AI, 22,000 devs, 2 years) |
| PR size and wait | AI-assisted PRs: over 400 lines at the 75th percentile against 157 for unassisted ones; around 16 hours waiting for a first reviewer against just over 3; acceptance rate 32.7% against 84.5% | Vendor telemetry (LinearB, 8.1 M PRs, 4,800 teams) |
| Shape of the code | Code movement from refactoring: 21% in 2022 → 3.8% in 2026. Copy-paste: 9.4% → 15.7%. Block duplication +81%. Cross-file calls −35% since 2023 | Vendor telemetry (GitClear, 623 M changes) |
| Security of what is generated | 55% of samples pass security testing — flat over two years — with over 95% syntactic correctness. By language: Python 62%, Java 29%. By flaw: XSS 15%, log injection 13% | Vendor benchmark (Veracode, 80 tasks, 150+ models) |
| Delivery stability | 90% use AI at work and over 80% believe it raised their productivity; 30% report little or no trust in the code it generates. AI adoption correlates positively with throughput and negatively with stability | Broad-sample research (DORA 2025, ~5,000 professionals) |
| Reported experience | 66% run into "solutions that are almost right, but not quite"; 45.2% say debugging generated code takes them longer. 32.7% trust its accuracy against 45.7% who distrust it | Open survey (Stack Overflow 2025, ~33,000 responses in the AI section) |
Six independent measurements pointing the same way: more throughput, the same or worse quality, and less effective review
The convergence is what makes it interesting. GitClear and LinearB share neither methodology nor customers, and both find the same thing by different routes: refactoring disappears. In GitClear, code movement falls to 3.8%; in LinearB, the refactor rate of AI-assisted pull requests is close to zero against 37% for unassisted ones. When two telemetries with different biases agree on direction and order of magnitude, the signal holds more weight than either one alone.
The four assumptions that broke
Modern code review settled across the industry around a simple idea: two people look at a change, one explains it and the other asks questions. All the value is in the conversation, not the form. And that conversation rests on four assumptions that held on their own until 2024.
1 · That there is someone to ask why
This is the assumption holding up all the others. "Why did you do it this way?" was the most productive question in a review because it had an addressee: someone had weighed alternatives and discarded several. With a generated change, that person may not exist. Whoever opened the pull request looked at an output and thought it seemed fine, which is exactly what the reviewer is about to do. The readers doubled and the author disappeared.
The practical effect: review slides from catching design problems to catching surface problems. And surface problems are precisely the ones the generator no longer makes.
2 · That writing costs more than reading
The whole economics of review depended on this asymmetry. Writing two hundred lines took an afternoon; reading them, twenty minutes. That is why it was reasonable for one person to review the work of several. When generating those two hundred lines drops to ninety seconds while reading them still takes twenty minutes, the ratio inverts and the system jams where it was never designed to jam. LinearB's wait figures — from three hours to sixteen for a first reviewer — do not describe slower reviewers: they describe the same reading capacity against multiplied throughput.
3 · That diff size reflects decision size
A large pull request used to mean an important change, and therefore deserved more attention. Now a four-hundred-line diff might be a trivial decision expressed generously, or three serious decisions buried in scaffolding. Size stopped being a signal, and with it went the heuristic teams used to allocate review effort.
4 · That new code resembles the code already there
A developer who has spent a year in the repository reuses without thinking: they know that validation already exists. A generator, whatever its context window, tends to solve the problem in front of it by writing it again. Hence GitClear's most uncomfortable finding: in 2026 block duplication is up 81% against 2023, and calls to functions in other files — the best cheap indicator of reuse — are down 35%.
And this is what no diff-based review can see. A duplicated block is impeccable inside its own pull request. It is only a problem in relation to something in another file, which the reviewer does not have open, and which they often do not know exists. Code review is structurally blind to the dominant failure mode of generated code.
The perception trap
Here comes the most uncomfortable source in this piece, and it deserves telling with all its limitations because it gets cited very badly.
In July 2025, METR published a randomised controlled trial with 16 experienced open-source developers, across 246 real tasks in their own repositories — averaging over 22,000 stars and more than a million lines — using Cursor Pro with Claude 3.5/3.7 Sonnet. Before starting, participants forecast that AI would make them 24% faster. The measured result was that they took 19% longer. And the part that makes it more than an anecdote: after completing the tasks, they still estimated AI had made them 20% faster.
The limitations are substantial and the authors write them out themselves: the sample is small, these are repositories the participants knew intimately, the tooling is from early 2025, and METR now labels the result historical without claiming it describes current workflows. It cannot be used to argue that AI makes people slower. None of those limitations, however, touches the finding that matters here:
This explains the number this article opens with better than the negligence hypothesis does. A team approving quickly is not being careless: it is applying an intuition calibrated over years about how long someone takes to write something and how much care reading it deserves. That intuition has lost its basis, and like every broken intuition, it fails silently and confidently. It is the same mechanism that makes the ROI of Copilot and Cursor get measured where it is not: you ask people whether they feel faster instead of looking at what reaches production and what comes back.
What the generator does not review about itself
The market's reflex answer is to put an automated reviewer in front. It is a good idea badly sized, and Veracode's data explains why.
In its 2026 update — 80 coding tasks, four languages and over 150 models evaluated over time — syntactic correctness exceeds 95% while the security pass rate sits at 55%, and that second figure has been essentially flat for two years. Models have improved enormously at writing code that works and not at all at writing code that cannot be exploited. The breakdown is more eloquent than the aggregate: Python passes 62% and Java 29%; and by flaw type, log injection passes 13% and cross-site scripting 15%, against 82-86% for SQL injection and insecure cryptography. Not even the most recent releases move the needle appreciably, with the partial exception of reasoning models at around 70-72%.
The operational conclusion is not "don't use automated review". It is that automated review is strongest exactly where generated code is already strong, and shares blind spots with the generator. It works as a first pass over long diffs and as a replacement for the linter. It does not work as the last link before merging, for the same reason filters cannot be the last link before an irreversible action: a high detection rate is good news for the cost of the error and a poor basis for a guarantee.
And there is a second-order effect worse than the technical one. An automated reviewer visible on the pull request creates the sense that someone has already looked. The 31.3% rise in merges with no review at all in Faros's telemetry is consistent with that: it is not that the machine reviews badly, it is that its presence reads as permission not to look.
What changes in the process
None of what follows requires new tooling or stopping delivery. These are changes to the contract between whoever opens a pull request and whoever approves it.
| The change | Which broken assumption it repairs | How you know it works |
|---|---|---|
| Hard size ceiling, returned unread | That size is still a signal. Splitting stopped being expensive: the cost of generating was what made the large PR reasonable | 75th percentile of PR size stable month over month, not growing |
| The PR arrives with the spec it was generated against | That an author exists. If nobody can explain the why, the why has to be written beforehand and separately | Review comments cite the spec, not just lines |
| Review by declared risk, not by lines | That the diff reflects the decision. The author flags what touches money, personal data, permissions or migrations | Review time allocation decoupled from size |
| Look for the duplicate outside the diff | The structural blindness: the cloned block is impeccable inside its own PR | Repository duplication rate, measured and on the dashboard |
| Tests are the artefact reviewed first | That the reviewer can simulate behaviour by reading. With 400 lines they did not write, they cannot | Tests fail at least once before passing (otherwise they prove nothing) |
| Automated review goes first, never last | It shares blind spots with the generator: strong on syntax, weak on XSS and log injection | Zero merges approved by automation alone |
| No approving without a comment on risky changes | That fast approval signals quality. With the intuition decalibrated, it signals a queue | Percentage of merges with zero comments, by risk level |
Seven contract changes, no tooling changes
The artefact that gives the pull request its why back
Of the seven, the second holds up the rest, and it is also where this connects to something we argued before the data backed it.
If review lost value because it lost the author, the repair is not to hunt for an author who no longer exists: it is to move the why into an artefact written before generating and reviewed separately. That is exactly what Spec-Driven Development does: the specification stops being documentation that ages and becomes the unit that gets discussed, approved and versioned. Generated code becomes its checkable consequence, not the source of truth.
Seen from the review, the change is concrete. The conversation splits in two, and each half gets a counterpart back:
- On the specification — before anything is generated — there is a human author with intent, discarded alternatives and criteria. That is the expensive conversation worth having, and it takes minutes because the artefact is short.
- On the code the question stops being "why this way?" and becomes "does this do what the spec says, and what else does it do?". That is a question a reviewer can answer from a diff, even having written none of it.
The "what else does it do" is the part people skip and where the real problem lives, because generated code tends to bring unrequested work: a new dependency, a config file touched in passing, error handling that swallows the exception. That excess is invisible if you review against your memory of what was asked, and obvious if you review against a document. It is also, incidentally, what separates an MVP from a quick ship.
The same logic that makes a golden set the artefact that outlives model changes in an AI system applies here: what persists is not the output, it is the criterion it is judged against. And if that criterion is written down nowhere, every review reinvents it — with the uneven results you would expect.
How to tell whether this is happening to you
Five questions answerable with the data your repository already keeps. No perception surveys needed — which, as we have just seen, are exactly what does not work here.
- What percentage of your merges in the last thirty days went in with zero comments? If it climbs month over month while volume climbs, your review is already a formality. It is the cheapest measurement and the one that stings most.
- What percentage of your incidents came from a change that did pass review? This measures whether it catches anything. A review that approves everything and prevents nothing has a cost and no function.
- Is the 75th percentile of your pull request size growing? It is the leading indicator for everything else, and the easiest to fix with a team rule.
- How much duplication does your repository have today against a year ago? If you do not know, the dominant failure mode of generated code is not on your dashboard.
- How many changes have passed review and are not deployed? Fenton's test. If it is high, fix that first: redesigning review will not ship anything sooner.
The first four tell you whether your review still does its job. The fifth tells you whether review is even your most urgent problem. It is worth doing in that order, and worth having before the next conversation about buying another licence — because the pattern described in the 70% gap repeats here exactly: the tool arrived, the method did not.
The teams coming out of this well do not review faster and do not review less. They review something else: a short document before generating, and a bounded diff afterwards, against that document. It sounds like more steps. In person-hours it is cheaper than reading four hundred lines nobody wrote, hunting for a defect that, if it is the usual one, is not even inside the pull request.
Frequently asked questions
Has the bottleneck really moved to code review?
It depends on what you mean by bottleneck, and it is worth being precise because the answer changes where you invest. In GitLab's June 2026 survey, 85% of 1,528 developers and technology buyers say yes. Steve Fenton disputes the whole premise: if work piles up after review — approved changes that are not deployed — then the constraint is downstream, in batched deployment, and speeding up review delivers nothing sooner. Both can be right at once, because they are talking about different things: review is almost never your throughput constraint, but it is where the risk concentrates. You redesign it for the second reason, not the first.
What exactly changes when you review AI-generated code?
The assumption that an author exists breaks. A traditional review is a conversation with someone who made decisions and can explain them: why this structure, which alternative they discarded, what happens when a null arrives. With generated code, whoever opens the pull request is often reading it for the first time with the same attention as the reviewer. The question "why did you do it this way?" loses its addressee, and with it goes much of the mechanism by which review caught design problems rather than surface ones.
Does the data say generated code is worse?
It says something more uncomfortable: it is not worse line by line, it is more of it and worse connected. Veracode measured in 2026 that 55% of generated samples pass its security tests — a figure flat for two years — while syntactic correctness exceeds 95%. GitClear, across 623 million changes between 2023 and 2026, finds that the code movement characteristic of refactoring fell from 21% in 2022 to 3.8% in 2026, while copy-paste rose from 9.4% to 15.7%. The code compiles, passes, looks reasonable in the diff, and duplicates what already existed three folders away. That is not visible when you read the pull request: it is visible when you read the repository.
Is it worth putting one AI in charge of reviewing another AI's code?
It is worth it for the layer the linter already covered and for a first pass over long diffs, and it beats looking at nothing. It does not work as the last link in the chain, for two measured reasons. First, the failure mode of generated code is not syntactic, and automated review is strongest exactly where the code is already strong. Second, from Faros telemetry in 2026: pull requests merged with no review at all, human or agentic, are up 31.3%. The practical risk is not that the automated reviewer gets it wrong — it is that its presence reads as permission not to look.
How do you review a 400-line pull request nobody wrote?
You do not: you send it back. It is the one rule in this piece that works with nothing else in place, and the one that draws the most resistance. LinearB's data on 8.1 million pull requests puts AI-assisted ones above 400 lines at the 75th percentile against 157 for unassisted ones, and their acceptance rate falls from 84.5% to 32.7%. A large change generated in twenty minutes costs the same to split as a small one, because the cost of generating stopped being the limit. What does have to change alongside it is what accompanies the pull request: the specification it was generated against, and the cases that check it.
Where do I start this week without stopping delivery?
By measuring two things almost nobody has on the dashboard and that need no new tooling: what percentage of your merges in the last thirty days went in with zero review comments, and what percentage of that month's incidents came from a change that did pass review. The first tells you whether review exists or is a formality; the second, whether it catches anything. With those two numbers on the table, the conversation about pull request size and about what must accompany them stops being a matter of style and starts having a figure next to it.
Sources cited
- Faros AI — The AI Engineering Report 2026: The Acceleration Whiplash (two years of telemetry from 22,000 developers across more than 4,000 teams; merges without review +31.3%, bugs per developer +54%, incidents per PR +242.7%)
- LinearB — 2026 Software Engineering Benchmarks Report (8.1 million pull requests, 4,800 teams, 42 countries; size, wait for first reviewer and acceptance rate by PR type)
- GitClear — The Maintainability Gap: 2026 AI Code Quality Research (623 million changes between 2023 and 2026; refactoring, duplication and cross-file calls)
- Veracode — Spring 2026 GenAI Code Security Update (80 tasks, four languages, over 150 models; 55% security pass rate against over 95% syntactic correctness)
- DORA / Google Cloud — 2025 DORA Report · State of AI-assisted Software Development (nearly 5,000 professionals; positive relationship with throughput and negative with delivery stability)
- Stack Overflow — 2025 Developer Survey · AI (66% "almost right, but not quite"; 45.2% more time debugging generated code)
- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (16 developers, 246 tasks; forecast +24% speedup, measured −19%, post-hoc perception +20%). The authors explicitly bound the scope of the result and METR now labels it historical
- GitLab and The Harris Poll — AI Accountability Report (23 June 2026; 1,528 respondents across six countries; the 85% "bottleneck moved to review")
- Fenton, S. — Code Review Isn't Your Bottleneck, Even With AI (21 July 2026; the approved-but-not-deployed test, and batched deployment)
Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.
LinkedIn →