The Bottleneck Moved

The Bottleneck Moved is the diagnosis the rest of this book treats. Making code cheaper to produce did not make software faster to ship, because production was one station on a line, and the stations after it still run at the speed of people reading carefully.

Key takeaways

• CircleCI's 2026 State of Software Delivery, published 18 February 2026 from 28,738,317 workflows, found that for the median team feature-branch throughput rose 15% while default-branch throughput fell 7%.
• DORA's State of AI-assisted Software Development 2025, published 24 September 2025, states the mechanism plainly: code still passes through testing and review queues, and the system was not designed to carry the gains.
• Faros AI, which sells engineering-productivity analytics, reports median time to first pull request review up 156.6% across its telemetry as of March 2026. Its conclusion supports its product, and its method is correlational.
• A bottleneck is the station with the lowest throughput, so speeding up any other station raises work in progress and nothing else. That is the whole of the diagnosis.
• Google's own measured study found change-list throughput per user-month up 17.5% with no statistically significant change in active coding time per change list. The gain came from somewhere other than typing.

Read this before Chapter 5, which turns reviewer attention into a capacity number, and before Chapter 11, which decides which of your delivery metrics still discriminate. The chapters between them are the operating model this diagnosis demands.

The dashboard is genuinely good news. Merged pull requests per engineer are up. Adoption is above eighty per cent, and nobody is asking for their old workflow back.

Then the delivery review happens. Cycle time from first commit to production is where it was two quarters ago, and the release train has slipped twice.

Somebody says the tooling is not working. The tooling is working exactly as sold. What is not working is the twelve metres of pipe downstream of it, which nobody widened.

Two throughput lines that stopped moving together

The cleanest public statement of the problem is a split. CircleCI's 2026 State of Software Delivery, published 18 February 2026 from an analysis of 28,738,317 CI/CD workflows in projects with at least two contributors, reports that for the median team feature-branch throughput rose 15% while default-branch throughput fell 7%.

Read those two numbers together. More work is being started and less work is arriving on the branch that ships. The gap between them is inventory.

The same report puts two numbers on the state of that branch. Main-branch success rate was 70.8%, which CircleCI describes as the lowest in over five years against a 90% benchmark, and median recovery to green was 72 minutes, up 13% year over year.

A default branch that is red more often, and slower to recover, is a narrower pipe than it was. Feature work is arriving faster at a narrower pipe.

What a bottleneck is, and why local speed does not help

A bottleneck is the station in a sequence with the lowest throughput. Its rate sets the rate of the whole line, no matter how fast the other stations run.

That definition has a consequence people find genuinely counter-intuitive. Improving a non-bottleneck station does not improve output. It increases the amount of unfinished work sitting in front of the bottleneck, which makes everything slower to finish and harder to see.

Authorship was a non-bottleneck station in most organisations. It felt like the constraint because it was the visible, effortful part, and because engineers experience their own typing rather than the queue their change enters afterwards.

So the honest reading of a flat cycle time is not that the tools failed. It is that they worked on the wrong station, and the organisation has just discovered where its real constraint always was.

Where the hours went, stage by stage

Faros AI's AI Engineering Report 2026 is the only public telemetry that follows a change through every stage, and its commercial position needs stating first: Faros AI sells engineering-productivity analytics, and the report's conclusion is that you cannot govern what you cannot see, which is what it sells. Its method is disclosed and worth holding on to. Two years of telemetry across 22,000 developers and more than 4,000 teams, per-company standardised metrics, Spearman rank correlation at p below 0.05, comparing each team's two lowest AI-adoption quarters against its two highest, with the analysis reflecting March 2026.

Those are between-quarter comparisons, not before-and-after experiments. Nothing in them demonstrates cause.

With that stated once, the stage timings are striking. Faros AI reports time a task spends in progress up 225.2%, time waiting up 81.8%, median time to first pull request review up 156.6%, and time in pull request review up 199.6% on the average and 441.5% at the median. Faros AI also reports time in quality assurance up 33.7%.

One figure comes with the publisher's own warning. Faros AI reports lead time from commit to production up 480.4% in roughly the 10% of its dataset that instruments deployment, and says to treat it directionally because the variance is high. I would not put that number in a board pack. The direction is the point.

DORA said the system was never built to carry the gains

The strongest survey evidence says the same thing from the other side of the room. DORA's State of AI-assisted Software Development 2025, published 24 September 2025 and fielded from 13 June to 21 July 2025 with 4,867 survey respondents and 78 in-depth interviews, puts it in one passage.

DORA writes that when developers use AI tools and write code faster, the code still needs to go through testing and review queues, followed by integration and deployment processes, and that the overall pace of delivery is unlikely to change significantly unless the surrounding workflows are updated for developers' new tools and increased speed. Then the sentence this book exists to answer: the system isn't designed to carry the gains, let alone amplify them.

That is a survey, self-reported, and DORA says so. It is also 4,867 people describing the same pipe.

DORA's own framing of AI's role is that it is an amplifier, magnifying the strengths of high-performing organisations and the dysfunctions of struggling ones. A queue is a dysfunction. It amplifies beautifully.

The one measured study that isolates the variable

