Faros AI has now measured AI-era code review twice. In its 2025 dataset, PR review time on high AI adoption teams was up 91%. In its 2026 dataset, median time in PR review is up 441.5%, average time in review is up 199.6%, and median time to first review is up 156.6%. Faros is careful to say the two studies are independent cross-sections rather than a longitudinal panel, so the pairing shows directional consistency and not a year-over-year trend. The direction is the part that matters here.
Two disclosures before anyone builds a plan on those numbers. Faros compares quarters of low AI adoption against quarters of high adoption inside the same company, which is a correlational design and not a causal one. Faros also sells engineering-intelligence tooling and competes with our own product, Releezy. The samples differ: the 2026 report draws on two years of telemetry, 22,000 developers and more than 4,000 teams, while the 2025 report covers over 10,000 developers across 1,255 teams.
The interesting question is what a leader does with a review queue that grew like that. The available answers are process answers. Add reviewers. Tighten the checklist. Put an AI reviewer in front of the human one. Every one of those leaves untouched the quantity that actually sets review capacity.
Authoring Scaled. Judgment Did Not.
Faros in 2025 put the throughput side plainly: “Developers on teams with high AI adoption complete 21% more tasks and merge 98% more pull requests.” In that 2025 cross-section, high-adoption teams merged roughly twice as many pull requests as low-adoption ones. The 2026 cross-section is where it gets interesting: PR merge rate per developer is up only 16.2%. Faros rejects tool fatigue as the explanation and names the constraint instead, writing that “the code quality is creating a review bottleneck that is throttling throughput” and that organizations “are generating more code than the system can review and merge.” The capacity to judge them did not follow, and my argument for why is that judging a change is an act of reconstruction.
A reviewer approves a change by rebuilding enough of the system in their head to predict what the change will do in production. That reconstruction has a cost, and the cost is paid per change, by whoever holds the responsibility. Authoring got cheaper. Reconstruction did not.
The Quantity That Sets the Budget
How much context a review requires comes from the change itself. The reviewer only pays the bill. The footprint of a change is set by how the system is divided.
A change confined inside one bounded module can be judged against that module’s contract. The reviewer reads the diff, reads the contract, and knows what the blast radius is because the boundary defines it. A change that crosses four boundaries forces the reviewer to hold four contracts plus the interactions between them, and the interactions are where the defects live. If a change touches six bounded modules instead of one, no amount of reviewer seniority makes the sixth module free.
This is why I expect process interventions to underperform on this problem. A checklist tells the reviewer what to look for inside a context they still have to assemble. A second reviewer does not halve the reconstruction; it duplicates it. An AI first pass changes who assembles the context, and we will come back to why that helps less than it looks.
Architecture is the only variable in the system that changes the quantity itself. We have argued before that boundaries are what make agents trustworthy. The same boundaries decide whether agent output is reviewable at all.
What Overload Looks Like in Telemetry
Faros 2026 reports that daily PR contexts per developer are up 67.4%, against +46% in the prior dataset. Tasks touched daily are up 17.7%. Work restarts are up 13.8%. And 26% more in-progress tasks sit for seven days or more with no PR and no activity.
I read those numbers as people switching between more open threads than they can hold. Faros measures the counts, not the limit, so the interpretation is mine.
Code churn, measured as lines deleted against lines added per quarter for merged code, is up 861%. Faros describes that as 9.6 times the prior rate. Churn on merged code means the work passed review and came out anyway. Incidents per PR are up 242.7%.
Faros names a different mechanism, one layer above the architecture: “the code arriving for review is often not review-ready. Reviewers are not just assessing more code, they appear to be working harder to bring that code up to a standard it should have met before the PR was opened.”
The Capitulation Metric
Pull requests merged with no review at all are up 31.3%. Faros calls this “the most urgent finding in this section.”
That is a capacity signal. When the cost of reconstructing context for a given change rises above what a reviewer can spend, the review does not get worse in a gradual, measurable way. It stops happening. Nobody announces the decision. It shows up only where someone is already counting unreviewed merges.
We have written about what happens when teams try to replace that lost review with layers of policy: it is mostly governance renamed. And the deeper problem underneath the churn figure is that review signal has decoupled from production outcome, which is the verification paradox of agent-written code.
AI Reviewers Are Bound by the Same Limit
The argument for AI review assumes that a machine reviewer has effectively unlimited patience for context. It has a context window, and the argument runs that a coupled system fills that window with code the change did not touch.
Faros describes precisely why this output is expensive to judge: “It is often superficially convincing: idiomatic, well-named, stylistically consistent with the surrounding codebase… The structural and logical failures, when they exist, are beneath the surface. Catching them requires the reviewer to read carefully, reason about intent, and reconstruct the problem the code was meant to solve.”
CodeRabbit, which sells AI code review and therefore has an interest in this finding, reported in December 2025 on 470 open-source GitHub pull requests, 320 of them AI-co-authored and 150 human-only. AI-co-authored changes carried 10.83 issues per PR against 6.45 for human-only, roughly 1.7 times as many by my arithmetic. CodeRabbit reports that “Logic and correctness issues were 75% more common in AI PRs.”
Logic and correctness are exactly the class of defect that requires the reviewer to hold the surrounding system. Style and naming are local. Correctness is relational, and relations cross boundaries. The Serious CTO made this argument in April 2026 with the sharpest framing I have seen: if services are tightly coupled, agents fill their context windows with unrelated code, and reviewers end up evaluating changes that touch everything at once. Modifiability is the property that matters, and localized change with strong boundaries is what keeps the reviewable context small.
Swapping a human reviewer for an agent moves the reconstruction to a system with a bounded context window and no accountability for the outcome. If the architecture forces a large context, I expect the agent reviewer to fail the way the human one does, and to fail more quietly.
Do This Now
Instrument one number and treat it as an architectural metric: how many bounded modules the average merged change touches. Your repository history has the raw material: map your module boundaries once, then count how many a merged change crosses. Compute it per PR and plot the trend over the last four quarters. Then set a cap.
When a change exceeds the cap, the correct response is to reject the shape of the change or to fix the boundary that forced it. When the average rises quarter over quarter, you have an architecture defect, and every review-process intervention you fund against it will underperform.
This is falsifiable, which is the point. If your team caps the number of modules a change may touch, holds the cap for two quarters, and review time and escaped defects do not fall, the thesis here is wrong for your codebase. If you add reviewers and checklists instead and both metrics keep climbing, that is what this argument predicts. Faros measured the backlog, not what happens when you try to staff your way out of it. We have argued that optimizing the coding step alone creates queues downstream, and that review was always doing more than defect detection, which is a separate argument worth reading. Neither changes the arithmetic above.
Every boundary you fix lowers the context the next review needs.
This analysis synthesizes AI Engineering Report 2026: The Acceleration Whiplash (Faros AI, March 2026), The AI Productivity Paradox Research Report (Faros AI, 2025), State of AI vs Human Code Generation Report (CodeRabbit, December 2025), and AI Killed Code Review (Here’s the Proof) (The Serious CTO, April 2026).
Victorino Group helps engineering teams find the boundaries that make their changes reviewable again, so review capacity stops being the thing that limits delivery. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation