Vibe Coding: When AI-Built Software Falls Apart

Vibe coding is building software by accepting whatever the AI produces without really understanding it. Describe what you want, watch the app appear, ship it. The term started as a half-joke among developers. Then non-developers discovered they could build working apps this way, and it stopped being a joke.

I want to be clear up front: vibe coding is genuinely one of the best things AI has given us. People who could never build software now can. Ideas get tested in a weekend instead of dying in a notebook.

But I also get called in when vibe-coded software falls apart. There is a pattern to how that happens, and it is worth understanding before it happens to you.

Why it works so well at first

AI models are extremely good at producing software that demos well. The happy path works. The UI looks clean. The features you asked for are there, and they appeared in hours instead of weeks.

This is not an illusion. For that first version, the AI really did the job. The problem is that "works in the demo" and "survives real users" are different standards, and the gap between them is invisible until you cross it.

Where it collapses

The projects I get handed to rescue fail in remarkably similar ways.

The edge cases nobody asked about. AI code handles the flow you described. It quietly does something wrong for the user who double-submits a form, uploads a 40 MB photo, has an apostrophe in their name, or loses connectivity halfway through a payment. Wearing the confidence of clean, well-formatted code, these bugs hide until a real user finds them. Plausible but wrong is the default failure mode of AI code, and by design it looks exactly like correct code.

Security that was never asked for. Models write what the prompt demands, and prompts written by non-engineers rarely demand authorization checks, input validation, or careful handling of secrets. I have seen vibe-coded apps with admin routes protected by nothing but an unguessable URL, API keys shipped to the browser, and databases where any logged-in user could read everyone else's records. The app worked perfectly. It was also wide open.

The architecture nobody owns. Each AI session solves the problem in front of it. Fifty sessions later the codebase has three ways of doing the same thing, dead code nobody dares delete, and structures no human ever chose. It still runs. But every change breaks something unrelated, and each fix is another AI patch on top. Six months in, the honest description is: it works, nobody knows why, and it is getting worse.

No tests, so no floor. With no test suite, there is nothing to catch a regression before users do. Every deploy is a coin flip. This is usually the point where someone contacts me.

When vibe coding is exactly right

None of this means you should not vibe code. It means you should know which game you are playing.

Vibe coding is the right tool when the cost of failure is low: prototypes to validate an idea, internal tools for your own team, personal automations, landing pages, anything you would rather have imperfect today than perfect never. Most of this software should never be hand-built by an engineer at engineer prices. That would be its own kind of waste.

The line is real users, real money, or real data. The moment strangers depend on the software, trust it with payments, or store personal information in it, you have left prototype territory, whether the code knows it or not.

Crossing the line safely

If a vibe-coded project starts becoming a real product, you do not necessarily need to rewrite it. You need to retrofit the discipline that was skipped:

1. A security pass before anything else. Authorization on every route, secrets out of the client, inputs validated. This is days of work, not months, and it removes the failures that can genuinely hurt you.
2. Tests around the behavior you already rely on. Not full coverage. Just enough that the deploys stop being coin flips, starting with payments and data handling.
3. One architecture decision, applied. Pick a structure, have the codebase converge on it, delete the dead ends. AI is actually excellent at this refactoring work once a human decides the direction.
4. A review habit going forward. Someone who understands the system reads what goes in. AI writing the code is fine. Nobody understanding the code is the actual problem, and it is the difference between AI-assisted engineering and vibe coding.

That last sentence is the whole article in one line. The tools are the same. The difference is whether judgment stays in the loop.

I wrote more about the working rules that keep AI-generated code production-safe in my article on AI coding tools. And if you have a vibe-coded product that real customers are starting to depend on, that is a solvable situation. It goes better the earlier it is taken seriously.