The AI productivity paradox occurs because accelerated code generation moves the delivery constraint downstream to review and verification, where capacity may not change, so measured developer gains fail to convert into organizational delivery speed.
TL;DR
Randomized trials and large telemetry datasets report higher individual or team output in their measured populations. Company-level delivery can remain flat when downstream verification does not absorb the added change volume. Engineering leaders should measure the conversion gap through lead time, deployment frequency, rework, and spend per merged change.
A CFO opens the quarterly review with a direct question: engineering approved a significant AI tooling budget, per-developer output rose on every dashboard, and the roadmap did not compress. The delivery dates that were supposed to move have not moved, and the board reads flat lead time as evidence the spend failed.
CTOs and engineering managers have to answer that question. Randomized trials and telemetry across tens of thousands of developers report higher output in their measured populations, but those findings do not establish universal individual speedup or organization-wide delivery gains. The organizational question begins after the individual effects covered in Augment Code's developer slowdown guide: whether measured output reaches the metrics a board can see.
Why the AI Productivity Paradox Shows Up as Slower Delivery
An enterprise that captures genuine per-developer savings from AI can still deliver more slowly because the savings accrue at the code generation stage. Delivery speed also depends on QA, integration testing, and release approval. Adding generation capacity upstream of a verification stage with fixed capacity leaves throughput capped and lengthens the queue in front of that stage. The organization receives more open pull requests and larger changes waiting longer for the same reviewers, with lead time unchanged.
That queue mechanism makes the developer the wrong unit of analysis for an ROI question. Faros AI, an engineering analytics vendor that sells the measurement layer this finding implies buyers need, published telemetry in July 2025 covering more than 10,000 developers across 1,255 teams. Its central finding, verbatim: "Any correlation between AI adoption and key performance metrics evaporates at the company level." Per-developer and per-team gains appear in the same dataset; the organization-level signal does not. The phrase "AI productivity paradox" comes from the title of that Faros report.
Faros's vendor telemetry does not evaluate tool quality or organizational budget allocation. Faros reported that per-developer output rose even though company-wide throughput, lead time, and incident resolution remained flat. The pattern is consistent with local speed accumulating as downstream queue depth.
The Bottleneck Moved Downstream to Review and Verification
Faros researchers observed the stall in review time. Developers on high-adoption teams complete 21% more tasks and merge 98% more pull requests. Review time on those pull requests rises 91%, average PR size grows 154%, and bugs per developer rise 9%. Every upstream measure rose. Human reviewers absorbed the added work through larger pull requests and longer review times.
Faros researchers found an association between larger changes and longer reviews. The association is correlational: the telemetry does not distinguish reviewers deferring work from reviewers reviewing more shallowly.
A 2026 enterprise study extended the evidence beyond the 2025 telemetry. He, Agarwal, Denisov-Blanch, Azaletskiy, Koyejo and Vasilescu tracked 802 developers and 196,212 pull requests at a company that mandated doubled output. Their paper is arXiv 2607.01904, version 1, submitted July 2, 2026, a preprint with no declared venue.
The study separates its result from its causal boundary:
- Study design: The panel runs from January 2024 through April 2026 and uses a staggered difference-in-differences design.
- Measured result: Per-capita throughput reached 2.09x the pre-mandate baseline by April 2026, with gains concentrated in newer code.
- Causal boundary: The company did not randomly assign adoption or usage intensity, so the authors interpret the result as implicating an adoption-and-use channel without claiming exact causal attribution.
Downstream, per-reviewer load roughly doubled, automated review overtook human review, and merge and revert rates held steady. The measured gain arrived alongside a larger review burden, showing higher reviewer load alongside higher measured throughput. The study does not establish a company-level delivery-speed gain, but it extends the evidence beyond claims based only on 2025 data. Relieving the constraint it locates means adding capacity at the verification stage, not upstream of it. Cosmos, Augment Code's unified cloud agents platform, generally available on paid plans, coordinates generation and verification in one system for that reason.
What Individual-Output Metrics Do Not Measure
Individual-output metrics and delivery metrics come from different instruments, and most AI adoption dashboards carry only the first kind. Google Cloud's DORA 2025 report, State of AI-Assisted Software Development, announced September 23, 2025, drew on two separate populations: a survey of nearly 5,000 technology professionals and more than 100 hours of qualitative data. In the survey, 90% report using AI at work, and more than 80% believe it raised their productivity. Respondents self-reported both figures, so they measure sentiment rather than throughput.
On throughput itself, the 2025 edition found a positive relationship with AI adoption, reversing the negative relationship DORA's 2024 edition reported. The negative relationship with delivery stability did not reverse: the 2025 edition reports that higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability. DORA frames the whole pattern by describing AI as an amplifier that magnifies both the strengths of high-performing organizations and the dysfunctions of struggling ones.
The cited peer-reviewed trials measure output rather than delivered value. Cui, Demirer, Jaffe, Musolff, Peng and Salz, in Management Science (DOI 10.1287/mnsc.2025.00535), ran three randomized controlled trials. The populations included 1,746 developers at Microsoft from September 2022 to April 2023, 320 at Accenture from July to December 2023, and 3,054 at an anonymous Fortune 100 company from September to October 2023.
Weekly pull requests rose 26.08% with a standard error of 10.3%. The outcome variables include code changes and builds, with pull requests and commits making up the code-change measures; no trial in the set measured delivered value. The gain also concentrated among the developers with the least tenure: short-tenure developers improved 27% to 39%, compared with 8% to 13% for long-tenure colleagues.
The two metric families identify the conversion gap when they are read against each other:
| Per-developer output metrics (what AI tools measure) | System-level delivery metrics (what delivery speed requires) |
|---|---|
| Pull requests merged per developer | Lead time from commit to production |
| Lines of code per week | Deployment frequency |
| Tasks completed per sprint | Change failure rate |
| Commits per developer | Mean time to restore |
| Build frequency | Rework rate |
| Self-reported productivity belief | Spend per merged change |
Executives who read only the left-column metrics will report success even when production lead time does not improve.
The Cost of Rework and Defects
Faros AI's Faros 2026 report draws on a different and larger population than the 2025 telemetry: 22,000 developers across more than 4,000 teams, over two years of telemetry. The full report sits behind a registration form, and it tracks metric change between each organization's own periods of lowest and highest AI adoption, not across calendar time. Moving from low to high adoption, bugs per PR are up 28.7%, incidents per PR up 242.7%, code churn up 861%, and deployments per week down 11.7% among the roughly 10% subset of teams with deployment instrumentation. The report's published takeaways add that pull requests merged without any review, human or agentic, are up 31.3%.
GitClear's GitClear quality report, covering 623 million analyzed changes from 2023 to 2026, found block duplication rising from 40.3 to 73.0 instances per million changed lines. The 2026 figure represents the year to date. A separate GitClear study from January 2026 complicates its own reading: heavy AI users out-produce non-users by 4 to 10x. GitClear attributes that cohort finding to who adopts most, so it does not establish a causal productivity effect.
These costs arise during review and after merge, outside per-seat accounting, which is why the budget conversation belongs on spend per merged change. Teams calculate it by dividing total engineering and AI spend for the period by changes that survive review and ship, counting rework and incident time in the numerator. Augment's Code Review examines pull requests and returns findings that an engineer or another agent can resolve. Cosmos Sessions preserve the conversation and auditable work, and delivery instrumentation is still what makes the metric calculable from one quarter to the next.
Rework, defect escape, and higher reviewer load can raise unit cost even where seat cost stays flat. Tracking spend per merged change alongside churn and quality metrics gives finance a number that moves when delivery improves. For vulnerability findings that enter this flow, security remediation can carry an alert into a reviewed code change when the scanner and repository workflow provide enough evidence for a fix.
What the Historical Record Says About Adoption Lags
The pattern has a documented history. Robert Solow wrote that "You can see the computer age everywhere but in the productivity statistics" in the New York Times Book Review, July 12, 1987, page 36. Writers commonly miscite the line to the New York Review of Books.
Brynjolfsson, Rock and Syverson formalized the resolution in The Productivity J-Curve, NBER Working Paper 25148, October 2018, published in American Economic Journal: Macroeconomics volume 13, issue 1, pages 333 to 372, January 2021. A general purpose technology demands large intangible complementary investments in process redesign and human capital. Because accounting expenses those investments instead of capitalizing them, measured productivity is understated during the build-out and overstated later.
AI coding adoption fits that model when an organization records the tool purchase as a current expense while review-capacity and process investments accumulate as less visible intangible assets. During that build-out, delivery metrics may dip before the complementary investments produce measurable output.
The individual level has its own well-known caution. The METR study found that 16 experienced maintainers took 19% longer across 246 tasks in mature open-source repositories they had each worked in for about five years. That study is arXiv 2507.09089, version 2, July 25, 2025, a preprint with no declared venue.
The figure is stale by its authors' own account. METR's February 2026 update reports that 30% to 50% of follow-up participants declined tasks they did not want to do without AI. The authors state that developers are likely more sped up by AI tools than the early-2025 estimate suggested, and they call their data very weak evidence for the size of the increase. Engineering leaders should limit individual-performance claims to the populations and tasks those studies measured; the organization-level constraint still depends on how additional output moves through review and release.
Where Executives Read This Wrong
Engineering leaders often carry these numbers into board conversations through interpretations that direct spending toward the wrong stage.
- Reading the J-curve dip as ROI failure: The early dip is the accounting signature of intangible investment in the Brynjolfsson, Rock and Syverson model. Judge the program by whether structural change is underway, not by two quarters of flat metrics.
- Converting self-reported savings into delivery claims: DORA's 80% figure measures belief. Report belief as sentiment, and reserve delivery claims for lead time and deployment frequency.
- Buying more generation capacity to relieve a downstream constraint: The 2025 Faros telemetry associates high adoption with longer review time. The 2026 report associates high adoption with more defects, incidents, churn, and unreviewed merges. Direct the next tooling dollar toward review and test capacity.
- Measuring adoption rate over flow: Adoption is near-universal in DORA's survey and carries no delivery information. Instrument flow through the whole pipeline.
All four corrections depend on system-level instrumentation that per-seat AI dashboards do not provide.
How to Convert Individual Gains Into Delivery
Start with instrumentation because every later decision depends on it. Measure lead time and deployment frequency over the same window as per-developer output. Add throughput per team and rework rate, then calculate spend per merged change. Divergence between the two families quantifies the conversion gap for a board.
A team that doubles merged pull requests while lead time and deployment frequency stay flat has increased change inventory without increasing delivery. If rework also rises, spend per merged change can reveal whether the extra output survives verification cheaply enough to justify the added tooling and review load.
Closing that gap is an operating-model change and not a tooling change. The software factory operating model keeps specifications and merge approval with people while agents do the writing, and the software factory maturity model stages that transition.
Then expand verification capacity alongside generation. Cosmos coordinates agent work across the software development lifecycle. Cosmos Environments define where agents run and what they can access. Cosmos Experts define agent behavior and capabilities. Shipped Experts include PR Author, Deep Reviewer, Risk Analyzer, and Verifier, providing distinct authoring and verification roles within explicit execution boundaries.
Cosmos Sessions preserve auditable work across long-running tasks. Cosmos Triggers can start Sessions from external events, including webhooks, or from schedules. Subscriptions can keep a running Session listening for follow-up events. These Cosmos primitives provide coordination mechanisms. Review policy, staffing, merge gates, and metric definitions remain the organization's own.
Verification must also cross repository boundaries when a change affects shared interfaces. The Context Engine retrieves code through semantic dependencies and call flows, including cross-repository relationships. The test coverage workflow maps critical paths using code relationships and engineering history, subject to the evidence available in the connected repositories.
Finally, set a test that separates J-curve adjustment from genuine failure. Treat the program as adjusting while structural change is underway, review capacity is growing, rework rate is falling quarter over quarter, and spend per merged change is trending down. Treat it as failing when per-developer output keeps rising while every system-level metric stays flat after leaders fund the structural work. That test gives the CFO a falsifiable answer and commits engineering to a measurable position.
What to Do Next
Spend aimed at generation competes with spend for verification capacity. Instrument the downstream stage before buying more upstream capacity. Pull review queue time and rework rate for the last two quarters, then calculate spend per merged change and place those measures beside per-developer output for the same window. Use that comparison to turn the next budget request from a seat count into a constraint-relief plan the CFO can audit.
Frequently Asked Questions
Related Reading
Written by
Ani Galstian
Ani writes about enterprise-scale AI coding tool evaluation, agentic development security, and the operational patterns that make AI agents reliable in production. His guides cover topics like AGENTS.md context files, spec-as-source-of-truth workflows, and how engineering teams should assess AI coding tools across dimensions like auditability and security compliance