CircleCI published their 2026 State of Software Delivery report in March, built from 28 million CI/CD workflow runs across their platform. The number that got the coverage was: average daily workflow throughput up 59% year-over-year. Teams are running more pipelines, generating more code, merging more PRs. AI tooling at work.
The number that mostly didn't get coverage: for the median team, main branch throughput fell 7%. Feature branch activity up 15%. Main branch down 7%. Main branch success rates dropped to 70.8%, the lowest point in over five years, well below CircleCI's own benchmark of 90%.
More code is being written than ever. Less of it is shipping.
What Main Branch Throughput Actually Measures
Feature branches are where you develop. Main branch is where code becomes software. A successful workflow on main means a change cleared review, passed CI, and merged. If your main branch throughput falls while your feature branch activity rises, you have a pile of code that isn't landing anywhere.
This is a different finding from the review bottleneck story that's been circulating since early 2026. That story, which Faros.ai documented with two years of telemetry from 22,000 developers, is about review time going up 91% on AI-heavy teams because PR size grew 154%. PRs waiting longer, but eventually merging.
The CircleCI data is harder. It's not "merging slower." For the median team, the main branch is processing 7% fewer workflows than before they started using AI extensively. The pipeline is moving backward. And the success rate when you do get to main is at a five-year low, which means the code that does reach production is failing more often once it gets there.
59% more activity. 7% less delivery. That gap is where AI's productivity promise is disappearing.
The Bottleneck Never Was Writing Code
In March, Agoda's engineering team published a frank post framing this as a rediscovery of Fred Brooks. The argument: AI has raised individual developer output, but project-level delivery velocity has barely moved, because coding was never the bottleneck. Specs, alignment, code review, integration testing, and verification all take the same time they did before AI. With more code being generated, review actually takes longer. The constraint didn't shrink — it held still while the supply of unreviewed code grew.
A month later, Zendesk's engineering team gave that constraint a name: absorption capacity. The idea is specific and useful. When code generation is cheap, the bottleneck becomes the team's capacity to safely absorb rapid change — deciding what should be built, aligning implementation with existing architecture, establishing confidence through verification, and knowing whether the deployed change actually improved outcomes. Zendesk frames it explicitly as an organizational design problem. The winning question in 2026 is not "how fast can we write this?" but "how fast can we safely turn generated code into trusted software?"
The CircleCI numbers land harder in that context. A 59% increase in workflow runs means teams are pushing more code at a system that was never designed to absorb it at that rate. Feature branches pile up. Review queues grow. Confidence in each change drops because more is happening simultaneously and there's less context per PR. Main branch success rates fall. Throughput on main falls. The output looks fine at the individual level — developers are more active, generating more, closing more — and the system-level metric quietly moves in the wrong direction.
The 1-in-20 Exception
The top 5% of teams in CircleCI's dataset bucked this pattern dramatically. Their main branch throughput increased 26% while their overall workflow throughput grew 97%. They're generating more code and more of it is shipping. The median team is generating more code and less of it is shipping.
The CircleCI report doesn't spell out exactly what the top 5% are doing differently, but the pattern across similar analyses is consistent enough to be credible: they measure throughput rather than output. Lead time for changes, review queue depth, change failure rate, and mean time to restore — not PR count, not lines generated, not AI acceptance rate. When you're tracking whether code is moving through the pipeline and landing cleanly, you catch the absorption capacity problem before it compounds. You notice feature branch activity climbing while main is stagnant, and you act on it — tightening review criteria, investing in CI reliability, strengthening architectural guardrails — rather than celebrating the volume.
The top 5% also have something that most teams don't explicitly invest in: verification infrastructure designed for AI-assisted velocity. Strong CI. Comprehensive test coverage that makes each merge feel safe rather than brave. Observability that catches regressions quickly after deploy, enabling fast rollback when the 70.8% success rate catches up to you. Without that infrastructure, faster generation just means faster accumulation of unshipped or fragile code.
One in twenty teams has that infrastructure in place or built it in response to AI adoption. The other nineteen are experiencing the same workflow volume growth and less actual software coming out.
The Measurement You're Probably Running
If you're a developer using AI tools, the number you feel is generation speed. Tasks complete faster. The editor fills in more. Claude Code or Cursor runs a test-fix loop and the red CI line goes green. These signals are real and immediate. They're also measuring the wrong end of the pipeline.
The CircleCI finding is what happens when you aggregate that felt experience across 28 million workflow runs and ask what the pipeline looks like from the main branch's perspective. The individual experience is fast. The system-level outcome is that code is moving more slowly from branch to deployed software than it did before AI adoption.
None of this means the generation speed is fake or the tools aren't useful. It means the productivity gain is happening at one end and being consumed before it reaches the other end. If your team's deployment frequency, lead time, and main branch success rate aren't improving alongside your AI tooling adoption, the capacity to absorb what you're generating is where the gain is being absorbed.
Zendesk's framing is the right one: the question is whether your team can safely take in more meaningful change. The answer for the median team, based on CircleCI's 28 million workflows, is apparently not yet.
What to Actually Track
The tools most developers use to measure their own productivity — WakaTime, editor telemetry, commit counts — log from the keyboard outward. They capture generation. They do not capture whether that generation eventually ships.
The metrics that correlate with the top 5%'s outcomes point in the other direction: how long from first commit to main branch merge, how often main branch builds succeed, how quickly production incidents get resolved, whether feature branch lifespan is growing or shrinking. Those metrics are harder to get than coding hours, but they're measuring the end of the pipeline that the CircleCI data says is broken for most teams.
Your AI tools are solving the easy problem. The 7% main branch decline is the hard one.