Where gains and losses occur
AI speeds up writing code, which was rarely the bottleneck. The constraint moves into review, testing, change approval and operations, so system-level gains come from fixing coordination and handoffs, not from generating code faster.
Written by
-
Benedikt Stemmildt Founder & Co-CEO
Updated:
Getting Started 2
Our position. We expect the bottleneck to move one step upstream of where you just fixed it (opens in a new tab). Walk one finished change to production and list every queue it waits in, because a factory shortens the build and does nothing for the wait around it (opens in a new tab).
Most of a change’s lead time is waiting, approvals and coordination, so faster coding saves only a small share of the whole.
Why does faster coding barely speed up delivery?
DX’s data across nearly 140,000 engineers shows annualized time lost to CI wait times, meeting bloat, context switching, and approval bottlenecks eclipses the time AI saves on coding; their conclusion is that AI is a local optimizer and global optimization requires fixing the human and systemic processes around the code (DX Q1 2026 AI-Assisted Engineering Impact Report). Atlassian’s numbers agree: coding and fixing issues is less than 25% of a developer’s day, the rest going to handoffs and context across the 150+ SaaS tools of a typical enterprise, and half of surveyed developers lose more than 10 hours a week to inefficiencies (Atlassian talk – Developer experience fireside (opens in a new tab); Atlassian – State of Developer Experience 2025 talk (opens in a new tab)).
Golo Roden sharpens the point (11 February 2026): the constraint was never the speed at which code is written but the speed at which understanding emerges, misunderstandings between domain experts and developers surface late and drive rework, and the same “end of developers” promise already failed with CASE tools, 4GLs, RAD, and low-code; his prescription is thinking tools like Amazon’s Working Backwards, because the ROI of understanding is invisible and manifests as the absence of problems (heise - Der wahre Engpass: Warum schnelleres Coden Projekte nicht beschleunigt (opens in a new tab)). The systems principle that 90-95% of productivity is determined by the system, not the worker, is the standing explanation for why individual tooling alone moves so little (DX - AI strategy playbook talk (opens in a new tab)).
Where does the bottleneck move?
The bottleneck then moves. Intercom, having doubled throughput, names review as its current constraint (Intercom talk - Doubling engineering throughput (opens in a new tab)). Review is tractable, though: Atlassian’s Rovo Dev agent performs an instant first-pass PR review and cut PR cycle time by 45% (Atlassian - State of Developer Experience 2025 talk (opens in a new tab)). Public examples target constraints outside code generation: Morgan Stanley’s legacy-code specification work, Zapier’s onboarding agents, and Spotify’s incident-context automation (DX, AI strategy playbook talk (opens in a new tab)).
The continuous delivery community puts a number on the ceiling. In its value stream figures, an average enterprise change takes about 281 days from idea to production, and about 32 of them are coding. Doubling coding speed therefore saves roughly 6% of lead time, while the other 88% is waiting, approvals and coordination (MinimumCD.org and DojoConsortium.org - Why Coordination, Not Coding, Sets the Pace (opens in a new tab), as of June 2026). Its advice follows from that ratio. Speeding up code creation before the downstream friction is gone mostly adds work in progress and risk, so process engineering comes before faster generation (MinimumCD.org and DojoConsortium.org - The New Bottleneck (opens in a new tab), as of September 2026).

