What Actually Changed in How Teams Ship Code This Year

A May 2026 analysis of 8.1 million pull requests across nearly 5,000 engineering teams found something worth sitting with: AI-generated pull requests now wait more than 16 hours on average before a reviewer picks them up, compared to roughly 200 minutes for work written without AI assistance, and once picked up, AI-generated PRs merge at a rate of about 33%, against roughly 84% for manually authored ones. Writing code got faster. Trusting it didn’t keep pace.

The biggest shift in 2026 engineering practice isn’t that AI writes more code; it’s that the bottleneck moved from writing code to reviewing and trusting it, which changes what “good engineering practice” actually requires from a team. That’s not a prediction or a vibe about where things are headed. It’s what a large, dated dataset says has already happened, and it’s worth being precise about what that shift actually demands from a team trying to keep up with it.

What’s actually different about how teams ship code now, versus a year ago?

The constraint moved. A year ago, the honest bottleneck on most teams was still writing the code itself: engineers spent real time producing the diff, and review was a comparatively fast step layered on top of that slower process. This year’s data shows that relationship reversed for AI-generated work specifically: production is fast, and review has become the part that can’t keep pace. That single fact reframes what “good” engineering practice means. Good used to mean writing more, better code faster. It increasingly means having a review and trust process that can actually absorb the volume that faster writing now produces, without either rubber-stamping it or drowning under it.

Where exactly did the bottleneck move to?

From code production to code verification, and the size of that shift is large enough to show up clearly in real production data, not just in anecdotes. The May 2026 analysis of pull requests found AI-generated PRs waiting over five times longer for a reviewer to even pick them up than manually written work, and merging at less than half the rate once they do. That’s not developers being slower to write code. It’s the review stage becoming the place where volume outpaces capacity, exactly the pattern you’d expect once one side of a pipeline speeds up dramatically while the other side, human judgment about whether something’s actually right, doesn’t speed up at all.

There’s a second detail in that same dataset worth naming directly, because it cuts against an easy, comfortable read of the numbers: once reviewers do pick up an AI-generated PR, they move through it faster than a manually written one, not slower. That’s not necessarily a sign review has gotten more efficient. It’s consistent with reviewers giving AI-generated code a faster, shallower pass rather than the deeper scrutiny it might actually need, which is arguably the more concerning version of “the bottleneck moved,” not the reassuring one.

What does “good” actually look like this year, compared to a year ago?

A year ago, good mostly meant shipping fast: more code, more PRs, more velocity, with review treated as a secondary check that usually kept pace without much deliberate design. This year, given what the data shows about review capacity actually breaking under AI-generated volume, good has to mean something more specific: a deliberate process for deciding what needs careful review and what doesn’t, built before volume forces the decision under pressure. A team that’s still measuring itself primarily on how much code ships, without also tracking how much of it gets a real review versus a rushed one, is measuring the half of the pipeline that’s no longer the actual constraint.

What’s the specific technical shift worth naming, with sourcing?

Review and verification tooling has had to mature rapidly as agent-written code volume increased, precisely because the same 2026 data shows the old assumption, that review capacity would simply scale alongside production, didn’t hold. The acceptance-rate gap in that analysis, roughly 84% for manual work against roughly 33% for AI-generated work, is itself evidence of a system straining at exactly the seam this shift predicts: work arriving faster than the process built to validate it can absorb without either bottlenecking hard or cutting corners. Teams and tool vendors responding to that strain by investing in better review tooling, more structured verification steps, and clearer rules for what needs deep scrutiny versus what doesn’t, isn’t a hypothetical response to a future problem. It’s a response to a gap the data already shows is real and already large.

What changed in team structure as a result?

More of the actual working week shifted toward judgment calls, is this right, should this ship, what does this pattern of failures mean, and away from the mechanical act of typing code. That’s a natural consequence of the same bottleneck shift: if producing code is no longer the slow part, the time that used to go into production has to go somewhere, and the place it’s landing is the harder, less mechanical work of deciding whether what got produced is actually correct and worth trusting. That’s not a smaller job than writing code. For a lot of engineers, it’s a less familiar one, since judging someone (or something) else’s fast output at volume is a different skill than producing your own work carefully at a slower pace.

What’s a concrete marker separating teams handling this well from teams that aren’t?

Whether a team has a deliberate structure for deciding what needs careful review, or is relying on reviewers doing their best under volume that the 2026 data suggests is already outpacing what unaided human attention can sustain. A team letting every AI-generated PR compete equally for the same reviewer attention, with no tiering by risk or category, is the shape of team the acceptance-rate gap describes: overwhelmed on one side, shallow on the other. A team that’s built a real distinction, which categories of change get deep scrutiny and which can move faster under a narrower, deliberate rule, is positioned to keep the speed gains from AI-assisted production without inheriting the full cost of the review bottleneck the data shows is already real. That’s a reasoned expectation given what the data shows about where the strain concentrates, not a separately measured claim on its own.

One dated example, anchoring the recap

The clearest single anchor for this whole shift is that same May 2026 finding: AI-generated pull requests waiting over 16 hours on average before review, against roughly 200 minutes for manually written work, drawn from an analysis spanning 8.1 million pull requests across nearly 5,000 engineering teams. That’s not a small or cherry-picked sample, and the gap it describes, over five times longer to even get picked up, is the concrete, dated evidence that the bottleneck genuinely moved this year, not a trend piece’s assertion that it did.

FAQ

Does this mean AI-generated code is worse than manually written code?

The data shown here is about review and merge dynamics, not a direct quality comparison. A lower acceptance rate could reflect genuine quality gaps, more cautious reviewers, or both; the dataset doesn’t isolate which. What it does show clearly is that the review stage is the part now under strain.

Is the review bottleneck a permanent shift, or a temporary growing pain?

The 2026 data captures a snapshot, not a prediction about next year. What it does establish is that, as of this analysis, review capacity hadn’t caught up with production speed, which is the actual claim this recap is built on.

Does faster review of AI-generated PRs, once picked up, mean review has gotten better?

Not necessarily, and it’s worth being skeptical of that read. Faster review time once a PR is picked up is also consistent with a shallower pass, which the same data’s overall pattern makes a real possibility worth investigating rather than assuming away.

What’s the actual takeaway for a team evaluating its own practices?

Track how much shipped code is getting a real, deliberate review versus a rushed one, not just how fast code is shipping. The 2026 data suggests the second number, without the first, is measuring the wrong half of the pipeline.

Where does a team start if it wants to close this gap?

By building a deliberate structure for what needs deep review versus what doesn’t, before volume forces that decision under the same pressure the acceptance-rate gap in this data reflects.

See what an AI-native roadmap health check would surface for your team. Book a demo.