Are AI Development Gains a Myth for Enterprise Software?

A strategic examination of why the productivity revolution keeps failing to arrive on the balance sheet

There is a peculiar dissonance at the heart of enterprise software development in 2026. Walk any engineering floor and you will find artificial intelligence everywhere: 93% of developers now use an AI coding assistant at least monthly, and roughly 27% of all production code is machine-authored. Walk into the boardroom, however, and the story inverts. Organisational productivity gains have stubbornly refused to move beyond approximately 10%, and a National Bureau of Economic Research survey of nearly 6,000 executives found that over 80% of firms reported AI had delivered no measurable productivity impact whatsoever over the preceding three years. The economist Robert Solow once quipped that the computer age was visible everywhere except in the productivity statistics. Four decades on, his paradox has been reincarnated with unnerving fidelity.

So the question deserves to be posed bluntly. Are the AI development gains promised to enterprise software organisations a myth? The honest answer is more uncomfortable than either the evangelists or the sceptics would prefer: the gains are real, but they are being generated in a place where the enterprise cannot bank them, and in many cases they are quietly funding a liability that will fall due later.

The evidentiary problem: what the numbers actually say

The canonical figure in every vendor deck remains GitHub’s 2022 finding that developers completed tasks 55% faster with Copilot. Scrutinise the methodology and the edifice wobbles: a single JavaScript task, thirty-five completers, no assessment of output quality or production survivability, and a confidence interval stretching from 21% to 89%. It demonstrated that when one selects a task ideally suited to AI assistance and measures only completion time, AI looks fast. That is a genuine finding. It is simply not the finding being used to justify eight-figure enterprise licensing programmes.

The counter-evidence is equally instructive, and equally imperfect. METR’s much-cited randomised controlled trial found experienced open-source developers were 19% slower with AI tools whilst believing themselves faster, a perception gap that should trouble any executive relying on developer sentiment surveys. Yet METR itself revised its position in February 2026 after discovering that 30% to 50% of invited developers declined to participate without AI access, a selection effect that skewed the sample. Their newer cohort showed a statistically ambiguous 4% slowdown, and their considered conclusion was that AI likely does provide productivity benefits in early 2026. Intellectual honesty demands we hold both revisions in view: the triumphalist numbers were inflated, and the most damning number was too pessimistic.

Between these poles sits the most credible synthesis. McKinsey’s survey of 4,500 developers across 150 enterprises found AI reduced time on routine coding tasks by 46%, but routine coding is a narrow category encompassing boilerplate, test scaffolding and documentation. It excludes system design, debugging complex issues and comprehending unfamiliar codebases, which is to say it excludes most of what senior enterprise engineers are actually paid to do. DX’s analysis of 135,000 developers found daily AI users merging 60% more pull requests, yet across DORA metrics and quality indicators, the team-level gains simply do not aggregate. The value evaporates somewhere between the individual keyboard and the organisational ledger.

Where the value goes: Amdahl’s Law and the migrating bottleneck

The explanation is neither mysterious nor new. Software delivery is a system, and a system moves only as fast as its slowest constraint. Writing code has rarely been the constraint in a mature enterprise; the constraints are review, integration, security validation, change advisory boards, regression assurance and release governance. Accelerate code generation and you do not accelerate delivery; you relocate the queue. Faros Research documented precisely this dynamic: developers on high-adoption teams touch 47% more pull requests per day, review queues swell, QA saturates, and downstream bottlenecks absorb the value created upstream. Amdahl’s Law is not repealed by a subscription to a coding assistant.

There is a deeper irony for the enterprise specifically. The elaborate governance apparatus that startups mock as bureaucratic sludge exists because enterprise software carries obligations that a seed-stage product does not: fiduciary duty, regulatory exposure, contractual service levels, decades-old data whose integrity underwrites the business. That apparatus is exactly what throttles AI’s raw generative speed, and it is also exactly what the enterprise cannot responsibly discard. The gains are throttled by the same mechanisms that make the organisation an enterprise in the first place.

The reuse regression: why AI-generated code offends enterprise architecture

