When Code Gets Cheap, the Bottleneck Moves

The promise and the measured result

The promise was simple: if developers write code faster, software ships faster. DORA's tenth report on software delivery went looking for that result and did not find it. The 2024 DORA report (survey) asked nearly 3,000 working professionals about their AI use and their team's delivery. For every 25% increase in AI adoption it estimated a 1.5% reduction in delivery throughput, an effect it called "small, but likely negative", and said that "the negative impact on delivery stability is larger (an estimated 7.2% reduction for every 25% increase in AI adoption)".

The striking part is what improved alongside. The same 25% more adoption went with a 7.5% increase in documentation quality, 3.4% in code quality, 3.1% in code review speed and 1.3% in approval speed, plus a 1.8% decrease in code complexity. DORA called the combination surprising, because historically those process measures "lead to improvements in software delivery." This time they did not. The local measures got better and the system got worse.

DORA offered a mechanism, and labelled it a hypothesis: "since AI allows respondents to produce a much greater amount of code in the same amount of time, it is possible, even likely, that changelists are growing in size. DORA has consistently shown that larger changes are slower and more prone to creating instability."

A year later the picture had shifted, but only in part. The 2025 DORA report (survey), from 4,867 respondents surveyed between 13 June and 21 July 2025, put it this way early in the report: "AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability. This suggests that while teams are adapting for speed, their underlying systems have not yet evolved to safely manage AI-accelerated development."

Adoption was close to universal by then: 90% of respondents used AI at work, and more than 80% believed it had raised their productivity. Read the two years carefully. They are two cross-sectional surveys of different populations, so the change in the throughput sign is not a trend, and this book does not call it one. What held across both years is the instability finding. That is the result to plan around: whatever AI does to speed, it has so far been associated with less stable delivery.

Instability is not the price of speed. The obvious defence is that some instability is an acceptable cost of going faster. DORA tested that. On the idea that speed offsets instability, the 2025 report says: "We found no evidence of such a moderating effect … instability still has significant detrimental effects on crucial outcomes like product performance and burnout" (p. 41). Faster delivery did not buy the instability back.

Where the friction goes: deciding and verifying

If AI makes code cheaper to produce, where does the effort go? DORA's 2025 answer is the clearest single statement of this chapter's argument: "For an individual, friction doesn't vanish so much as move: It shifts from manual grind to deciding and verifying, possibly in the form of prompt iteration, result vetting, and assessing code that looks remarkably similar to correct code" (p. 40). The same page warns that "an increase in change volume without a corresponding set of evolved guardrails, roles, and 'golden paths' could increase verification and coordination costs."

Two more DORA lines locate the problem. First, AI's benefit lands where the work is typed, not where it is integrated: "As of now, AI tends to turn up at the keyboard, which can help explain why code quality and productivity benefit, but friction, burnout, and instability may not. They may reside beyond the individual's purview and be tied more directly to how the organization is wired" (p. 39). Second, the gains leak away: "Without this foundation, AI creates localized pockets of productivity that are often lost to downstream chaos" (p. 3).

And DORA names the mechanism that turns local gains into instability, this time in its analysis of version control: "AI use is also associated with a higher degree of software instability. We have hypothesized that this is likely, in part, because it is harder to review larger batches of code" (p. 57). More frequent use of rollback amplified AI's effect on team performance, but the report is explicit that "rollback reliance does not directly reduce instability". It helps teams undo what got through; it does not stop it getting through.

Practitioners reported the same shape before the surveys did. Google's research blog, describing its internal tools in June 2024, wrote that the "code author increasingly becomes a reviewer" (Google Research, T3). The Thoughtworks Technology Radar kept "complacency with AI-generated code" in its Hold ring for three editions. In October 2024 it asked whether a reported rise in pull-request merge rate was good news, or whether "people are merging larger pull requests faster because they trust the AI results too much." By November 2025 it had generalised: "speeding up one part of the workflow increases pressure on the others." That is a practitioner opinion, not a measurement, but it is the same diagnosis.

The verification burden also shows up in how developers feel about the output. In DORA 2025, 30% reported little or no trust in the quality of AI-generated code. In the Stack Overflow 2025 developer survey (survey), a self-selected sample of about 49,000 (about 33,000 answered the trust question), 46% distrusted the accuracy of AI tools and only 3.1% highly trusted it. The most-cited frustration, at 66%, was "AI solutions that are almost right, but not quite", and 45.2% said "Debugging AI-generated code is more time-consuming". Code that is almost right is the hardest kind to verify. That cost does not shrink when generation gets cheaper; it grows with every extra line generated.

The queue, in telemetry

Surveys say where friction goes. Engineering-analytics vendors, who read the version-control and ticketing data of their customers, show the queue forming. Their numbers are pooled vendor telemetry and correlational, so this book takes their direction and not their magnitudes. Faros's three reports and LinearB's benchmarks point the same way: more pull requests, bigger pull requests, longer waits for review, and, in Faros's data, more merges with no review at all.

