Generation stopped being the scarce resource in software delivery some time ago, and most organisations have not updated their accounting to reflect it. In an AI-native engineering organisation the binding constraint is verification capacity — the ability to decide, per change, whether the thing is correct — not generation capacity, which is abundant at the margin. Bill Staples states the arithmetic directly: the correct economic unit is cost per accepted change, aggregating generation, environment setup, context, verification, review, remediation and governance, and AI collapses the generation term while every other term stays where it was [1]. An organisation that makes generation ten times faster while leaving CI, review and validation untouched does not become ten times faster. It moves the queue [1]. Staples names the mechanism rather than treating it as a tooling inconvenience — it is the theory of constraints, and the constraint has changed location.
That single relocation reorganises every downstream decision. Headcount plans are still written against output, budgets are still set against inference spend, and performance expectations are still expressed in merged pull requests. Each of those was a reasonable proxy when the constrained resource was the engineer typing the change. None of them is a proxy now. The organisation's delivered value is bounded by how much change it can accept, and acceptance is a property of the verification system, not of the authoring system.
A caveat before the argument. Several figures below are company self-reports, vendor reports, consultancy data or secondary press, and they are labelled as such where they appear. They are used to locate where effects fall, not as a current measurement of your organisation.
Builder and judge
Separation of duties is an accounting control, and it survives this transition for the same reason it survived the last one: the person who produced a thing cannot be the person who certifies it. Certification requires independent judgement about correctness, and a person who has just spent an hour producing a large diff has spent the attention that judgement consumes. At generation speeds this stops being a nicety and becomes arithmetic — the reviewing half of the job grows at the same rate as the authoring half, while the attention available to do it does not.
The clearest measurement of what happens when the requirement is dropped comes from the Microsoft rollout study, which is observational rather than experimental and covers tens of thousands of engineers: 461 days before the mandate window and 115 days after it [7]. The CausalImpact estimate puts merged pull requests per engineer per day 24.0% higher (95% CI +14.5% to +33.7%); in the cohort breakdown the lift is 11.4% for Claude Code users (95% CI +9.4% to +13.6%) and 24.9% for Copilot CLI (95% CI +23.0% to +26.8%), reaching 50.1% for engineers using Claude Code for five or more days [7]. The authors are explicit that a merged pull request is a proxy for output, not for delivered value [7]. Note the wording: the study measures output, not the share of output that went through review, and not the share of merged work accepted without rework. Those are exactly the numbers a business case built on merged pull requests does not contain.
Attention, rather than intent, is what actually breaks. Across 8.1 million pull requests and more than 4,800 teams, agentic pull requests waited 17.6 hours for a first reviewer against 3.4 hours unassisted [6]. The p75 review time was 6.4 hours for agentic work and 3.2 hours for AI-assisted work, against 4.2 hours unassisted, and the p75 pull request size was 408 lines for AI-involved pull requests against 157 unassisted, with agentic work at 293 [6]. Agentic change is therefore both larger and slower to attract attention than ordinary change, which is the opposite of what a higher generation rate implies. Faros AI, across 22,000 developers and more than 4,000 teams, found the same shape from the other side of the pipeline: throughput up 33.7% in task throughput per developer and 66.2% on epics per developer, while time in review rose 441%, bugs per developer rose 54%, incidents per pull request rose 242.7%, pull requests merged with no review rose 31.3% and pull request size rose 51.3% [8]. The deterioration appeared regardless of baseline engineering maturity [8], which rules out the comfortable explanation that well-run teams simply absorb it.
There is one published attempt to measure the other direction — what happens when you enforce the requirement rather than drop it. At Anthropic, after multi-agent review was deployed into the pipeline, the share of pull requests receiving substantive comments rose from 16% to 54%, with fewer than 1% of findings marked incorrect by engineers [16]; a separate vendor account describes the other side of the same change — new review agents ran in shadow mode, so a human confirmed their findings before they reached a report [11]. That is a measured improvement, bought with process and tooling rather than with models. It is also the only figure in this series that describes verification capacity increasing, and it required an existing, functioning review system to attach the proof requirement to.
The organisational unit that scales is therefore not the engineer who produces; it is the pair plus the substrate. One person cannot be both at this speed, and the ratio between the two is not a matter of seniority or care. It is a matter of where the organisation's scarce hours are spent.
The unit economics
Cost per accepted change is the right unit precisely because it refuses to let the cheap term hide the expensive ones [1]. Broken out, it looks like this.
| Term in the unit of work | What AI does to it | What the change has to be offset by |
|---|---|---|
| Generation | Collapses the marginal cost of the first draft [1] | Nothing — this is the only term that improves |
| Environment setup and CI | Adds load; merged pull requests rose 24% (95% CI +14.5% to +33.7%) — the study contains no CI-time metric [7] | Faster, pre-warmed, isolated builds [10] |
| Context assembly | Moves from the author's head into retrieval and repository tooling | Cheap retrieval that does not require a human to reconstruct intent |
| Verification and review | Does not improve; reviewer attention becomes the queue | Sampled review, agent-proven findings, executable checks [11][16] |
| Remediation and refinement | Grows — roughly 60% of an agentic task's cost sits after the first successful call [14] | Iteration caps and a return-to-human rule [10] |
| Governance and provenance | Grows with volume | Branch protection, attribution, spend ceilings expressed as rules |
The headline saving is real and it is smaller than it looks, because it applies to one term out of seven [1]. What the industry reports instead is the growth in the terms that were never compressed. Consultancy data puts refinement and re-verification at roughly 60% of the cost of an agentic task, with 93% of organisations exceeding their AI budgets [14]. DORA's finding on tokenmaxxing is the same result stated as a curve: organisations spending the most get only a modest throughput gain at ten times the spend, and roughly 30% distrust AI-generated code in general the output [5]. Those are not contradictory. They are the cost structure of a system whose bottleneck is verification: paying for inference buys generation, and generation is not the constraint.
Amplitude's internal programme, reported as a company self-report, is the instructive counter-example because it shows where the gain actually lives. Over a six-month internal overhaul they shipped three times as many pull requests while monthly bugs fell from 715 to 319, cut pull request cycle time from 5.2 hours to 44 minutes, and took frontend CI from roughly 30 minutes to 3–4 minutes [9]. Read the list carefully: none of those numbers measures model capability; two are pipeline metrics and two are defect metrics. The gains followed their own infrastructure work, not agent distribution [9], which is exactly what the cost-per-accepted-change model predicts and exactly what a throughput narrative leaves out.
Budget behaviour follows the same fault line. Budgets are still constructed against tokens, because tokens were the visible line item during the adoption phase, and 93% of organisations overspent against them anyway [14]. A budget attached to the term you have already collapsed cannot be right; the correction is a change of denominator, not a forecasting improvement. Price the plan in reviewer hours and CI minutes, because those are the terms that will set the rate of accepted change.
The consequence is an uncomfortable one for a generation business. The marginal accepted change is now priced in senior judgement, and senior judgement does not respond to inference spend. That is a capacity constraint, and it is the subject of the two sections that follow.
What an ROI case assumes
DORA's J-curve describes a temporary productivity dip with three named causes — the learning curve, the verification tax and pipeline adaptation — framed as the tuition cost of transformation [2]. Any credible ROI case must contain that dip explicitly, because the dip arrives before the return and the return arrives after it. DORA’s illustrative worked example for a 500-person organisation with a fully loaded salary of $176,000 per head returns $11.6M on an $8.4M investment, roughly 39% ROI with an approximately eight-month payback [2]. The report’s authors call it “a high-uncertainty estimate meant to spark a conversation, rather than a rigid mathematical formula”. Those are modelled figures from a real study, and they are also a description of an organisation that funded its verification capacity through the dip and arrived on the far side.
What most business cases omit is the second line: the instability tax. DORA's worked example also quantifies $344,000 of negative downtime impact (a model assumption — $100K/hour × 4 hours of recovery, not a measurement) as change failure rate moved from 5% to 6% [2]. A case built on throughput alone does not contain that line at all, because a case built on throughput alone assumes that faster change does not change the probability that change breaks something. A one-point move in a percentage is not a rounding artefact at 500-person scale; it is a budget line.
The independent survey evidence points the same way. In the DORA 2025 State report, across roughly 5,000 professionals, 90% reported using AI at work and more than 80% reported higher productivity — but 30% reported little or no trust in generated code, and while AI showed a positive relationship with delivery throughput it still showed a negative relationship with delivery stability [3]. The earlier wave found the stability effect at scale: a 25% increase in AI adoption was associated with a 7.2% reduction in delivery stability [4]. Throughput gains and stability losses are being measured simultaneously, by the same methodology, across consecutive years. Treating the first without the second is not a simplification, it is a choice of which half of the data to believe.
A third assumption hides in the word "accepted". The security pass rates are not encouraging. Veracode's spring 2026 snapshot, across more than 150 models, put the security pass rate at about 55% [13]. Over the same period, syntax correctness in that work rose to roughly 95% [13] — the 50% baseline belongs to the first report of the series. Veracode's summer 2026 snapshot, across more than 100 models, put the security pass rate at 56%, with roughly 44% of tasks producing vulnerable code, an XSS pass rate of 15%, and pass rates of 30% for Java and 63% for Python [12]. The quality metrics that improve are the ones that measure whether the output is well-formed. The one that measures whether it is safe has not moved [12][13]. An ROI case that assumes generated code is roughly right has assumed past the only measurement that matters here.
So the stabilisation cost — the review capacity, test depth and CI latency that must be funded during the dip, before the payback arrives — is the item a business case tends to leave out. DORA names the dip as tuition [2]; tuition is a cost, and a case that books the benefit at the eight-month payback mark and the tuition nowhere is not conservative, it is simply wrong.
Ask two questions of any ROI case before you accept it. What change failure rate does it assume, and what is the dollar value of a one-point move in that rate [2]? And which verification investment is funded during the dip, from which budget line? A case that cannot answer both is a throughput case wearing an ROI label.
Where ADLC wins and where it does not
The dividing line is not domain knowledge. It is whether correctness already has an executable definition in your substrate — a test that runs, a property that can be checked, a diff small enough for a human to hold in their head.
| Work type | Verdict | Why |
|---|---|---|
| Greenfield work | Strong fit | Correctness is defined by the specification you are writing, so the specification can become the check; there is no inherited behaviour to regress |
| Mechanical migrations | Strong fit | The definition of done is a diff against a mechanical rule, which is exactly the shape agents execute well; Stripe reports agents performing best on bounded work such as upgrades and configuration [10] |
| Templated replication | Strong fit | One accepted instance becomes the template and the check for every subsequent instance; the acceptance rate of instance one is the whole business case [6] |
| High-volume triage | Fit with a caveat | Classification is bounded and revertible, but the reporting agent must stay inside the verification loop or triage quality becomes unobservable |
| Legacy code | Weak fit | Correctness is implicit in behaviour nobody wrote down; PR size and review time are where this shows first [6][8] |
| Regulated change | Weak fit | Every change carries an audit obligation, so acceptance means producing evidence rather than producing a merge; incidents per pull request rising 242.7% is not an acceptable mode here [8] |
| Cryptography and standard-mandated correctness | Poor fit | Verification requires expertise that cannot be sampled, and the cost of a wrong answer is not symmetric with the cost of a slow one [12] |
The organisations reporting the strongest results are not the ones that adopted agents earliest; they are the ones that already paid for the verification substrate. Stripe's agent fleet, described in secondary reporting, was running more than 1,000 agent pull requests per week at first disclosure and more than 1,300 per week as of February 2026, every one of them human-reviewed, on a base of more than three million tests, a limit of two CI iterations before a branch returns to a human, isolated pre-warmed environments and roughly 500 centrally served internal tools [10]. None of those infrastructure facts is a model fact. Anthropic reports that Claude authors about 80% of merged code and that the company ships eight times more code per quarter against the 2021–2025 period, and that 80% figure is a vendor self-report [11]. Google has said, in Sundar Pichai's own post in The Keyword, that roughly 75% of new code at the company is AI-generated and approved by engineers, up from about 50% last fall [15].
Read those three disclosures together and the pattern is consistent: each is an organisation that had already invested in tests, environments, internal tooling and review capacity, and each is now reporting an authoring-throughput effect on top of that base. That is a legitimate result. It is not evidence about an organisation that has not built the base, and treating it as such is the most common analytical error in this field — not dishonesty, just a missing denominator.
The hiring consequence
Verification capacity has two components and both are slow. The first is the substrate: test depth, CI latency, isolated environments, centrally served tooling [10]. The second is the reviewer — calibrated senior judgement that knows what a plausible wrong answer looks like in a specific codebase. Neither component responds to an increase in inference spend, and neither can be assembled inside a single planning cycle.
The demand signal is already in the numbers. First-reviewer wait for agentic work is 17.6 hours against 3.4 hours unassisted [6]. Median review time rose 441% in a sample of more than 4,000 teams [8]. Merged pull requests per engineer per day at Microsoft rose 24.0% (95% CI +14.5% to +33.7%), with a cohort breakdown of 11.4% for Claude Code and 24.9% for Copilot CLI, and a dose-response reaching +50.1% for engineers using Claude Code for five or more days [7]. Where an organisation has built multi-agent review into the pipeline, the reported result was the share of pull requests with substantive comments rising from 16% to 54%, with fewer than 1% of findings marked incorrect by engineers [16].
Read together, these describe a market for senior engineering attention that has tightened without an obvious valve. When generation is abundant, the senior engineer's hour becomes the scarcest input in the delivery system, and every hour spent producing change is an hour not spent judging change. The obvious response — hire more producers — makes the constraint worse, because it increases the volume arriving at a review system that has not grown. The response the evidence supports is to move judgement off the critical path wherever correctness is executable, and to buy back senior time for the changes where it is not [11].
There is a hiring consequence in the narrow sense as well: the roles that become valuable are the ones that make other people's output acceptable. Verification engineering, evaluation ownership, platform work that reduces CI latency — these are the roles whose demand rises when generation rises, and they are the roles least represented in the current intake plans of most organisations that adopted AI. The counter-intuitive part is that this is not a hiring boom. It is a reallocation, and it competes for the same budget as headcount in the visible, countable delivery roles.
Verdict on the hype
What is measurably real. Across independent datasets and consecutive years, the same direction appears: accepted changes fall even as merged changes rise — 32.7% versus 84.4% acceptance within 30 days across 8.1 million pull requests [6] — delivery stability degrades as adoption rises, first at 7.2% for a 25% increase in adoption [4] and then as a persistent negative relationship alongside a positive one on throughput [3]. Merged pull requests rise by about 24% (95% CI +14.5% to +33.7%) — the study contains no CI-time metric [7]. Across 22,000 developers, review time, defects, incidents per pull request, unreviewed merges and pull request size all rise together [8]. Security pass rates remain a minority result while syntax correctness approaches completeness [12][13]. Roughly 60% of an agentic task's cost sits after the first call, and 93% of organisations exceeded their AI budgets [14]. None of this is vendor collateral and none of it is ambiguous. The constraint moved, and where it moved is measurable.
What is real but conditional. The economics work where the substrate exists. DORA's illustrative 500-person example, with a fully loaded salary of $176,000 per head returns $11.6M on $8.4M at roughly 39% ROI with an approximately eight-month payback [2]. Amplitude reports three times the pull requests shipped with monthly bugs falling from 715 to 319 [9], as a company self-report. Stripe runs more than 1,300 human-reviewed agent pull requests per week [10], Anthropic reports Claude authoring about 80% of merged code [11] as a vendor self-report, and Google reports roughly 75% of new code AI-generated [15] in the CEO's own post. Each of these is a real measurement of a real organisation. Each is also a measurement of an organisation that had already built test depth, fast CI and review capacity — the conditions that produce the result are also the preconditions for it. Generalising from them to an organisation without those conditions is a category error rather than an extrapolation, and it is the error the entire genre of AI-ROI content rests on.
What is still marketing. Throughput multipliers presented as business outcomes. A 24% rise in merged pull requests [7] and eight times more code shipped per quarter [11] measure output, not delivered value — a distinction the Microsoft authors draw themselves when they state that a merged pull request is a proxy for output rather than value [7]. Token spend curves that flatten without moving cost per accepted change [5]. Adoption rates and AI-generated code shares offered as productivity statements [3][15]. The honest summary is that none of these figures is fabricated; they are correct measurements of a term that is not the one a board is trying to move.
None of this makes the technology a mistake. It makes the bottleneck legible, and a legible bottleneck is a tractable one. The decision rule that follows from the whole series is short: before funding an ADLC investment, state which term of cost per accepted change is currently binding [1]. If it is generation, buy agents and expect a direct return. If it is verification or review — which is where the independent datasets place large organisations today [3][4][6][7][8] — fund CI latency, test depth and review capacity first, because generation stopped being the expensive term the moment you adopted it, and a queue only moves when something downstream of it gets faster.
The series in six parts
- SDLC to ADLC: What the Viral Diagram Leaves Out — what changes structurally when agents supply part of the change queue, and which parts of the lifecycle do not move.
- The AI SDLC Hype Ledger: What the Evidence Actually Shows — the measurement gap between adoption figures and outcome figures, and why the two diverge.
- Where the Bottleneck Moved: Code Review After Coding Agents — how reviewer attention became the binding constraint and what the queue does when it is not widened.
- The Infrastructure an ADLC Actually Requires — the deterministic layer agents need: environments, tests, internal tooling, CI budgets.
- An ADLC Adoption Playbook: From Assistants to Agent-Driven Delivery — the maturity ladder, the baseline and in-flight metrics to capture, and a ninety-day sequence.
- Organizational Design and Unit Economics for an AI-Native SDLC — cost per accepted change, what an ROI case has to assume, and where ADLC wins and where it does not.
Sources
- Bill Staples, GitLab, "When code is abundant", 24 August 2026 — https://about.gitlab.com/blog/when-code-is-abundant/
- DORA, 2026 ROI of AI-assisted Software Development report, updated 22 April 2026; the dollar figures are quoted via InfoQ's write-up (https://infoq.com/news/2026/05/dora-roi-ai-assisted-dev-report/), worked examples in DORA's ROI calculator, with InfoQ coverage — https://dora.dev/ai/roi/report/ and https://www.infoq.com/news/2026/05/dora-roi-ai-assisted-dev-report/
- DORA, 2025 State of DevOps report announcement, ~5,000 professionals, September 2025 — https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
- DORA, State of DevOps 2024 — AI adoption vs. delivery stability — https://dora.dev/research/2024/dora-report/
- DORA, "Finding balance in the era of tokenmaxxing" — https://dora.dev/insights/finding-balance-in-the-era-of-tokenmaxxing/
- LinearB, Software Engineering Benchmarks Report and AI in software development — https://linearb.io/resources/software-engineering-benchmarks-report and https://linearb.io/library/ai-in-software-development
- Microsoft AI rollout study, arXiv:2607.01418v1, 1 July 2026, observational — https://arxiv.org/abs/2607.01418v1
- Faros AI, "AI Acceleration Whiplash" — https://www.faros.ai/research/ai-acceleration-whiplash The precise figures (33.7%, +441.5% median review time, +242.7% incidents per PR) are in the report PDF: https://pages.faros.ai/hubfs/AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf
- Amplitude, internal AI-native SDLC programme (company self-report, reported by GitLab) — https://about.gitlab.com/blog/when-code-is-abundant/
- Stripe Minions (secondary reporting) — https://rywalker.com/research/stripe-minions Stripe primary source: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents
- Anthropic, "How Anthropic secures its AI-native software development lifecycle" — https://claude.com/resources/articles/how-anthropic-secures-its-ai-native-software-development-lifecycle
- Veracode, 2026 GenAI Code Security Report, summer 2026 snapshot — https://www.veracode.com/blog/2026-genai-code-security-report-ai-risk
- Veracode, Spring 2026 GenAI Code Security Report — https://www.veracode.com/blog/spring-2026-genai-code-security
- Consultancy data on the agent cost stack (arXiv 2601.14470, via Yahoo Finance) — https://finance.yahoo.com/technology/ai/articles/agent-cost-stack-restructuring-billing-120424958.html
- Sundar Pichai, "Sundar Pichai shares news from Google Cloud Next 2026", The Keyword, 22 April 2026: 75% of all new code at Google is AI-generated (up from 50% last fall) — https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/cloud-next-2026-sundar-pichai/
- Anthropic, "Bringing Code Review to Claude Code" (multi-agent review; substantive comments 16% → 54%) — https://claude.com/resources/articles/code-review