Here we arrive at the most strategically underappreciated finding in the entire literature, and the one that cuts closest to how enterprises actually create durable value from software. Enterprise architecture is predicated on abstraction and reuse: shared libraries, hardened components, a single authoritative implementation of each piece of business logic. These are not aesthetic preferences. Reusable, centrally maintained components are how an organisation enforces the confidentiality, integrity and availability guarantees at the core of its security posture. One authentication library, audited and patched once, protecting a thousand consuming services, is a control. A thousand subtly divergent authentication implementations is an attack surface.

AI coding tools, as currently constituted, are structurally hostile to this discipline. GitClear’s longitudinal analysis of 211 million changed lines across repositories including those of Google, Microsoft and Meta found that code duplication rose 81% compared with the pre-AI era, with an eightfold increase in duplicated blocks of five or more lines. Copy-pasted lines exceeded refactored lines for the first time in the dataset’s history, and the refactored share of changes collapsed from roughly 25% to under 10%. As GitClear’s chief executive Bill Harding observed, every time you want something, the AI creates a new implementation for it, because the model cannot see your internal abstractions, does not know your team standardised on a particular data access pattern six months ago, and optimises for a passing test rather than a coherent codebase. Ox Security’s analysis of 300 repositories characterised the output as highly functional but systematically lacking in architectural judgement.

The security corollary is stark. Veracode’s testing of over one hundred large language models across eighty tasks found 45% of AI-generated code introduced OWASP Top 10 vulnerabilities; CodeRabbit’s analysis put AI-generated code at 2.74 times the vulnerability density of human-written code; and Black Duck’s 2026 report recorded known vulnerabilities per codebase more than doubling year on year. Google’s DORA research adds the operational dimension: incremental AI adoption correlates with measurable declines in delivery stability. For an enterprise whose entire security model rests on integrity and availability, code that duplicates rather than reuses, and that carries elevated vulnerability density, is not merely suboptimal. It is a slow-motion violation of the control environment, compounding at roughly four times baseline maintenance cost by the second year on some estimates.

The startup mirage: velocity is not the same game

But what of the startups? A quarter of one recent Y Combinator cohort reportedly shipped codebases that were 95% AI-generated, and the vibe-coding toolmakers saw their combined valuations rise roughly 350% in a year. Does this not prove the gains are real?

It proves something narrower: that AI is extraordinarily effective at the problem startups actually face, which is discovering whether anyone wants the product before the money runs out. A startup’s codebase is a hypothesis, cheerfully disposable if the hypothesis fails and rewritable if it succeeds. It carries no twenty-year-old ERP integration, no regulator, no change advisory board, no data whose corruption would trigger a disclosure obligation. The economics of speed-over-durability are rational at that stage, and genuinely transformative.

The enterprise is playing a different game, and the startups themselves demonstrate this the moment they grow into one. The industry has already coined a term, rescue engineering, for the structural rework required when early vibe-coded successes accumulate real users, real data and real obligations. Auditors of such codebases report a monotonous consistency: duplicated logic across modules, absent separation of concerns, missing error handling, negligible test coverage, business rules hardcoded across whichever files were convenient at prompt time. Regulated regimes such as SOC 2, HIPAA and GDPR require software that is explainable, auditable and traceable, and black-box generated codebases cannot satisfy those requirements unaided. The startup wins are real, but they are wins in a category the enterprise does not compete in. Citing them as evidence for enterprise gains is a category error dressed up as a benchmark.

So: myth, or mismanagement?

The most defensible reading of the evidence is that the gains are not a myth but a conditional asset, and most enterprises have not met the conditions. The same DX research that found stagnant aggregate productivity also found the distribution bifurcating dramatically: some organisations doubled their customer-facing incidents after adoption whilst others cut them by half. The differentiator was never the tooling. In structurally sound organisations AI operates as a force multiplier; in disordered ones it multiplies the disorder, at machine speed.

The strategic implications for enterprise leadership follow directly. First, stop purchasing task-level statistics and start instrumenting system-level outcomes: lead time, change failure rate, incident volume and, critically, the ratio of refactored to duplicated code, because a codebase whose duplication is accreting is consuming tomorrow’s velocity to fund today’s. Second, treat AI output with the governance posture Martin Fowler recommends, as contributions from a prodigiously productive collaborator whom you do not yet trust, subject to the same review, testing and security gates as a new hire’s work, with pull request size caps and scanning tuned to AI failure patterns. Third, and most consequentially, recognise that the binding constraint is the delivery system, not the developer. If review, testing and release engineering are not modernised in tandem, the licence spend purchases a longer queue. The BCG heuristic that 10% of AI value derives from algorithms, 20% from technology and 70% from people and process is borne out with almost embarrassing precision in the software delivery data.

