A great many adoption figures have been published these past months. They all look excellent and they say nothing. This one is different, because it measures the far end of the pipe rather than the near end: LinearB analysed 8.1 million pull requests across 4,800 teams in 42 countries, and looked at which ones actually got merged.
88.3% of the developers in the sample now use AI regularly, up from just under 72% in early 2024. So adoption is settled. And yet:
Hand-written pull requests merge 84.5% of the time within thirty days. AI-generated ones merge 32.7% of the time.
Two out of every three AI pull requests never reach a customer. That isn't a nuance - it's half the promise disappearing somewhere between generation and production.
Three measurements that explain the gap
The report separates three families of pull request - unassisted, AI-assisted, and fully agentic - and the gaps are mechanical:
Merge rate within 30 days human PRs ............... 84.5% AI-generated PRs ........ 32.7% Size at the 75th percentile human PRs ............... 157 lines agentic PRs ............. ~290 lines AI-assisted PRs ......... 400+ lines (~2.6x human) Refactor share, 75th percentile human PRs ............... ~37% AI-assisted PRs ......... close to 0% Time before review is picked up human PRs ............... ~200 minutes AI-generated PRs ........ more than 16 hours
LinearB has been recommending for years that a pull request stay under 300 lines, because that is roughly what a human brain holds in working memory. AI-assisted work clears that threshold as a matter of routine.
Review is breaking, and it breaks at both ends
The most telling number isn't the merge rate, it's the review pickup delay. An AI pull request waits more than sixteen hours before a reviewer opens it, against a little over three hours for a human one. Five times longer.
The explanation fits in a sentence: nobody knows what to do with it. The reviewer can't estimate the mental load it will cost, doubts what context the author had in mind, and feels none of the social obligation to help a colleague ship - because there is no colleague.
Then comes the twist. Once review begins, AI pull requests move through it faster than the rest: roughly 194 minutes against 252. You could read that as good news. It's the opposite. A 400-line change reviewed faster than a 157-line one is not an efficient review: it's a surface inspection. LinearB says so plainly, and the qualitative responses in its survey confirm what teams already feel - a lot of code is reaching production without having been genuinely examined.
A pull request that waits sixteen hours and then gets reviewed in three has not been reviewed. It has been stamped.
The Stack Overflow blog documents the same phenomenon from another angle, and the anecdote it reports is worth every chart. Pratima Arora, Smartsheet's CPTO, describes an engineer producing seven times more code than the rest of her team - and good code, she stresses: the check-ins and the reviews were excellent. The result: the other six spent the majority of their time reviewing hers rather than writing their own.
That's the whole subject in one story. Individual productivity is not team productivity. It can even eat it. And where one person was enough to saturate six reviewers, a fleet of agents has no reason to be gentler.
The number nobody talks about: refactoring at zero
There is one figure in this report that deserves more attention than the merge rate. At the 75th percentile, a human pull request spends about 37% of its changes on existing code. An AI-assisted one: almost none.
In other words, AI is not helping pay down technical debt. It is expanding the surface you have to maintain.
LinearB's explanation is the right one, and it is economic rather than technical: generating fresh code costs a model nothing. It doesn't feel the mental drag that pushes a human developer to go and find the function that already exists. Without explicit guidance on internal libraries, shared components and approved implementation paths, the shortest route is always to start from scratch - even if that duplicates what the team went to the trouble of factoring out.
It is the best argument for an explicit context layer I have read. A codebase is not a sufficient source of truth: it shows what exists, never what was deliberate. And a model that cannot tell an architectural decision from eight years of accumulated debt will reproduce both with equal conviction.
The software factory, once measured
The second report, published in early August, covers the first half of 2026: 2.7 million PRs, 7.5 million commits, 83,000 developers, 253 organisations. It lets you put a number on a phrase heard everywhere - the software factory, the pipeline where agents triage, spec, implement, review and ship while the engineers pull back to the edges.
At organisations rated "elite":
- 54% of pull requests are AI-assisted;
- 13% of developers use AI on at least three working days in four;
- agents author up to 4.7% of PRs.
4.7%. Even at the 90th percentile, the genuinely autonomous part of the pipeline opens one PR in twenty. Everything else still comes into existence in collaboration with a human. If your team isn't wall-to-wall agentic, you aren't behind: you are in the majority, by a very wide margin.
Against that, the depth gap is dramatic. Compared with themselves a year earlier, developers in the heaviest usage band merged 95.7% more. The high band gained 65.4% more PR yield, the moderate band 24.4%, light adopters 2.2%. Developers using no AI at all fell 3.6%.
Two caveats before you take these numbers into a board meeting. First: the sample consists of organisations that already measure their delivery with LinearB - by construction, teams more instrumented than average. Second: LinearB sells the analytics layer its own numbers argue for. That invalidates nothing - the method is described and the sample is enormous - it simply invites you to read the commercial conclusion with the same distance as the rest.
The real diagnosis: nobody owns an agent's pull request
The mid-year report breaks agentic merge rates down by maturity tier, and this is where the story becomes useful:
Merge rate for agent-opened pull requests "elite" organisations ......... 79% "good" organisations .......... 58% "fair" organisations .......... 37%
A fair-tier organisation ships barely a third of the code its agents produce. The rest accumulates, ages, and is eventually abandoned - after being paid for in tokens.
LinearB's diagnosis is the right one, and there is nothing technological about it: when an agent opens a pull request, no human owns it. It appears on nobody's board, sits in nobody's objectives, and has nobody to answer a question about it. It doesn't die. It fades.
The prescription that follows is disappointingly ordinary, which is usually a good sign. Before adding agents, give every agent-opened pull request a named human owner. Put those PRs on the same board as everyone else's. And count that shepherding as delivery when review season comes, or nobody will do it.
If your agentic merge rate looks like the fair tier, buying more agents is precisely the wrong purchase.
What this changed in our own model
This was the first design decision we took at Survol, and I'm setting it down here because these figures finally give it a measured justification rather than an intuition: the unit of truth is the version, not the author.
Concretely, a version developed by hand - zero tokens spent - and a version produced by an agent have exactly the same lifecycle: a branch, a merge request, an owner, a review, a preview, a promotion. So does a mixed version, which is the most common case of all. This wasn't an ideological statement about the place of humans; it was the only way to stop a change becoming an orphan depending on who wrote it. LinearB's report describes precisely what happens when you don't.
The counterpoint worth reading too
LinearB's own article cites an experiment worth reporting as-is, because it cuts against its own narrative. Dex Horthy, of HumanLayer, ran his company's work through a full software factory with humans at the edges. He shut it down after roughly three months, because of codebase rot: nothing in the way models are trained rewards keeping a codebase maintainable, so quality eroded in a way no test could catch.
Set that next to the near-zero refactor rate and you get the same phenomenon seen from two places. It isn't an argument against automation - it's an argument against unmeasured automation.
Measure what the factory delivered, not what it generated
The most useful part of the second report is a three-part measurement frame, all of it computable from data you already have:
- Effective PRs: merged pull requests, with rework discounted out. Generated output is not delivered work. A PR that never merged delivered nothing, and a PR you rewrite next sprint delivered less than it appeared to.
- Cost per effective PR: total engineering cost, people and AI together, divided by effective PRs. People cost dominates the numerator - hence LinearB's honest caveat: the level depends on your accounting, only the direction between two periods means anything.
- Rework rate, the guardrail under both of the above. A PR you merge and then rewrite spends from your AI budget twice: once to generate it, once to redo it. It is also the point where the rot described above stops being a feeling and becomes a number.
The frame is sound, and it beats anything sitting in an adoption dashboard. I'd make one remark, which extends it rather than criticises it: a pull request is a unit of plumbing, not a unit of value. A feature may take one PR or eleven, depending on how your repositories are split. The day the denominator becomes the shipped feature rather than the merged PR, "what did this earn us" stops being an estimate. That's why we track consumption per session, per version and per feature - same idea, one level up.
What these numbers don't say
The limits matter, otherwise you just swap one bad metric for another.
- A merge rate is not a quality rate. An abandoned pull request may have been a good experiment, settled quickly and well. Exploring three approaches and discarding two is healthy practice, not waste - and AI is precisely what makes that kind of exploration affordable. Some share of the unmerged 67% is useful work.
- These measures ignore whatever never became a PR. The prototype that settled an argument in a meeting leaves no trace in these statistics, and it may have saved a month.
- The 84.5% human merge rate is a comparison point, not a target. A team that merges nothing it opens has a problem; so does a team that merges everything.
What we take away
- Adoption is settled: 88.3% of developers use AI regularly. It has stopped being an interesting indicator.
- Merge rate is one: 84.5% for human code, 32.7% for AI code. The bottleneck has moved from production to review and ownership.
- AI pull requests are 2.6 times larger, wait five times longer, then get reviewed faster. All three numbers tell the same story.
- The near-zero refactor share is the underlying signal: AI is growing the surface to maintain rather than shrinking it, for want of explicit context about what already exists.
- The fully autonomous factory accounts for 4.7% of PRs, even among the best. The real lever isn't adding agents - it's giving each of their pull requests a named human owner.
There is an optimistic reading of all this, and I think it's the right one. If the blocker were model quality, we would have to wait for the next generation and hope it suffices. Because it sits in how work is organised - who owns what, who reviews what, at what granularity we count - it is addressable this week, with the tools we already have.
Sources: "8 million pull requests reveal where engineering productivity breaks down", LinearB, 4 May 2026 · "Your software factory needs a context layer", LinearB, 4 August 2026 · "Coding agents are giving everyone decision fatigue", Stack Overflow Blog, 21 May 2026. All figures quoted are those published by these sources.
