Why AI-built apps demo fine and fail in production

The pattern is so consistent that people who call about a rescue describe it in nearly the same words. The app worked. They showed it to someone, and it worked then too. Then real users arrived, or a payment went through, or a background job ran at three in the morning, and something structural gave way. Prompting the tool to fix it made a different thing break.

This is not bad luck, and it is not the founder's fault. In 2025 four separate groups measured it.

What the studies found

Veracode, July 2025, ran 80 coding tasks through more than a hundred models. The tasks were designed so that each had a secure and an insecure way to solve it. When given that choice, the models picked the insecure option 45 percent of the time. Not on obscure edge cases; on the everyday things, like how a query is built and how input is escaped.

Escape.tech, October 2025, went looking at what actually shipped. They scanned more than 5,600 publicly reachable applications built with Lovable, Base44, Bolt.new, and Vibe Studio. They found 2,038 highly critical vulnerabilities, more than 400 leaked secrets, and 175 instances of exposed personal data. Some of that data was bank account information.

Tenzai, December 2025, tested five major AI coding tools by having each build applications and then attacking them. Sixty-nine vulnerabilities, six of them critical. Every one of the five tools introduced server-side request forgery. None of the five implemented cross-site request forgery protection.

Carnegie Mellon's SusVibes benchmark measured the gap most precisely. Across 200 tasks drawn from real open-source projects, the best agent configuration got 61 percent of solutions functionally correct. Only 10.5 percent were also secure. More than 80 percent of the solutions that worked contained a security vulnerability.

That last number is the whole story. The tools are good at making it work. Working and safe are different targets, and the tools are aimed at the first one.

Why it happens

Three reasons, and they compound.

The tools optimize for the demo. The feedback loop inside Lovable or Bolt or Cursor is: does the screen render, does the button do the thing. There is no loop for "is the endpoint authenticated" or "what happens when this runs twice." So the model satisfies the loop it has.

They hand-roll instead of reaching for the framework. The Rails Foundation's own benchmark, run by Evil Martians in August 2026, found frontier models solve most scoped Rails tasks, 92 percent for the best of them. It also found the models mostly write their own version of things instead of using the framework's built-in API; recall of the correct Rails API ranged from 8 to 35 percent. A hand-rolled password check instead of has_secure_password. A custom retry loop instead of Active Job. Each one is code that a person now has to understand from scratch, and each one is a place where the framework's twenty years of security fixes do not apply.

Nobody read the whole thing. An app assembled over forty prompts has been seen one file at a time by a model with a context window and never once by a person end to end. The data model drifts. Two parts of the app disagree about what a "user" is. The API key that was in an environment variable on prompt three is in the front-end bundle by prompt thirty because that was the fastest way to make the demo work.

The scale of it

This would be a curiosity if the volume were small. It is not. Lovable told TechCrunch it crossed $400 million in annual recurring revenue in February 2026 with 146 employees, and by June was reporting $500 million and more than 200,000 new projects created every day. Most of those projects are abandoned. A meaningful fraction reach real users. Every one of those inherited the numbers above.

What a rescue actually has to fix

People arrive expecting a rescue to be debugging: find the bug, fix the bug. It is usually not. The recurring problems are structural, and they come in a predictable order.

1. The dangerous things. Secrets in the bundle. Endpoints with no authentication. A database reachable from the internet. An admin panel with no login. These get fixed before anything else moves, and a real backup is taken first, because a rescue that loses data is worse than no rescue.
2. The data model. The thing the tool got wrong on prompt three that everything since has worked around. Constraints that should be in the database and are in a callback, or nowhere. Two tables that both think they own the same fact.
3. Authentication and authorization. Almost always hand-rolled, almost always subtly wrong. Replaced with the framework's version.
4. The jobs. Anything that runs on a schedule or in the background: emails, syncs, billing. Usually no retries, no alerts, and no idempotency, so when it fails at 3am it fails silently and when it is re-run it does the thing twice.
5. Everything else, cut. The tool generated forty screens. Six are used. The rest are deleted, in writing, so the next developer does not have to maintain them.

That order is why the Rescue Run is shaped the way it is: teardown, stop the bleeding, rebuild the core, deploy and hand over. And it is why the diagnostic comes first, because until someone has read the whole thing once, nobody knows which of those five is the problem.

If you are in the middle of this

Keep prompting if it is working. It stops working at the point where the problem is not in the file the model is looking at, and you can usually feel that point: the same bug for two weeks, fixes that break something else, a developer who looked at the repo and went quiet. When you get there, the useful thing is not another tool. It is one person reading all of it, once, and telling you the truth in writing.