There is one further consideration that counsels against complacency dressed as scepticism. Model capability is not static: METR’s own benchmarking shows the length of task frontier models can complete autonomously doubling roughly every four months. The enterprises that spend this period building the governance, measurement and architectural discipline to absorb AI safely will be positioned to capture each capability increment as it arrives. Those that conclude from today’s flat aggregate numbers that the whole affair is a myth will discover, as the laggards of the cloud era did, that the paradox eventually resolves, and it resolves in favour of the prepared.

The gains, then, are not a myth. They are an invoice. AI genuinely accelerates the creation of code; whether that code delivers enterprise value depends entirely on whether the organisation has built the system that converts velocity into integrity. Most have not. That is not a failure of the technology. It is a failure of strategy, and unlike the technology, it is entirely within the enterprise’s control.

Sources and further reading

DX / Laura Tacho, Measuring Developer Productivity and AI Impact (121,000 developers, 450+ companies, 2026), as reported by ShiftMag: shiftmag.dev/this-cto-says-93-of-developers-use-ai-but-productivity-is-still-10-8013

METR, We are Changing our Developer Productivity Experiment Design (February 2026 revision of the original randomised controlled trial): metr.org/blog/2026-02-24-uplift-update

GitClear AI Code Quality research (211 million changed lines, 2020 to 2024) via LeadDev, How AI-generated code compounds technical debt: leaddev.com/technical-direction/how-ai-generated-code-accelerates-technical-debt

GitClear 2026 update and DORA stability findings via LeadDev, Code maintainability plummets in the AI coding era: leaddev.com/ai/code-maintainability-plummets-in-the-ai-coding-era

GitClear churn, duplication and maintenance-cost analysis via Particula, AI Writes 41% of Code: The Churn and Tech-Debt Data: particula.tech/blog/ai-code-churn-cloning-tech-debt-data-41-percent-generated

McKinsey enterprise developer survey (4,500 developers, 150 enterprises), DX 135,000-developer analysis and GitHub Copilot enterprise figures via Second Talent, 84% of Developers Use AI Tools. Productivity Gains Are Only 10%: secondtalent.com/resources/ai-developer-productivity-tools-2026

Faros Research, The AI Productivity Paradox Report (bottleneck migration and Amdahl’s Law analysis): faros.ai/blog/ai-software-engineering

Veracode, CodeRabbit and Black Duck OSSRA security findings, the GitHub Copilot 2022 study critique, and the NBER executive survey (February 2026) via Philipp Dubach, 93% of Developers Use AI Coding Tools. Productivity Hasn’t Moved: philippdubach.com/posts/93-of-developers-use-ai-coding-tools.-productivity-hasnt-moved.

Ox Security repository analysis (300 repositories, architectural judgement findings) via Tembo, AI Technical Debt: How AI-Generated Code Creates Hidden Costs: tembo.io/blog/ai-technical-debt

Forbes, AI Productivity’s $4 Trillion Question: Hype, Hope, And Hard Data (task-level versus aggregate gains, BCG 10-20-70 rule, JPMorgan and Goldman Sachs figures): forbes.com/sites/guneyyildiz/2026/01/20/ai-productivitys-4-trillion-question-hype-hope-and-hard-data

TechCrunch reporting on the Y Combinator Winter 2025 cohort and vibe-coding valuations via DesignRush, 25% of Startups Run on AI-Generated Code: news.designrush.com/25-percent-startups-use-vibe-coding-growing-risk

Rescue engineering and enterprise governance patterns via Keyhole Software, Vibe Coding Trends 2026: keyholesoftware.com/vibe-coding-trends-2026

Feel free to share on

Recent Posts

Related blog posts

The Great Token Retrenchment: Prudence, Panic, or the First Honest Reckoning with AI’s Value?

Winning travel’s AI shift

The AI Differentiator dividend