31% More Pull Requests Are Now Merging With No Review at All
Faros AI found 31.3% more pull requests merging with no review at all, and the incident data says that skipped gate is costing more than anyone tracked.
A help desk I worked around years ago was measured on one thing: how fast tickets got closed. One technician was very good at that number. He closed more tickets than anybody and closed them faster, so in a review meeting his row of the spreadsheet was the one you pointed at as the example.
He also closed tickets without resolving the problem underneath them, and he never taught anybody anything. The people he helped called back, usually inside a week, with the same issue wearing a slightly different costume. Total volume climbed. The desk's aggregate numbers moved the wrong way – customer satisfaction down, average time to resolution up – and the numbers he moved were everyone else's, not his own.
I still think about him kindly, which is probably why the story stuck with me. He wasn't gaming anything. He was doing exactly what we'd told him mattered, and the trouble was structural: the measurement was individual, the cost was collective, and the person generating the cost was our top performer by the only number anyone was watching.
That shape is why one figure in Faros AI's AI Engineering Report 2026: The Acceleration Whiplash stopped me cold. Drawing on two years of telemetry across 22,000 developers and more than 4,000 teams, Faros found that under high AI adoption, 31.3% more pull requests merged with no review at all – human or agentic. Faros calls it the most urgent finding in that section of the report, and I think they're right, though almost none of the coverage picked it up.
What high AI adoption actually changed about code review
More code arrives, in bigger pieces, and it is still almost entirely written by people. In Faros AI's telemetry, 80% of teams now clear the threshold of half their developers using AI tools weekly, epics completed per developer are up 66%, task throughput is up 33.7%, and the PR merge rate is up 16.2%. Individual pull requests are 51% larger than they were. Fewer than 1% of pull requests are opened autonomously by AI agents, so no robots are filing patches while everybody sleeps – this is the same engineers producing considerably more, considerably faster, in chunks that take longer to read.
The consequence everyone has already quoted is that median time in PR review rose 441.5%, which I've covered at length under the heading of the queue itself. Worth being precise, since secondary coverage keeps blending three separate numbers: that 441.5% is median time in review. Median time to first review rose 156.6%. Average time in review rose 199.6%. Three different measurements with three different meanings, and the largest of them is the one that travels.
What interests me more is what a team does next, because a queue that slow isn't a stable condition. Something gives.
How much code is reaching production with nobody looking
The thing that gave was the gate. That 31.3% increase in pull requests merged without any review is the adaptation, and Faros's own reading of it is the part I'd underline for any engineering leader:
We do not believe this reflects a deliberate decision to bypass oversight. The more likely explanation is that reviewers cannot keep pace with the volume of AI-generated code arriving for their attention.
Nobody held a meeting and voted to stop reviewing. Nobody edited a branch protection rule or amended the definition of done. Under enough load, the gate simply stopped closing, and the process diagram on the wiki still shows it there.
One clarification before anyone reaches for automation as the answer: Faros counts agentic review, and agentic review has grown from zero to 25% of pull requests. The 31.3% is what merged with no review from anyone, human or machine, after that growth is accounted for. Tooling is already absorbing a quarter of the load and the bypass rate went up anyway.
A word on the source. Faros AI sells engineering intelligence software, and this is their own telemetry from their own customer base, which is self-selected toward organizations that care enough about delivery measurement to buy a product for it. That cuts both ways. It's not a random sample of the industry, so I wouldn't treat 31.3% as a national average. It also means the teams in the sample are the measured ones, the teams best equipped to notice a control quietly failing, and it showed up there all the same.
This is a governance failure rather than a productivity problem
Review is a control, not a workflow step. It's the thing that was supposed to catch the defect before a customer did, and in most organizations I've worked with, it's the only control between an individual's judgment and production. When throughput doubles and the control does not scale with it, you haven't slowed down. You've quietly changed your risk posture without deciding to.
This is where I want to borrow a diagnostic instinct I use on almost every engagement: when everything downstream is failing, look upstream. The people closest to a visible failure are usually the least responsible for it, because they're standing at the bottom of the waterfall, up to their necks in what went wrong far above them. I once walked into an 80-person product organization badly behind schedule, and the story handed to me on the way in was the story I'm always handed – engineering is the bottleneck, the engineers aren't pulling their weight. On day one I started pointing at work in progress and asking why they were building it. Nobody could answer. Not the engineers, which I expected, but also not the two people whose entire job was to know. The engineers looked like the problem because they were downstream of it.
Reviewers are downstream too. The decision that produced their queue was made upstream, by whoever rolled out the tooling and then watched throughput climb and called it a win. My co-author and I wrote about this shape in Leading Product Teams: reward the wrong thing without thinking it all the way through, and you create a perverse incentive whose repercussions land well outside the thing you were measuring. That help desk was the small version of it, one desk and a satisfaction score. A review queue under AI load is the same mechanism at a scale that reaches your customers.
I do have a soft spot for reviewers. It's unglamorous work that never shows up in a demo, and the better you are at it, the more of it you get – which Faros captures in what they call a senior engineer tax, the concentration of review burden on the most experienced people on the team. Those are the same engineers you were counting on for architecture, mentoring, and incident response.
What the incident data says it costs
The cost is measurable, and it is not small. In the same Faros dataset, the incidents-to-PR ratio rose 242.7%, which means that for every pull request merged, the probability of a production incident more than tripled relative to the low-AI-adoption baseline. Bugs per developer rose 54%, monthly incidents rose 57.9%, and code churn – measured as lines deleted against lines added – rose 861%.
Put the two findings side by side. The control meant to catch AI-generated defects is the control being skipped, under pressure the AI created, and defects reaching production more than tripled per unit of work shipped. Every one of those throughput gains is real. So is the incident rate, and incidents are paid for by the same engineers, out of the same week.
There's a related finding I'll flag rather than resolve. Faros reports that strong engineering foundations do not protect against quality deterioration – that the mature, well-instrumented teams degraded too. That sits in genuine tension with the DORA program's and ClearRoute's reading that AI amplifies whatever discipline a team already has, which is the finding I leaned on in an earlier post about what your dashboard still measures. Two datasets, two answers, and I don't think the evidence is settled enough for me to tell you which one describes your team. It's worth knowing that the comforting version of the story has a credible challenger.
What isn't in tension: the trust gap between how fast code gets written and how confident anyone is in it, what QA already knows about AI-generated code, and the debt that outlasts the gain. Different datasets, same direction.
The number to pull before your next planning meeting
Your zero-review merge rate is the metric this turns on, and most teams don't track it. It's the share of merged pull requests that reached your main branch with no approving review and no substantive review comment from anyone other than the author, machine reviewers included. Nearly every organization tracks cycle time, merge rate, and deploy frequency. Almost nobody tracks the one number that tells you whether their most important control is still operating.
Pull it for the last 90 days from your own version control API, then pull the same 90-day window from a year ago, before the current wave of tooling. Split it by repository, because it will not be evenly distributed, and the repositories where it spikes are the ones you should be curious about. Then hold it next to your incident count for the same periods.
If you can't produce that number for last quarter, you don't know whether your review process still exists or whether it's just a diagram. That's a knowable thing, and it takes an afternoon.
The tooling market will have an answer for you, and its answer will be to buy a reviewer. That may well be part of it. But procurement is a second decision, and the first one is whether the volume you're now producing is a volume you can actually govern, which is a question about capacity and obligation rather than about vendors. It's the same question that help desk should have asked before it started rewarding closed tickets.
Nobody removed the gate. It stopped closing under load, quietly, while everyone's individual numbers got better.
If you want help finding out whether yours is still a control or already just a diagram, email matthew@fieldway.org.
Sources
More from Consulting Operations
The EU Just Made "A Human Looked At It" a Legal Category
EU AI Act Article 50 took effect on 2 August. Its human-review carve-out quietly turns accountability into a legal category, not just good practice.
Your Agents Don't Need Better Retrieval. Retrieval Is the Problem.
Six agent memory systems recall stored facts nearly perfectly and apply them to indirect questions barely at all. The bottleneck is retrieval itself.
£2.76 Million of Engineering. 5% Reached a User.
One financial institution spent £2.76 million on engineering in a year. About 5% of it reached a user, and AI never touched the reason why.
Want help running a sharper practice?
The reading and synthesis behind your client work, handled – a living deliverable kept current, so more of your time goes where your name is actually on the line.
See how this works for advisors