What the box supports is a direction, and it is the direction DORA's hypothesis predicts. Generation went up; the work arriving at review got bigger; the time it spent waiting there grew; and a growing share went through with no review at all. None of these reports measures review depth, so they cannot say how much review was deferred, rushed or skipped. The rise in merges with no review at all shows that at least some was skipped.

Wait time and active time are different numbers. Not every vendor saw review get slower. Jellyfish, another analytics vendor (June 2025; 2.16 million merged PRs from 259 companies, Copilot users only, T3), found average cycle time in Q2 2025 falling from 95.5 to 83.8 hours, with 8.6 hours saved in coding and 5.1 hours saved in review. LinearB's own table shows AI-assisted (not agentic) PRs clearing review faster than unassisted ones at the 75th percentile, 3.2 against 4.2 hours.

Both observations can be true at once. Queue time and pickup time grow with the volume and size of agent-written PRs, while the active time a reviewer spends on each PR can fall, especially with assisted rather than agentic work. Shallow or skipped review is a third explanation, and the unreviewed-merge figures show that skipping, at least, is not hypothetical. The practical consequence is that "review time" is not one metric. If you measure only active review effort you can watch it fall while the queue in front of it grows. Measure wait time and active time separately, and measure agentic PRs separately from assisted ones. Chapter 7, Code Review, returns to this when it designs the review process itself, and the wiki's note on review queues for agent output covers the queue mechanics.

Amdahl's arithmetic

There is a structural reason a coding speed-up cannot carry delivery on its own, and it needs no survey: coding is a minority of the time between an idea and a release. Bain's 2025 technology report (consultancy, survey-based) puts it plainly: "writing and testing code only accounts for about 25% to 35% of the time from initial idea to product launch". Atlassian's 2025 developer-experience survey (vendor survey, self-reported) of 3,500 developers and managers found that "Developers only spend 16% of their time coding, and coding is not a friction point for developers." The same survey shows the offset directly: 68% of respondents said AI saved them more than 10 hours a week, while 50% said they lost 10 or more hours a week to non-coding tasks, which the report puts down largely to organisational inefficiencies. Time won at the keyboard was spent again elsewhere. DX (vendor, T3), citing a Microsoft Research study, puts coding at "about 14%" of developer time. These are different measures (share of lead time versus share of a developer's week), and none is precise. All of them say the same thing: most of the clock runs outside the editor.

Amdahl's law turns that into a ceiling. If a segment is a fraction of the total, speeding up only that segment can never save more than that fraction. The worked example below uses illustrative arithmetic, with no organisation behind it: a lead time of 100 units, of which coding (Bain's "writing and testing") is 30 and review is 10.

Illustrative arithmetic. Lead time = 100 units.

Scenario                               Coding  Review  Rest   Total  Change
A. Baseline (coding = 30%)              30.0    10.0   60.0   100.0     --
B. Coding 2x faster                     15.0    10.0   60.0    85.0  -15.0%
C. Coding infinitely fast                0.0    10.0   60.0    70.0  -30.0%
D. As B, review time +91%               15.0    19.1   60.0    94.1   -5.9%
E. As D, but coding = 16% at baseline    8.0    19.1   74.0   101.1   +1.1%

Review +91% = 10.0 x 1.91 = 19.1 (the Faros 2025 review-time figure,
used here only as an illustrative input).

Row B is the vendor pitch: double coding speed and lead time falls by 15%. Row C is the ceiling: even an infinitely fast coder cuts lead time by at most 30%, because the other 70 units are untouched. Row D asks what happens if larger batches push review time up by the 91% Faros reported for high-adoption teams in 2025, a vendor figure used here only as an input, not as a measured outcome. Review grows from 10 units to 19.1, and those 9.1 points take back most of the 15-point gain. Row E repeats the calculation with coding at the 16% Atlassian reported, treating a share of the working week as if it were a share of lead time, which it is not: now the coding gain is 8 points, the review growth is still 9.1, and the system is slightly slower than before AI arrived.

The numbers are deliberately simple, and the real system has more segments (testing, CI, release, waiting for decisions) that can grow too. But the shape survives any choice of inputs: a speed-up confined to a minority segment has a hard ceiling, and any growth in the segments downstream of it is paid out of that ceiling. Faros cited the same law in its own report. Bain drew the same conclusion: "If AI speeds up coding, then code review, integration, and release must speed up as well to avoid bottlenecks." The wiki's page on the cost of human review works through how that downstream line item is priced, and the chapter on economics, risk and measurement builds the full cost model.

Phase-level evidence: when generation stops being the constraint

The surveys and telemetry describe whole organisations. The sharpest evidence that the constraint moves comes from teams that pushed AI generation hard inside one phase and wrote down what limited them. In both company cases below the answer was review, and DX's cross-company data shows the same ceiling.

Google's migrations throttled generation. Google's engineers used an LLM pipeline to migrate test code from JUnit 3 to JUnit 4: 5,359 files and more than 149,000 lines in three months (Nikolov et al., 2025, T2). The team could generate changes faster than people could review them, so it limited the number of changelists sent each week to avoid overwhelming reviewers. The authors are also explicit that the model was not the system: "The use of LLMs alone through simple prompting is not sufficient for anything but the simplest of migrations." The pipeline around the model, and the humans reviewing its output, set the pace. The case studies chapter reads this migration in full.

