The whole app was one HTML file - introducing AI Code Rescue

A friend who runs another software house messaged me a few weeks ago. Translated from Polish, lightly edited:

“Hey. A client sent us an ‘app’ they built in Claude. They want us to add SSO and help with hosting. People are genuinely lost out there.”

A minute later, the punchline:

“Turns out the whole application is one HTML file.”

Single sign-on. For a file.

Not long after, a different friend - a developer at another company - asked me over DMs whether we’re also seeing more and more work that boils down to fixing AI slop. Someone senior at his company had built three quarters of the company website by prompting an AI, and now the team is expected to bring it up to the quality of the hand-built site it replaced. He told me he’d opened a job board for the first time in a year.

Two separate chats, same picture. And the same picture keeps showing up in my feed.

The line from that post worth keeping: for a product at that scale, the prototype is maybe 0.5% of what makes it actually work in production. The rest is infrastructure, reliability, and edge cases that only surface once real people are using it.

The practice has a name now. Vibe coding is building software by describing what you want to an AI tool - Lovable, Bolt, v0, Cursor, Claude - and shipping whatever it generates, usually without a developer ever reading the code. It puts a working demo in front of people in hours. What it skips is everything that decides whether the thing survives once it leaves the demo.

The numbers behind the anecdotes

This isn’t a few unlucky founders. The same pattern shows up across the big public datasets on how code has changed as AI adoption spread - repo telemetry, security benchmarks, and review-pipeline data alike.

Veracode tested over 100 models on realistic coding tasks and found that 45% of AI-generated solutions contained OWASP Top 10 vulnerability classes - the industry’s standard list of the ten most common ways web applications get attacked. These are the first things anyone looking for a way in would try. Newer and bigger models weren’t meaningfully more secure. GitClear’s analysis of 600M+ commits shows code duplication up 81% since 2023 - the highest level ever recorded - while refactoring dropped by roughly 70%, so the mess compounds instead of getting cleaned up. And Faros AI’s telemetry across 22,000 developers found 31% more pull requests (the checkpoint where someone else is supposed to read a change before it joins the real codebase) merged with no review at all.

Then there are the incidents. In July 2025, an AI coding agent deleted a production database during an explicit code freeze. The same summer, an app shipped with no database access rules exposed 72,000 private images, including thousands of government IDs. Two different apps, one shared failure: nobody was reading what the AI did.

The part you might not expect: we’re firmly pro-AI

After all of that, you’d assume this post ends with “so stop using AI.” It doesn’t. At Coditive we land firmly on the other side of this. Today, not using AI isn’t the safe, principled choice. From a client’s point of view, it’s the unfair one, and frankly the uneconomical one.

We ran the numbers on ourselves. Between July and December 2025 we tracked five very different projects, from simple marketing sites to full web applications. Across all of them, working with AI cut our delivery time by 35% to 50%, with code quality that held steady and in several cases came out better than before. That’s the standard behind the way we deliver work now. Our recent Strapi v4 to v5 migration is a public example: estimated at 40-60 hours the old way, delivered in about 20.

Sit with that for a second. A client paying for a hand-built project at old speeds, when the same quality now ships in half the time, is overpaying for the privilege of watching us work slower. Refusing these tools wouldn’t make us more disciplined. It would make us more expensive for no reason the client ever benefits from. Nobody serious is going back.

The real problem with vibe coding: code nobody reads

So how do both things stay true at once - AI making our work measurably faster and better, and AI-built apps arriving at agencies as one giant HTML file?

The difference is verification. Generating code is now nearly free. Reviewing it isn’t. When those two drift apart, review quietly disappears - and with it, everything review used to catch.

A National Bureau of Economic Research working paper tracked more than 100,000 GitHub developers across three generations of AI tools. Commits rose 40% with autocomplete, 140% with interactive agents, and 180% with autonomous agents. Follow that same work toward a release, though, and the gain drops to 30%.

Some of that gap is review. Between the commit and the release, a human still reads the diff and sends part of it back, and the researchers read the rest of the gap as human bottlenecks further along the path to shipping. Releases do grow, and on a big codebase with that layer intact, this is the system working as intended. The brake is supposed to be there, and a good part of what it rejects is exactly the kind of code this post is about.

The “apps” that get sent to us often have no such layer. Nothing stands between what the model wrote and what the user gets.

Even where the layer exists, volume is wearing it down. That was one of the loudest themes at WordCamp Europe 2026. When an AI agent opens 40 or 50 pull requests at once, the human “approving” them stops being a reviewer and becomes a witness to the automation - a rubber stamp. Which makes the reviewer more important than ever. When nobody writes the code by hand, review is the one place where human judgment still enters the work. Companies and open source maintainers are already answering that with stricter rules than they needed a few years ago: who is allowed to review what, and how much an agent is allowed to merge on its own.

Amazon is the clearest example. After a run of outages, an internal memo flagged a trend of incidents with a “high blast radius” involving Gen-AI assisted changes, and the company now makes junior and mid-level engineers get a senior sign-off on AI-assisted code before it ships. Amazon puts the outages themselves down to human and configuration error. It added the sign-off rule anyway.

That’s the honest framing of the vibe-coding problem. The tools build impressively fast. Accountability for what they build still has to come from a person, and that person has to be able to read the code.

So we made it a service: AI Code Rescue

This is the offer expansion the headline promised. AI Code Rescue is the newest of our AI services, built for exactly the situation our friends keep describing: you built something with Lovable, Bolt, v0, Cursor, or Claude, it works in the demo, and now it needs to survive real users, real data, and real attackers.

Every engagement starts with an audit of your codebase, and the audit findings are depressingly consistent. Live payment keys hardcoded in the repository. API endpoints that let any logged-in user read any other user’s data. Database rules that say yes to everyone. Dependencies that don’t exist on npm - which is worse than it sounds, because attackers watch for those made-up package names, publish malicious code under them, and wait for the installs. (Interesting fact: the security world already has a word for this - slopsquatting.)

The audit turns into a rescue plan that ranks everything we found: what’s critical, what can wait, and what each part costs to fix. Then we work down the list, security first, and you can see the diff for every change we make. We don’t default to rewrites. When a rewrite really is cheaper than repair, we show you the math and you decide.

One thing we want to be clear about, because almost everyone who contacts us asks some version of it: no, we won’t judge how the code was built. You shipped something real and put it in front of users. Most ideas never get that far. We build with AI ourselves, and in 15 years of taking over projects we’ve seen scarier things written by hand.

If you have an AI-built app right now

Three things worth doing this week.

First, don’t panic-rewrite. A full rebuild is the easy answer to give. Most AI-built apps we take over are fixable for far less.

Second, get the security basics checked before you push more traffic to the app. Exposed keys, missing authorization, and open database rules are the failures that turn into headlines, and they’re also the fastest to find and fix.

Third, have a human who reads code look at yours. If you’d like that to be us, get a free code assessment - you’ll get an honest read on where your app stands and what it would take to make it production-grade. We’ll sign an NDA first if you need one, and if all you want is the audit report, that’s a service on its own.

AI got your app this far. Humans take it from here.