A workflow run is one pipeline execution, and the counter increments by the same amount for a merge, a rerun, a scheduled job or a retry after a flake [16][11]. That is what breaks the productivity reading of the divergence. Feature-branch throughput up 15% against main-branch throughput down 7% is a 22-point spread [3][6], and it fits both a world where more work reaches the trunk and a world where each change that reaches it takes more attempts. The dev.to analysis says so plainly: if AI-assisted development produces more churn per shipped change, the counter climbs while delivery stands still, and the published data cannot separate the two cases [17].
Now the top of the distribution, because that is where the mean comes from. Fewer than one team in twenty grew code creation and code delivery together [6]. The top decile grew main-branch throughput by 1% [7]. Only in the top 5% does main-branch throughput grow 26%, alongside an 85% rise in feature-branch activity and daily runs going from 6.8 to 13.4 [8]. Rob Bowley's critique goes after the denominator: that cohort averages a CI pipeline duration of six seconds [14]. Multiply it out and the elite cohort executes roughly 80 seconds of pipeline per day, 13.4 runs at six seconds each [3]. For their doubling to say anything about your delivery, your gate would have to be doing what theirs does, which the source characterises as a lint job or a status check rather than a test suite [15]. If your main-branch gate is a fifteen minute integration suite, the number does not transfer, and the arithmetic is why.
The stability figures deserve the same discipline. A 70.8% main-branch success rate means 29.2% of main-branch runs ended red [9][1], which sits 19.2 points under CircleCI's own recommended 90% [9][2]. Reruns, scheduled jobs and retries all count in that population, and a red can be a dead runner, so the figure describes run outcomes rather than three in ten merges breaking the trunk [11]. Median time back to green of 72 minutes, up 13% year over year, implies about 64 minutes a year earlier [10][5]. It measures recovery time alone; nobody measured how long anyone actually sat blocked waiting [12].
Credit where the method earns it. Filtering to projects with at least two contributors and workflows that ran at least five times strips out toy repos and one-shot pipelines before anything gets averaged [5]. That filtering step is what makes the gap a causal one rather than a statistical artifact. Thoughtworks' complaint is that throughput without stability is waste rather than productivity, and that the report stops short of asking why builds fail more often [13]. It is also single-vendor telemetry, and the published methodology does not establish that the teams measured in September 2025 are the teams measured a year earlier [18][4].
The comparison figure I would carry into a review is the median gain of 4%; the headline mean runs close to fifteen times that figure [4]. In my context the number worth instrumenting is attempts per merged change, which no workflow counter can produce, because the counter cannot tell a passing merge from the third try at one. Everything else in the report is a well-filtered census of pipeline executions [5][16], and a trunk that fails 29.2% of its runs is a validation problem that needs no story about agents to explain it [1][9].
