82% of AI spend never reaches the product. And that was exactly what to expect.

The numbers are right. The reading is not.

The data leaked this week and went viral in the obvious places. An EntelligenceAI analysis of 2,444 companies showed where every dollar spent on AI-assisted development goes:

$0.44 – fixing bugs generated by the AI itself
$0.27 – rewriting code that missed the mark
$0.11 – on review friction, context switching, merges
$0.18 – actually delivering value to the end user

82% of the spend never reaches the product.

The lazy reading came immediately: AI is hype, it does not work, everyone has been fooled, go back to Stack Overflow.

That reading ignores a full 36 months of how this industry is operating – and what it is learning to do.

The story is 3 years old

The timeline of tooling that actually changed the work:

GitHub Copilot – 2022. LLM-based contextual autocomplete. The first time real-time code suggestion became a mainstream product.
Cursor – 2023. An entire IDE rebuilt around the model. Conversation with the codebase, multi-file editing, natural-language commands.
Windsurf – 2024. Cascade, the first serious attempt at a collaborative agent inside the editor.
Claude Code – 2025. An autonomous agent in the terminal, operating on the repository with permission to run commands.

These are not incremental versions of the same thing. Each proposes a different model for the relationship between developer and code. The industry has not even reached consensus on which approach wins – and it should not, because it has not finished exploring the solution space.

And Spec-Driven Development, which resurfaced in 2025 as the “right way” to use AI for programming? It has existed since 2004. Nobody invented anything – the industry rediscovered an old practice because the cost of not using it rose sharply with agents that produce code in volume.

Translation: AI-assisted software engineering has, in practice, 3 years of mature existence. And we are holding it to metrics as if it had 30.

Why that 82% is exactly what to expect

Take any significant technology transition of the past decades and look at its first 3 years.

When SPA frameworks (React, Angular, Vue) began replacing jQuery and server-side rendering around 2014-2016, thousands of projects were rebuilt as SPAs simply because it was the fashion. Most did not need to be. Simple CRUD applications turned into snowballs of complexity, badly managed client-side state, SEO problems discovered far too late. How many hours were burned rewriting dashboards from Angular 1.x to React, and then to Next.js? How many blogs became Gatsby before becoming Next before going back to WordPress?

When microservices became the architectural trend around 2015-2018, companies with perfectly functional monoliths decomposed them into 30, 50, 100 services because that was what Netflix did. Most had no scale problem justifying the decision. Years later we saw the reverse wave: “modular monolith”, “back to the monolith”, expensive consultants redoing what other expensive consultants had undone.

When cloud went mainstream around 2012-2015, millions were burned on badly executed lift-and-shift – migrating virtual machines as if they were physical servers, ignoring that cloud bills by usage, discovering absurd invoices in the third month. Years later the industry learned what a cloud-native workload was, FinOps became a discipline, and the first projects were rewritten.

Every one of those waves had its own “82% of the spend never becomes product”. None of them had a dashboard ready to circulate on LinkedIn in the heat of the moment.

The difference with AI is that the cycle is visible in real time. Tokens are countable. Telemetry is granular. The waste is measurable per company, per sprint, per commit.

That is not a problem. It is a privilege.

For the first time in the history of the software industry, we can measure the cost of collective learning while it happens. And still the dominant reading is one of shock – as if the existence of waste invalidated the technology, rather than proving it is genuinely being experimented with.

What separates those who are learning from those who are only paying

The interesting question is not “why is there waste”. It is another:

Of the teams burning that 82% today, which will be delivering 60% value 18 months from now – and what are they doing differently from the ones that will keep burning 82% forever?

The answer is starting to show in observable patterns among the teams pulling ahead of the curve.

Spec-driven, not vibe-driven. Before the prompt, there is a specification. Before the specification, there is a clearly formulated problem. Teams that treat AI as a code generator without that structure get stuck in the infinite loop of “generate, test, tweak prompt, generate again”. Teams that start from a spec use AI to implement, not to discover what needs doing.

Eval harnesses, not blind trust. AI-generated code is tested before it gets anywhere near production – not with ad hoc human review, but with automated suites that measure behaviour. AI-generated bugs are expensive, but predictable. Whoever invests in automated verification pays once; whoever reviews case by case pays every sprint.

Surgical scope, not total rewrite. The temptation to ask “rewrite this whole module using AI” is exactly what produces the 27% of rework. Mature teams use AI in limited scopes – one function, one test, one targeted refactor – and keep humans as the architectural integrators.

Stable tooling, not chasing the shiny. Part of the difference between a team that learns and one that only spends is how long it stays in a workflow before jumping to the next. Teams that switch from Copilot to Cursor to Claude Code to Windsurf every three months learn none of them deeply.

None of these points is new. None is a secret. But they separate the 18% that delivers from the 82% that learns.

Closing

The chart’s numbers are not wrong. The reading is.

Anyone who looks at 82% waste and sees failure is measuring a 3-year-old industry by 30-year-old standards. They are confusing the snapshot with the curve.

The curve is what matters. And it has a recognisable shape: high investment, low return, practice adjustment, rising return. We have seen this film with SPAs, with microservices, with cloud. We will see it with AI too.

We are still learning to use AI to build software in production – not to autocomplete a function, but to ship product with quality and at scale. Learning that is like building a rocket from scratch: you will blow up several before launching the first real one.

The 44% burned on bug fixing are the rockets exploding on the pad. The 27% on rework are the rockets that lifted off crooked. The 11% on review friction is the ground crew arguing over which valve to turn while the schedule slips.

It does not matter.

What matters is that some teams are picking through the wreckage, identifying what failed, and adjusting the next rocket. And others are looking at the chart of explosions, concluding that rockets do not work, and going back to travelling by caravel.

A new rocket explodes. What decides who reaches the moon is what you do afterwards.