The 59% in that headline is not a feature-branch number. It measures the year-over-year increase in the average number of daily workflow runs across all CircleCI projects, on every branch, an aggregate average rather than anything branch-specific. CircleCI's own report puts the median team's total throughput increase at 4%, and the bottom quartile saw no measurable increase at all. So the framing everyone repeated is wrong in the usual way CI statistics go wrong: a mean got hauled upward by a small group of extreme users, and thousands of engineers read it as a description of their own week.
The underlying shape survives the correction, and it is more interesting than the headline. For the median team, feature-branch throughput rose 15% year over year. Main-branch throughput fell 7%. Work went up. Merges went down. That is the finding worth arguing about, and it holds after you strip out the flattering average.
What the median team actually saw
CircleCI published the report on February 18, 2026, built from 28,738,317 workflows run during September 2025, filtered to projects with at least two contributors and workflows that ran at least five times. The filter is sensible. It removes toy repos and one-shot pipelines, which is more hygiene than most vendor telemetry gets.
Inside that population, the distribution matters more than the mean. Fewer than 1 in 20 teams scaled code creation and code delivery at the same time. Even the top 10% grew main-branch throughput by only 1%. You have to reach the top 5% before main-branch throughput grows 26% alongside an 85% surge in feature-branch activity, with daily workflow runs going from 6.8 to 13.4, a 97% increase.
The stability numbers are where a practitioner should flinch. Main-branch success rate fell to 70.8%, the lowest in over five years, against CircleCI's recommended benchmark of 90%. Median recovery time to green was 72 minutes, up 13% year over year, with mid-sized companies approaching three hours.
Be careful reading those two together, because the temptation is to commit the same sin the 59% did. Nearly three in ten main-branch workflow runs ended red, which is not the same as three in ten merges breaking the trunk. Main-branch workflows include reruns, scheduled jobs and retries, and a failure can be a flake or a dead runner as easily as bad code. The 72 minutes is time back to green, not time anyone spent blocked; nobody measured who was waiting. What survives both caveats is still ugly. A trunk that fails almost a third of its runs and takes over an hour to recover is a validation problem, and no AI story is required to explain it.
Thoughtworks made the sharpest point about the report: throughput without stability is waste rather than productivity, and CircleCI stops short of examining why builds fail more often. The second half of that is the real complaint. The report is very good at counting workflows and nearly silent on causation.
The average is doing more work than the argument
Rob Bowley's critique is the one I keep coming back to, because it attacks the denominator. The top-5% cohort in CircleCI's data averages a CI pipeline duration of six seconds, which raises a fair question about whether those workflows represent development work at all. A six-second pipeline is a lint job, or a status check that returns before the runner finishes warming. It is not a test suite. When the cohort that doubled its delivery is running pipelines that fast, doubling is cheap.
There is a broader measurement problem underneath. Workflow count is a proxy for activity, not for delivery. It counts pipeline executions, not deployments, not released features, not anything a customer touched. A retry storm from a flaky integration test inflates the same counter as a genuine merge. So does an agent that opens a PR, watches it fail, pushes a fixup, and repeats. If AI-assisted development produces more churn per unit of shipped work, the metric climbs while delivery stays put, and the data as published cannot tell you which happened.
Then there is the population. This is single-vendor telemetry. It describes teams that used CircleCI in September 2025 against teams that used CircleCI a year earlier, and the published methodology does not say whether those are the same teams. Anyone who moved to GitHub Actions, Buildkite, or an in-house system during the window left the dataset, and anyone who arrived joined it. Cohort churn can move numbers like these without a single team changing its behavior. I cannot size that effect from the outside, and nothing in the published material shows CircleCI sizing it either.
The AI story is inferred, not measured
The report's framing points at AI-generated code as the cause. Rob Zuber, CircleCI's CTO, put it plainly: the teams realizing AI's benefits are using autonomous validation to run laps around competitors that can't validate AI-generated code at scale. Coherent story. It also sells CI. In the material I could reach, it is unsupported by any segmentation of the data, and I could not find a cut that isolates AI-assisted teams from everyone else. The causal claim rests on timing, not on measured tool usage.
The external evidence points several directions at once. DORA reports that 90% of technology professionals now use AI at work and over 80% believe it has increased their productivity. The 2025 DORA research found greater AI adoption correlating with simultaneous increases in delivery throughput and delivery instability. That already cuts against the simple story. In 2024, DORA's numbers went the other way: a 25% increase in AI adoption correlated with a 1.5% decrease in throughput and a 7.2% decrease in stability. I did not find a primary DORA document for those 2024 figures. They come through secondary coverage, and I treat them as weaker than the 2025 result. The throughput sign flipped between the two years. Only the instability finding held across both, which is the one that lines up with a 70.8% main-branch success rate.
METR's randomized trial is the other number people cite, and it deserves its scope stated in full. Sixteen experienced open-source developers took 19% longer to complete 246 issues when allowed to use early-2025 AI tools, primarily Cursor Pro with Claude 3.5 and 3.7 Sonnet, on repositories averaging over 22,000 stars and more than a million lines of code. The same developers had forecast a 24% speedup and still believed they had been sped up 20% afterward. The perception gap is the durable result. The 19% is sixteen people on codebases they knew intimately with tooling that is now over a year old, and anyone presenting it as a live measurement of current AI-assisted productivity is misusing it.
On code quality, GitClear and GitKraken analyzed 623 million code changes from 2023 to 2026 and found duplication up 81% with reuse operations down 70%. LeadDev, covering the same research, reports functional connectivity, meaning calls across files, down 35%. GitClear's own page returned a 403 when I tried to fetch it, so the finer year-by-year series circulating from it is not something I can check, and at least one figure in circulation uses a 2022 baseline that sits outside the 2023-2026 dataset.
The explanation the data cannot rule out
Here is the alternative reading nobody is testing. Falling main-branch workflow counts are consistent with fewer, larger merges. If review latency grew and batch sizes grew with it, you would see this exact signature: more feature-branch activity, fewer main-branch runs, a lower success rate when the big batches finally land. That is a different pathology from a jammed merge queue, and it calls for different fixes. Nothing in the published data separates them, because no source I found quantifies code review or merge-queue wait time directly. The mechanism everyone assumes is inference.
The closest available signal is the Merge Efficiency Ratio, which CircleCI defines as the number of feature-branch validation cycles it takes to move a change onto main. On your own CI data that reads as:
MER = feature_branch_workflows / main_branch_workflows
The ratio is my reading of their definition rather than a formula they publish, and they do not specify a window, so pick one and keep it fixed across comparisons.
Median teams run an MER of 3.9, against 2.6 for the top 5% and 1.3 for the top 20 organizations. Four feature-branch runs per merge is not a tooling win. It is rework that has not been named yet.
The picture also moved. CircleCI's Q2 2026 Pulse, published July 8, 2026, shows feature-branch throughput up 7.7% year over year with main-branch throughput flat rather than declining, and main-branch success recovering from 70.8% to 76.7%, still well short of the 90% benchmark. The spread widened: the median team ran roughly 1.7 main-branch workflows per day against 15.6 for top performers, a 9x gap up from 8x in Q1. One caveat on the Pulse. It describes data from March 2026, so the quarter labels are looser than they look, and I would not read the Q1-to-Q2 movement as a clean quarter-over-quarter delta.
Take the correction seriously and the practical instruction is narrow. Stop quoting the 59%. The two numbers that would have caught this on your own team a year early are main-branch success rate and MER, both computable today from data your CI already stores. If your trunk is green 70% of the time and you burn four feature runs per merge, the AI question is a distraction from a validation gap that was there before any of it.
