The 70% Wall: Why Most AI-Built Software Never Reaches Production

Ninety-five percent of corporate generative AI pilots produce no measurable return. That is not a skeptic's guess — it is the headline finding of a 2025 MIT study that examined 300 public AI deployments and interviewed 150 executives. Somewhere between the demo that got everyone excited and the system that was supposed to run the business, the vast majority of these projects simply stop.

Anyone who has tried to build something with AI in the last two years has felt the other half of this story: it has never been easier to get something working. A chatbot, a dashboard, a tool that reads documents and produces an answer — a single afternoon with the right prompt can now produce what used to take a small team weeks. That feeling is real. It is also, according to the data, almost completely disconnected from whether the thing ever becomes software a business can depend on.

95% of corporate generative AI pilots deliver no measurable business return. — MIT, The GenAI Divide: State of AI in Business 2025

This is the paradox worth sitting with: the distance between "idea" and "working demo" has collapsed, while the distance between "working demo" and "production system" hasn't moved — and by some measures has gotten wider. Four independent studies, from MIT, Stanford, GitClear and METR, describe the same wall from four different angles. None of them mention each other. None were written to make a point about AI hype. Read together, they explain with unusual precision why so many promising projects die at almost the exact same point.

What MIT actually found

The MIT report is not a takedown of artificial intelligence. Its authors are explicit that the 95% failure rate has almost nothing to do with which model was used, or how good that model is. GPT, Claude, Gemini — the pilots that stalled and the rare ones that scaled were often built on the same underlying technology.

What separated them was what happened after the first version worked. The failed pilots were treated as finished the moment they produced a good demo. Nobody owned the unglamorous job of watching how real people actually used the thing, fixing what broke in the first week of real use, and folding that feedback back into the product weekly — not quarterly. The tools that made it past the pilot stage were embedded into somebody's actual job, with a real owner accountable for whether it kept working, rather than left running on their own as a side project. MIT calls this the "learning gap": most AI tools — and most of the teams around them — simply aren't set up to retain feedback and improve over time.

In other words, the hard part was never getting a model to produce one good answer. It was building the unglamorous machinery — ownership, feedback loops, maintenance — that keeps it producing good answers in month three, under conditions nobody designed for on day one. That machinery never shows up in a demo. It only shows up once something is actually running.

Why the code itself starts to rot

Part of that machinery is the code, and here the data gets more specific — and more uncomfortable for anyone who has watched an AI assistant write in seconds what used to take an hour.

GitClear, a company that analyzes code history across hundreds of millions of lines of commits, tracked what actually happened to codebases as AI coding assistants became common. The pattern is consistent, and it isn't subtle.

*duplicated-code share measured 2021–2024.

None of this shows up on day one. A feature built with an AI assistant can look — and function — exactly like a feature built by hand, for a while. What accumulates is debt: more duplicated logic, less restructuring, more code that has to be touched again almost immediately. It's the software equivalent of a building going up fast because nobody is checking the wiring behind the walls. It stands. It works, for a while. And then it becomes expensive to change anything without breaking something else — which is precisely the moment most "AI pilots" are supposed to graduate into systems outside customers depend on.

The confidence that isn't earned

The second uncomfortable data point is about security, from a Stanford study that has held up well since researchers Neil Perry, Megha Srivastava, Deepak Kumar and Dan Boneh presented it at the ACM Conference on Computer and Communications Security in 2023. They ran a controlled study asking developers to write code for security-sensitive tasks — the kind involved in almost anything that touches user data, payments or logins — with and without an AI coding assistant.

The developers using an assistant wrote code with meaningfully more vulnerabilities, particularly around SQL injection and encryption — two of the most common ways real systems get breached. That alone would be a fair trade-off if people knew to double-check the output. They didn't: the same developers who wrote less secure code were also more confident their code was secure. The assistant didn't just introduce more risk; it quietly removed the instinct to go looking for it.

This matters more than a lone academic finding because it maps almost exactly onto where non-technical builders get stuck. Authentication, encryption, payments and access control are rarely visible in a demo — nobody asks to see your SQL-injection defenses before saying "this looks great." They become visible the moment real money, real customers or real regulators are involved — exactly the moment a project is trying to cross from pilot into production.

The speed that isn't real

The most counterintuitive study is also the most recent. In July 2025, the nonprofit research group METR ran a randomized controlled trial with experienced open-source developers — people with an average of five years on the specific codebases they worked in — completing real tasks on mature, real-world projects, half the time with AI coding tools and half without.

The developers were, on average, 19% slower when using AI tools. Not faster — slower. Before the study, these same developers predicted AI would speed them up by 24%. After finishing the tasks — after directly living the slowdown — they still believed AI had made them about 20% faster. The gap between what actually happened and what people were sure had happened was almost total.

This isn't a claim that AI coding tools are useless — the same tools can be a genuine speedup on short, greenfield, low-context tasks, which is exactly what most demos are. The METR result is specific to something else: mature, real, already-running systems — the kind every successful pilot eventually has to become. Getting an AI assistant to produce an impressive first version and integrating that output into something that has to keep running are not the same skill. The second one is invisible until you're already past the point where turning back is expensive.

What this looks like if you're not the one writing the code

None of the studies above require reading code to understand their consequence. If you're the person with the idea and the budget, not the one at the keyboard, this is what the wall usually feels like from the outside: the first version arrives fast and looks close to done. Then every small request after that — "just add a login," "just connect it to payments," "just make it handle more users" — starts taking longer than the last one, instead of shorter. Something that worked yesterday breaks when a new feature ships. Nobody can quite explain why a "simple change" took three weeks.

That isn't bad luck, and it usually isn't a bad developer either. It's the debt from the last section becoming due, on a system nobody was watching the way MIT's successful 5% watch theirs. The frustrating part is that it's invisible right up until the moment it isn't — which is exactly why so many capable, well-funded people conclude, wrongly, that the idea was the problem.

What the other 5% do differently

None of this means the 5% MIT found extracting real value got lucky, or simply hired better engineers. Across the successful cases, a consistent pattern shows up: the tool was placed inside an existing workflow with a specific, accountable owner, instead of dropped in as a generic assistant everyone was expected to figure out alone. It shipped in a narrow, well-scoped version first, not an ambitious one. And it kept changing — weekly, not quarterly — based on what actually happened when real people used it, not on what a demo audience applauded.

That's a description of a discipline, not a technology choice. It is also, not coincidentally, a description of exactly the unglamorous second-half work a demo never has to do — the ownership, the iteration, the hardening, the parts that don't compress into a five-minute video.

The wall isn't technology. It's everything after the demo.

Put these four studies next to each other and a single shape emerges. AI made the first 70% of building something dramatically easier and faster than it has ever been. It did nothing — arguably made things slightly harder — for the remaining 30%: the part where code has to stay maintainable, security has to hold up under real use, speed gains have to survive contact with a real system, and someone has to own what happens after the applause for the demo dies down.

That last 30% was never the exciting part. It was never going to fit in a launch tweet. But by every measure in this data, it's the entire difference between a demo that impresses a room and software a business can actually run on.