Figure 1. Doubling coding speed takes 16 days off a 281-day change, about 6 percent, because the 249 days of waiting, approvals and coordination do not move. Drawn by hackers&wizards from the value stream figures in MinimumCD.org and DojoConsortium.org - Why Coordination, Not Coding, Sets the Pace (opens in a new tab), CC BY 4.0, as of June 2026.
The same guide names the forces that make coordination so expensive. A resource running at 90% utilization builds a queue about nine times its processing time, the relationship The Phoenix Project popularized. Each dependency on another team roughly halves the chance of delivering on time, so four dependencies leave about 6%, and removing one doubles the odds again. Intent decays at each handoff, by about half per transfer, in the tacit knowledge loss Lean Software Development describes. The guide groups the symptoms as contention for shared people and resources, coupling to another team’s output or approval, and lost coherence of shared understanding. Underneath all three it sees a knowledge dependency, which makes removing a dependency worth more than any coding speedup (MinimumCD.org and DojoConsortium.org - Why Coordination, Not Coding, Sets the Pace (opens in a new tab), as of June 2026).
Review is only one place the constraint lands. A map of the delivery lifecycle names five, each with its own signal. In discovery, the agent builds the wrong thing quickly, and the fix is to use AI to surface ambiguity and draft measurable acceptance criteria before work starts. In architecture, unclear service boundaries pile up at a few expert reviewers, until decision records, service maps and automated dependency rules carry the constraints instead. In testing, generated tests confirm the implementation rather than the user’s intent, so behavior tests have to be checked against known failure cases. In change management, a same-day fix waits for an approval window, which calls for controls inside the automation, standard risk classes, smaller batches and reliable rollback. In operations, the agent stalls because ownership and runbooks live in people’s heads, until they sit in a catalog the agent can search (MinimumCD.org and DojoConsortium.org - Where the Bottleneck Moves (opens in a new tab), as of September 2026).
Where do the real gains come from?
The gains that do occur come less from typing speed than from cognitive reallocation. Developers traditionally spend only 1-2 hours a day writing code, the rest going to toil; AI absorbs the mechanical work (boilerplate, lookups, scaffolding) and frees attention for architecture and problem selection, which practitioners report as the deeper shift behind their ~30% measured savings (From Trees to Forest: The Real Impact of AI on Developer Productivity (opens in a new tab)). Task-level measurements confirm the split: McKinsey’s internal data shows code documentation improving 45-50% and code generation 35-45% while high-complexity tasks gain under 10% (From Trees to Forest: The Real Impact of AI on Developer Productivity (opens in a new tab)), and in DX’s use-case ranking by share of developers saving at least an hour a week, the top case is interpretive rather than generative: stack trace analysis (DX – AI strategy playbook talk (opens in a new tab); Vibe-coding workflows (opens in a new tab)).
Where the freed time goes is shifting too: developers now name improving code quality as the top use of AI-saved time, an answer that was missing from the top ten in the previous edition of the survey (Atlassian - State of Developer Experience 2025 talk (opens in a new tab)). This only pays off under specific conditions: modular, well-tested codebases, experienced reviewers, and constant oversight of AI tendencies to drift off requirement and add unrequested features (From Trees to Forest: The Real Impact of AI on Developer Productivity (opens in a new tab)).
How do organizations respond to the gains?
At the organizational level the response to per-engineer gains is often to hire more, not fewer: demand for software is elastic, top organizations exhibit a rebound effect and expand headcount as AI raises per-engineer output (Refactoring - How Engineering Teams use AI (opens in a new tab)), and Zapier concluded from its own gains that it should be hiring faster than ever (DX - AI strategy playbook talk (opens in a new tab)). The emerging operating model is “delegate, review and own”: AI performs first-pass execution, engineers review, and humans own architecture and outcomes, moving engineers from creators to curators and the skill emphasis from prompt engineering to orchestration (How agentic AI will reshape engineering workflows in 2026 (opens in a new tab), February 2026, forecast).
Deployment is accelerating but immature: KPMG’s quarterly pulse survey of companies above $1 billion in revenue shows full production agent deployments jumping from 11% in Q1 2025 to 42% in Q3, while McKinsey’s State of AI study finds only 7% of organizations fully at scale with about 62% still experimenting or piloting; organizations pursuing more use cases systematically report better ROI, and coding is among the above-average performers (AI Consulting in Practice - NLW, Superintelligent (opens in a new tab), AI Engineer talk by the host of The AI Daily Brief, 18 December 2025).
Related
- Productivity evidence and quality: what controlled studies and telemetry measure about speed and defects.
- Measuring impact: how to instrument stage-level lead time so a fast step cannot hide a slow one.
- What moves adoption: the organizational conditions that turn access into use.
- Agentic continuous delivery: how one pipeline holds agent changes to the human bar.
- Moving away from Agile: why sprint-era team structures cap company-level gains.
Resources
Delivery practice
- The New Bottleneck (opens in a new tab) - Overview of the Agentic Continuous Delivery diagnosis section, arguing that coordination rather than coding sets delivery speed, CC BY 4.0.
- Where the Bottleneck Moves (opens in a new tab) - Map of five delivery bottlenecks that AI acceleration exposes, each with its warning signal and countermeasure, CC BY 4.0.
- Why Coordination, Not Coding, Sets the Pace (opens in a new tab) - Value stream figures and queueing, dependency and handoff models showing why coding is a small share of lead time, CC BY 4.0.