Ask engineering leaders whether AI has made their teams faster and most of them say yes. Look at what reaches production and the answer is much less clear. The gap between those two answers isn’t noise, and it isn’t leaders kidding themselves. It sits in one specific place: the review queue.

One caveat before the numbers. All six datasets below come from vendors. Jellyfish, Faros AI, LinearB and Plandek sell engineering intelligence, CircleCI sells CI, and Sonar sells code quality tooling. Each of them sells the fix for the problem it measures. So the argument here rests on six vendors with different products pointing the same way, not on neutral research. I think that agreement is worth something, but read it as that.

The survey says yes

Jellyfish’s State of Engineering Management 2026 (May 2026, 600+ engineering leaders) found that 64% of teams report at least a 25% gain in velocity from AI, and 80% of leaders say AI improves productivity. Only 10% combine strong enablement with high adoption across the organisation.

LinearB’s 2026 benchmarks survey shows how those gains get counted. 88.3% of organisations use AI tools daily or several times a week. 44.7% don’t formally measure AI’s impact at all. 76.1% of leaders report productivity gains anyway, based on adoption signals rather than delivery data. And just 6.4% are extremely confident in the quality of the code AI produces.

So we have high usage, high reported gains, thin measurement and low confidence. That combination should make anyone want to look at the telemetry.

The telemetry says “not where you think”

LinearB also published the telemetry side: 8.1 million pull requests from 4,800 teams and 163,820 contributors in 42 countries. AI-assisted PRs were merged within 30 days 32.7% of the time. Unassisted PRs were merged 84.4% of the time.

That number needs care. Some AI-assisted PRs are speculative, the kind of thing nobody would have bothered to open by hand. A low merge rate on those is fine. But even with a generous discount for that, most of the AI-assisted work isn’t landing.

Faros AI found the same pattern earlier. Their AI Productivity Paradox study is from July 2025, a year older than everything else here, but it covers more than 10,000 developers across 1,255 teams. Developers with high AI adoption completed 21% more tasks and merged 98% more PRs. PR review time went up 91%, average PR size went up 154%, and bugs per developer rose 9%. At the company level, Faros found no significant correlation between AI adoption and improvement. The individual got faster. The company didn’t.

Where the code goes

CircleCI’s 2026 State of Software Delivery shows where the extra work ends up. It is based on 28.7 million workflows run in September 2025.

Average daily workflow runs were up 59% year over year, so a lot more code is moving through pipelines. For the median team, throughput on feature branches rose 15%, while throughput on the main branch fell 7%. Main-branch success rate dropped to 70.8%, the lowest in more than five years, which means nearly three in ten attempts to merge into production fail. Getting back to green takes the typical team 72 minutes.

That is the bottleneck in numbers. More code gets written and piles up in front of main, and less of it gets through.

Sonar’s State of Code Developer Survey (January 2026, 1,100+ developers) explains why the pile isn’t clearing. Developers say 42% of the code they commit is already AI-generated or AI-assisted, and they expect 65% by 2027. 96% don’t fully trust that code. Only 48% always verify it before committing. And 38% say reviewing AI code takes more effort than reviewing a colleague’s.

That last figure is the important one. The volume of review didn’t just go up. Each review got more expensive. A reviewer looking at a human colleague’s PR can lean on shared context: they know how that person works, what they tend to miss, and what they meant. With AI-generated code that context is missing, so the reviewer has to rebuild the intent from the diff alone. And the diffs are getting bigger.

Why more agents won’t fix it

The obvious response is to put AI on the review side as well. Use agents to review the agents’ code and the bottleneck goes away.

It doesn’t, because review isn’t a production task. Its job is to decide whether someone is willing to stand behind a change going into production. You can parallelise the work that leads up to that decision: linting, test generation, a first pass for obvious defects. All of that is worth doing. But the decision itself has to be owned by a person, and adding more agents gives that person more output to look at, not less. If 96% of developers don’t fully trust AI-written code, an AI review of it doesn’t settle the question. It just moves it to a different place.

I made a related argument in May, in Throughput Got Cheap. Judgment Didn’t., about why judgment is now the scarce resource. This post is about what that scarcity looks like when you measure it: work that is finished but not merged.

Floor, not ceiling

Plandek’s 2026 engineering productivity benchmarks, covering more than 2,000 teams, show who actually benefits from AI.

With AI, lower-performing teams cut their Lead Time to Value by nearly 50%. Top-performing teams improved by around 10 to 15%. That’s roughly a fourfold difference. The spread between teams is still large: bottom-quartile teams using AI take more than 35 hours on average to merge a pull request, compared with under 21 hours for top performers. Top teams get changes to production in under 22.5 days. Bottom-quartile teams take more than 62.

So AI raises the floor much more than it raises the ceiling. That changes the business case. “Make our best engineers faster” is the pitch most AI tools are sold on, and it’s the weaker one. The stronger one is “bring our weaker teams closer to our best.”

The ceiling can still move, but not through tooling alone. CircleCI’s top 5% of teams are the counterexample to everything above. Their feature-branch activity grew 85% and their main-branch throughput grew 26%. They got the extra code all the way to production. Plandek points the same way: teams that removed constraints in their delivery system alongside adopting AI delivered more than twice the output per engineer compared with teams that only adopted the tools. The teams that win changed how work gets reviewed and released, not just what writes the code.

What to ask on Monday

None of this needs a maturity model. It needs four honest questions:

  • Do you measure merges to main, or PRs opened? If your AI dashboard counts activity, it will look good no matter what reaches production.
  • What is your review time per PR, and is PR size growing? If both are going up, you already have the bottleneck. You just haven’t named it yet.
  • Who owns review capacity? In most organisations review is something people do in between their “real” work. If it is now the constraint on delivery, it needs an owner, time and a budget, like any other constraint.
  • Who are you buying AI for? If the honest answer is your top quartile, the data says you’ll see the smallest return there.

The short version

AI made writing code cheap. It didn’t make deciding what ships any cheaper, and it made each of those decisions harder. The gains your teams report are real, but most of them are sitting in the review queue. Clearing that queue is a question of how the delivery system is designed, and buying more tools won’t answer it.