Here are two numbers from the same dataset.
Pull requests merged per developer: up 16.2%.
Median time a pull request spends in review: up 441.5%.
Both of those come from Faros AI's Engineering Report 2026, published in April. It isn't a survey of how developers feel about AI. It's two years of telemetry across roughly 22,000 developers on 4,000-plus teams, and rather than comparing AI-using companies against AI-avoiding ones, it compares each organisation against itself — its lowest-AI-adoption period against its highest.
That design matters. It sidesteps the usual objection that fast companies adopt AI and slow companies don't, so of course the fast ones look better. This is the same teams, the same codebases, the same people. Just before and after.
And what it shows is a system that got dramatically better at one thing and quietly worse at everything downstream of it.
#What Actually Improved
Let's be fair to the tools first, because the gains are real and they're not small.
Epics completed per developer: up 66%. Not tasks. Not commits. Whole units of scoped, planned work.
Task throughput per developer: up 33.7%.
Pull requests merged per developer: up 16.2%.
AI code acceptance rate went from 20% to 60%, and 80% of teams now clear the threshold of half their developers using AI tools weekly.
If your board asked whether AI coding tools do anything, that's your answer. They do. Developers using them produce more finished work than the same developers produced eighteen months earlier. Anyone still arguing that AI assistance is a wash is arguing against telemetry now, not vibes.
Hold onto that, because the rest of this post is going to sound negative and it isn't. The gains are the setup for the problem.
#What Got Worse
Median time in review: up 441.5%. Median time to first review: up 156.6%. Average review time: up 199.6%.
Pull requests merged with no review at all: up 31.3%.
Incidents-to-PR ratio: up 242.7%. Monthly incidents up 57.9%.
Code churn: up 861% — meaning far more of what gets merged is subsequently deleted or rewritten.
Bugs per developer: up 54%, sharply worse than the 9% the same research programme reported a year earlier.
Tasks stalled seven days or more: up 26%. Work restarts: up 13.8%. Daily PR contexts per developer: up 67.4%.
Read those together and a shape emerges. More work enters the pipe. Less of it comes out clean. The step in the middle — a human being reading code and deciding whether it should exist — is now taking four and a half times longer, and a growing slice of the work is skipping it entirely.
#Writing Code Was Never the Bottleneck
This is the part that should have been obvious and wasn't.
Every engineering organisation is a queue of queues. Work waits to be specified, waits to be started, waits to be reviewed, waits to be merged, waits to be deployed. Throughput is set by whichever queue is slowest, and everything you do to speed up the other queues just makes the slow one more crowded.
For about fifteen years, the industry's collective assumption was that typing was the constraint. That's what the tooling investment went into: better editors, better autocomplete, better scaffolding, better frameworks. AI coding assistants are the logical end of that project, and they worked — they made the writing step close to free.
But the writing step was never where the time went. Read the numbers again. Time to first review went up 156.6% while time in review went up 441.5%. Those are two different failures. The first is a staffing problem: nobody picked it up. The second is a capacity problem: once someone picked it up, they couldn't finish it, because there were four more waiting and each one was longer than it used to be.
Remove the constraint at the cheapest step and you don't get a faster system. You get a bigger pile in front of the next step.
#The 31% Nobody Approved
Of all the numbers in the report, the one worth taking to a leadership meeting is this: pull requests merged without any review are up 31.3%.
No engineering organisation decided this. There was no memo saying "we're relaxing review requirements because AI writes good code now." What happened is that a queue overflowed, and merging without review is what overflow looks like in a git-based workflow. It's a pressure-release valve that nobody installed on purpose.
That's the tell that this is a systems problem rather than a discipline problem. If your reviewers were getting lazy, you'd expect faster reviews and more unreviewed merges. Instead reviews got slower — 441.5% slower — and unreviewed merges went up anyway. The people still reviewing are working harder than ever. There just aren't enough of them, and the work in front of them is bigger.
The churn figure tells the same story from the other end. An 861% increase in code churn means a lot of what's merging is being undone shortly afterwards. Some of that is healthy iteration. A lot of it is work that would have been caught by a review that never happened, or a review that happened too quickly.
#Maturity Doesn't Save You
One finding in the report deserves its own section, because it kills the most common response to all of this.
The usual reaction is: sure, but that's undisciplined teams. We have strong practices, good CI, a real review culture. This won't happen to us.
The report checked. High-performing organisations experienced the same downstream quality deterioration as everyone else.
That makes sense once you accept the constraint argument. Good engineering practice mostly means your queues are well-managed relative to your input rate. If the input rate changes by an order of magnitude, having well-managed queues doesn't help — it just means you notice the backlog sooner. A tidy pipeline and a chaotic pipeline both flood when you multiply what's flowing through them.
Being good at the old rate is not the same as being good at the new one.
#What To Measure Instead
If you take one operational change away from this, make it this one: stop measuring how much your team produces and start measuring what's waiting.
Throughput metrics — PRs merged, commits, story points, tickets closed — are now actively misleading, because AI inflates them whether or not anything reaches production. A 16% lift in merged PRs bought with a 441% lift in review time is not a productivity gain. It's a bottleneck relocating, and a throughput dashboard will show it as a win.
Queue metrics don't have that problem. The ones worth putting on a wall:
Time to first review. Not total review time — first response. This isolates "nobody picked it up" from "the review was hard," and they need different fixes. Staffing versus batch size.
Open PRs by age, and what's blocking each one. A count of open PRs is nearly useless. Twelve open PRs where eight are waiting on a human is a different organisation from twelve where eight are waiting on CI. The blocking reason is the metric; the count is just the container.
Review load per reviewer. In most teams this is brutally concentrated — a small number of senior people absorb most of it. That concentration was survivable at the old volume. At the new one it's a burnout schedule with a spreadsheet attached.
Merged but not deployed. This is the queue almost nobody watches, and it's where AI-era lead time actually goes to die. Code that's merged is not code that's shipped. If you're merging 16% more and deploying at the same cadence, the gap is just sitting there, ageing, accumulating risk, and none of your throughput metrics will mention it.
Rework and churn rate. What fraction of merged code gets rewritten or reverted within a few weeks? This is the closest single proxy for "did the review actually catch anything," and given the 861% churn figure it's the one most likely to be moving under you unnoticed.
#What To Actually Do About It
Measurement is the easy half. Here's the harder half.
Cap work in progress at the review step, not the writing step. If a developer has three PRs open and unreviewed, the fourth one is not helping anybody — it's making the queue worse and splitting their own attention across more contexts. The report's 67.4% increase in daily PR contexts per developer is that cost showing up in the data.
Make review a scheduled activity with a budget. Review used to be something you fit around your real work. At current volumes that doesn't survive contact with reality. Teams that are coping with this have generally made review an explicit, time-boxed part of the day with named owners, rather than an interrupt that competes with everything else.
Attack PR size directly. Review time scales worse than linearly with diff size — a 900-line PR doesn't take three times as long as a 300-line one, it takes far longer, and it gets a worse review at the end of it. AI makes large PRs almost effortless to produce, which means the natural friction that used to keep them small is gone. Whatever kept your PRs small before, you now need to do on purpose.
Treat "merged without review" as an incident class. Not a policy violation to punish — a signal that your queue overflowed. Track it, look at when it spikes, and fix the pressure rather than the person.
Move some review earlier, into the loop. The most durable fix isn't asking humans to read faster. It's giving the agent writing the code the same context a reviewer would apply — your size conventions, your architectural boundaries, the standards your team actually enforces — before the pull request exists. A review that never has to happen is the only review that's genuinely free.
#The Honest Caveats
Two, and they matter.
This is correlational. The within-organisation design is a real strength — it controls for a lot of what usually muddies this kind of research — but 2024 to 2026 was not a quiet period in software. Layoffs, reorganisations, hiring freezes and a macro squeeze all land on the same metrics. Some of the review slowdown is AI volume. Some of it is probably fewer senior engineers doing the reviewing. The data can't cleanly separate those.
And "worse" here means worse than the same teams' own pre-AI baseline, not worse than some absolute standard. A 242.7% rise in the incidents-to-PR ratio does not mean production is on fire; it means the ratio moved a lot from wherever it started, and where it started varies enormously by organisation.
None of that changes the direction of travel. It just means the precise magnitudes deserve less confidence than the pattern does.
#The Uncomfortable Version
The pitch for AI coding tools was that they'd let the same team ship more. The telemetry says they do — 66% more epics per developer is not a rounding error.
But shipping is not merging, and merging is not writing. We optimised the cheapest step in the pipeline by an enormous factor and left the two expensive steps exactly as they were: staffed by the same people, running at the same speed, with several times more arriving each morning.
The teams that get real value out of this era won't be the ones generating the most code. That's now a solved problem and worth roughly nothing. They'll be the ones whose review and deploy steps kept pace — because that's where the queue is, and the queue is the only thing that has ever set your throughput.
Find the queue. Everything else is decoration.
#Related Reading
- Lead Time for Changes: Measuring Development Velocity - Where time actually goes between commit and production
- Advanced Code Review Strategies for Large Teams - Scaling review without scaling headcount
- Measuring AI Coding Tool ROI: A Practical Framework - Establishing the baseline this report compares against
- Change Failure Rate: Balancing Speed and Quality - The metric that catches what review missed
Coderbuds shows you where work is actually waiting — open pull requests and what's blocking each one, review load by person, and merged work that hasn't shipped yet. See your team's queues.
