AI made writing code cheap. Review is still expensive
Teams merged 98% more PRs this year and review time went up 91%. The bottleneck moved from writing code to approving it, and most teams haven't noticed.
Two numbers from this year's LinearB benchmarks. Teams with heavy AI adoption merged 98% more pull requests. Review time on those pull requests went up 91%.
Read them together and you have the whole story of AI-assisted development in 2026.
We made one half of the job almost free and left the other half exactly where it was. Then we acted surprised when delivery did not get twice as fast.
The data, without the vendor spin
LinearB's 2026 Software Engineering Benchmarks Report is built from 8.1 million pull requests across more than 4,800 organisations in 42 countries. It is the biggest dataset anyone has published on this, and the findings are uncomfortable if you sold your board on an AI productivity story.
The headline numbers:
- AI pull requests wait 4.6x longer before anyone picks them up
- Once someone does pick them up, they get reviewed about 2x faster
- Acceptance rate for AI-generated PRs is 32.7%. For hand-written ones it is 84.4%
- At the 75th percentile, AI-assisted PRs are 2.6x larger, 408 lines against 157
- Agentic AI PRs sit unclaimed 5.3x longer than unassisted ones. AI-assisted ones sit 2.47x longer
That third bullet is the one I keep coming back to. Two out of three AI pull requests never make it in. All of that generation, all of that token spend, and the majority of it ends up abandoned or rewritten. It still cost somebody a review slot on the way out.
The fourth bullet explains the first. Nobody wants to open a 400-line diff they did not write.
Little's Law does not care that it's AI
Little's Law was published in 1961. It says the average number of items in a queue equals the arrival rate times the average time each item spends in the system. Push more work into a stage whose capacity has not changed and the queue grows. That is it. There is no clever version.
We increased the arrival rate at code review by roughly double and did nothing to review capacity. The queue grew. This is not an AI story, it is a manufacturing story that happens to be running on GitHub.
What makes it feel like an AI story is that the pain shows up somewhere you were not watching. Your developers genuinely are faster at writing. Their sprint feels great. Meanwhile lead time to production is flat or worse, and nobody can point at the step that ate it, because the step that ate it is a queue and queues do not appear on anybody's dashboard.
I wrote about a related version of this in why your developer has been "80% done" for 3 weeks. Same shape: the visible work finishes early and the invisible work takes all the time.
Nobody wants their name on the approval
Here is the part the throughput framing misses. Review is not slow because reviewers are lazy. It is slow because approving AI code is a bet with your name attached.
Sonar's 2026 State of Code Developer Survey put this in numbers. Across 1,100+ developers:
- AI writes or heavily assists 42% of committed code today, expected to hit 65% by 2027
- 96% do not fully trust AI-generated code to be functionally correct
- Only 48% always verify it before committing
- 38% say reviewing AI code takes more effort than reviewing a human colleague's
- Teams report burning about 24% of the work week checking, fixing and validating AI output
Look at the gap between the third and fourth bullets. Almost everyone distrusts the code. Barely half always check it. That is not hypocrisy, that is capacity. You cannot verify at 42% of your codebase volume with the review process you built when a human typed every line.
When I review a PR from someone on my team, I can ask them why. They had a reason, even if it was a bad one, and the answer tells me where else to look. An agent had a probability distribution. There is nothing to interrogate, so the only safe review is reading every line, and reading every line is exactly the thing that does not scale.
I made a version of this argument about the people side in AI raises the floor for weak engineers, then it comes for their job. The queue is the systems version of the same problem.
What I do when I am the only engineer
On most of what I ship independently, there is no second engineer. No reviewer, no queue, nothing to wait behind.
That did not remove the problem. It moved it earlier.
The review still has to happen, so it happens in scoping, before any code exists. I write down what the thing must do, what it must refuse to do, and what "wrong" looks like, and then I let the agent build against that. It is slower on day one. It is the only version that works, because I have no one to catch me later.
The practical form of this is a short brief I write before touching a prompt:
## What this change does
One sentence. If it needs two, it's two changes.
## What must not break
- [ ] Existing endpoint contracts
- [ ] Auth on the admin routes
- [ ] The nightly export job
## How I'll know it's wrong
- [ ] Test that fails today and passes after
- [ ] Manual check: <the exact click path>
- [ ] Log line or query that proves it in staging
## Out of scope
Things I will be tempted to fix and won't.
Four headings. Takes eight minutes. It has caught more bad work than any code review I have ever sat in, because it catches the bad work before it is written and before anyone is emotionally attached to it.
If you use Claude Code, plan mode is built for exactly this and most people skip past it. I covered the modes in Claude Code permission modes.
If you have a real team, change the review step
Six things that actually move the number, roughly in order of how fast they pay off:
- Cap PR size. Hard limit, enforced in CI. 400 lines is not a pull request, it is a hostage situation. Smaller diffs get picked up faster, which is the 4.6x number you are trying to kill.
- Make the author state what they verified. Not "added feature X." What did you run, what did you check, what are you unsure about. An honest "I did not test the error path" is worth more than a green checkmark.
- Put the automated gates before the human. Static analysis, tests, security scanning, all of it runs and passes before a reviewer opens the tab. Reviewers should be spending attention on design, not on catching a null check.
- Label AI-authored PRs. You cannot manage a queue you cannot see. If you do not know which PRs are agentic, you cannot tell whether your acceptance rate problem is a tooling problem or a scoping problem.
- Track time-to-first-review as a first-class metric. Not cycle time, not merge rate. The pickup delay is where the loss lives and it is the one number most teams do not have on a dashboard.
- Give the agent the same context you'd give a new hire. Most rejected AI PRs are rejected for missing intent, not broken syntax. This is why your docs are now infrastructure for AI coding agents.
Notice what is not on that list: more AI at the writing step. If your queue is the constraint, faster generation makes the queue longer. That is the whole point.
About the "developers feel faster" number
You have probably seen the stat that developers felt 20% faster while measuring 19% slower. That is METR's randomized trial, not LinearB, and the two get mashed together constantly. Sixteen developers, 246 real tasks, mature repositories they knew well.
Worth knowing the caveat before you quote it: METR ran a follow-up and said in February 2026 that selection effects made the newer estimate unreliable. Developers who most wanted AI would not sign up for the no-AI condition.
So do not use it as a measurement of how much slower AI makes anyone. Use it for the thing it actually shows, which is that self-reported speed and measured speed pointed in opposite directions in a controlled setting. If your evidence that AI is working is that your team says it feels faster, you do not have evidence.
What to do this week
Pull one number: median time from PR opened to first review comment, split by whether AI touched the code. Most teams can get this out of their Git provider in an afternoon.
If the AI column is materially worse, you have found where your productivity gains went. It is not a tooling problem and buying another assistant will not touch it.
Then do the boring thing. Cap PR size, move the checks in front of the human, and make somebody own the queue.
At dsrpt we run this across client work in Kuwait and Australia, and the pattern holds everywhere: teams that measured before adopting are fine, teams that adopted and assumed are quietly slower than they were a year ago. We wrote about the cost-per-job framing in GPT-5.6 is here: what it means for teams building software, and it applies here too. The question was never how fast the model writes. It is what a finished, approved, shipped change costs you end to end.
If you are generating more code than you were a year ago and nothing changed about how it gets approved, you did not get faster. You got a bigger queue.
Sources:
Building scalable systems and developer-first tools. Lead Software Engineer at DSRPT.
Frequently asked
-
Two reasons. They are bigger, running about 2.6 times larger than hand-written PRs at the 75th percentile, and reviewers do not trust them. Sonar's 2026 survey found 96% of developers do not fully trust AI-generated code to be functionally correct. A large PR you cannot skim, from an author you cannot interrogate, is the least appealing thing in anyone's review queue. So it sits.
-
At the individual writing step, usually yes. At the organisation level, much less than people expect. LinearB's 2026 data shows teams merging far more PRs while review time climbs and net delivery improvement lands around 10%. The generation gain is real, it just gets consumed by the review queue before it reaches production.
-
It is what happens when you speed up one step in a pipeline and leave the next one alone. Code generation got roughly free. Approval still costs a senior engineer's attention and carries the same accountability it always did. More work arriving at a step with unchanged capacity means a longer queue, which is the oldest result in queueing theory.
-
Add review capacity or reduce review load. In practice: cap PR size, require the author to state what they verified and how, run automated quality gates before a human ever opens the diff, and move the hard decisions into scoping so the review is about correctness rather than intent. Adding more AI to the writing step makes it worse.