Spotify said it out loud. Spotify Engineering's recap of a June 2026 conference talk by its Chief Architect carries the chapter's thesis as its title: "Coding is no longer the constraint". More than 99% of Spotify's engineers used AI coding tools weekly and 94% reported being more productive (as of June 2026). Pull-request frequency rose 76%, and the recap draws the consequence in one line: "The flip side: we now have 76% more PRs to review." The recap does not say review capacity grew to match; a 76% rise in work entering review without it is the queue from the previous section, seen from inside one company. Spotify also runs one of the strongest L3 maintenance cases on record, its background coding agent Honk (the pattern is covered in the wiki under background coding agents). Even at a company that far along, the constraint it reports is review, not generation.

DX's longitudinal data shows the same ceiling across companies. DX, another engineering-analytics vendor, tracked more than 400 companies from November 2024 to February 2026. AI usage rose 65%; median pull-request throughput rose 7.76%. Its own reading is that "AI is a local optimizer", and that "Global optimization requires fixing the human and systemic processes surrounding the code."

Put the three side by side and the pattern is consistent. Where generation is pushed, the first thing to saturate is the human who has to read the result. Usage that rises 65% buys a single-digit median throughput gain; a migration that could run faster is held to review speed; a company with near-universal adoption reports its new problem as review volume. The generator-side gain is real. The system-side gain is capped by verification, which is the subject of the wiki's concept page on the generator-verifier gap.

The pilot that looked like a success

If the constraint is downstream, a pilot that counts only upstream output will report success while the system stands still. One case in the public record shows exactly that.

Stanford's Software Engineering Productivity research group presented results from git histories across more than 600 companies and more than 100,000 engineers (Denisov-Blanch, September 2025 slides, T3). One anonymous company in that data adopted an AI coding assistant. Its pull-request count rose 13.6%. Measured by the group's quality-adjusted metric, "effective output" rose 1%. Code quality fell 9%, and rework rose 2.6 times (p < 0.01). The slide asks the question every pilot owner should ask: "Is this a failed AI coding assistant pilot?"

The case is anonymous and the method unpublished, so it carries an illustration, not a statistic. What it illustrates is the measurement trap this chapter predicts. A pilot judged on PR count would have been declared a 13.6% win and scaled. The same pilot judged on output adjusted for quality and rework was close to a wash, with 2.6 times the rework to pay for. Nothing about the tool differed between the two verdicts. Only the metric did.

The same gap shows up at the top of large companies. In a June 2025 interview, Google's CEO set the share of code that uses AI-generated suggestions, about 30% by Google's earlier statements, apart from what he called "the most important metric": engineering velocity, estimated at 10% and described as a "tough measure" with no further definition published (Lex Fridman Podcast transcript, T4). Volume metrics and flow metrics answer different questions. This book never uses the first as evidence for the second. Chapter 17, Measuring Success and When to Roll Back, sets out which flow and stability metrics to pair for every phase you change.

Where the constraint goes next

The evidence in this chapter supports one claim strongly: once generation is cheap, the constraint sits in verification. That means review first, then testing, then the integration and release of larger batches. It is where DORA puts the friction, where the vendor telemetry shows the queue, and where the migration teams hit their limit.

The next candidate is less settled, and this book says so. Deciding what to build, meaning requirements, specifications and product judgement, is argued to be the constraint that follows verification. DORA's capabilities model gives that argument its strongest support: "in the absence of a user-centric focus, AI adoption has a negative impact on team performance" (2025 report, pp. 60–61). The friction quote above also names "deciding" alongside "verifying". But no study in this book's evidence base measures requirements as the binding constraint in an AI-assisted organisation. Treat it as a reasoned expectation, not a finding.

DORA's remedy is to find the actual constraint before choosing where AI goes. Its value-stream chapter gives the example directly: a team "may discover, through mapping, that code reviews are a significant bottleneck. With this insight, they can decide to apply AI to improve the code review process, rather than using AI to simply generate more code that will only exacerbate the bottleneck" (pp. 74–76). That sentence is the practical form of this chapter's argument. Speeding up the phase that is not the constraint does not raise output. It lengthens the queue in front of the phase that is.

DORA's own capabilities point the same way. Working in small batches amplified AI's benefit to product performance and reduced friction, and it carries a named cost: "AI adoption's benefits for individual effectiveness are slightly reduced in teams that are working in small batches." That is the trade worth making. A slightly smaller individual gain is what it costs to keep each change reviewable.

The maturity model in the next chapter turns this into a rule of thumb, labelled there as the book's proposal: run Coding at most one level above the lower of Review and Testing (the maturity model's rules). The supporting data are the correlational telemetry and DORA's batch-size mechanism above, so it is a heuristic, not a law. Its logic, though, is this chapter's: a coding phase that outruns its verifiers produces more PRs, bigger PRs, longer review, more unreviewed merges and more instability. Chapter 7, Code Review, and Chapter 8, Testing & Verification, show how to raise the verifying phases first. The wiki's essay on the AI-native SDLC artifact chain traces how each phase's output becomes the next phase's input.