Survey and telemetry both leave room for doubt about what changed. One study narrows it. Tabachnyk and colleagues at Google, in a paper dated 27 January 2026, report a difference-in-differences analysis over 36,000 treatment developers and 18,000 controls, measuring the effect of adopting natural-language code transformation in the IDE.

The result has three parts and the third is the interesting one. Change-list throughput per user-month rose 17.5%, with a 95% confidence interval of 15.9% to 19.0%. Investigation-session duration fell 3.6%. And there was no statistically significant change in active coding time per change list.

Read that last clause slowly. More changes per developer per month, and no measurable reduction in the time spent actively coding each one. The paper notes its analysis is observational and that the precise magnitude cannot be guaranteed.

The practical reading is that the unit of work got smaller and more numerous rather than individually quicker. That is a change in arrival rate at every downstream station, which is exactly the variable a queue is sensitive to.

What got faster, and what did not

The table below is the compact form of the diagnosis, with each row attributed, and it is the one page worth taking into a delivery review.

Two rows in that table are the whole book. The first row is the thing you bought. The fourth row is the thing you sell.

The queue arithmetic, worked through

The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

A platform team of twenty engineers used to open around forty pull requests a week and merge them within a day. Reviewer capacity was never planned, because it never needed to be: each engineer spent perhaps two hours a week reading other people's changes and it fitted inside the gaps.

Adoption lands and the team opens seventy a week, each one larger. Reviewer capacity did not change, because reviewing is still done by the same twenty people in the same gaps. Arrival rate rose by three quarters. Service rate did not move.

The result is not a proportional slowdown. It is a queue that grows without bound while arrivals exceed service, and the queue expresses itself as waiting time rather than as a refusal. Nobody says no. Things simply take eleven days.

Two side effects follow, and both are visible in the public telemetry. Some changes get merged unread, because the alternative is a stalled release. And the largest, riskiest changes wait longest, because a reviewer with forty minutes picks the small one.

The objection: this is a badly run team, not a new problem

The strongest version of this objection is that queues have always formed in weak organisations, and that a team with good hygiene will absorb the new volume. It deserves a serious answer, because two credible sources disagree about it.

DORA's amplifier framing partly supports the objection: strong organisations get more from AI, weak ones get their dysfunctions magnified. Faros AI reports the opposite in its telemetry, stating that high pre-AI engineering maturity offered no protection in its data. Faros AI also directly contests DORA's method, arguing that surveys cannot capture what happens downstream and that perception lags reality while telemetry does not. DORA has not published a reply.

I am not going to resolve that for you, and Chapter 11 is where the reader gets a rule for their own case. The part both sides agree on is enough to act on: the constraint is now downstream of authorship, and no amount of care at the keyboard moves it.

There is a cheaper test than the argument. Look at your own median time to first review over the last four quarters. If it doubled, hygiene is not your problem.

Three numbers to put on one page this week

Diagnosis has to end in instrumentation or it is a mood. Three numbers are enough to start, and all three are usually already in the tools you own.

Time from pull request opened to first substantive human comment, at the median and the ninetieth percentile, is the first. It is the queue's waiting time, and it is the single most sensitive indicator that arrival has outrun service. Google's own review guidance treats response time rather than total review time as the thing to manage, which is the right instinct.

The share of merged changes that received no human review is the second. Faros AI reports that share up 31.3%, and it is the number that tells you whether the queue is being absorbed or bypassed.

Default-branch health is the third: success rate, and time to recover when it goes red. That pair tells you whether the extra volume is arriving as value or as instability.

Collect all three at the team level, never at the individual level, and hold them for a quarter before changing anything. You cannot fix a queue you have not measured.

Chapter summary

Making code cheap to produce did not make software faster to ship, because authorship was almost never the station with the lowest throughput, and improving a non-bottleneck station raises work in progress rather than output. CircleCI's 2026 State of Software Delivery, published 18 February 2026 from 28,738,317 workflows, states the split most cleanly: for the median team, feature-branch throughput rose 15% while default-branch throughput fell 7%, with main-branch success at 70.8% and median recovery to green at 72 minutes, up 13% year over year. Faros AI, which sells engineering-productivity analytics and whose method is between-quarter Spearman correlation across 22,000 developers and more than 4,000 teams as of March 2026, reports median time to first review up 156.6%, time in review up 441.5% at the median, and lead time up 480.4% in the roughly 10% of its dataset that instruments deployment, a figure it asks readers to treat directionally. DORA's report of 24 September 2025, from 4,867 respondents and 78 interviews, gives the mechanism in its own words: code still goes through testing and review queues, and the system isn't designed to carry the gains. Google's difference-in-differences study of 27 January 2026 isolates the variable, finding change-list throughput per user-month up 17.5% with no statistically significant change in active coding time per change, meaning the unit of work multiplied rather than individually accelerated. Whether engineering maturity protects a team is genuinely contested, with DORA's amplifier finding and Faros AI's no-protection finding pointing opposite ways. Start with three team-level numbers: time to first review, share merged unread, and default-branch health.

The queue starts with what arrives at it, and what arrives at an agent is a description of a job. Chapter 2 is What a Specification Has to Contain Now, because the first place to spend the money you saved on typing is on the thing being typed from.