Why Vibe Coding Fails

The Call Always Sounds the Same

Someone built an application using AI. They aren't an engineer — they're a founder, a product person, a domain expert. They used ChatGPT, Claude, or Copilot, and they built something that works.

Then they call us. It stopped working. Or it works unpredictably. Or every attempt to add a feature breaks something else. Or they got their first real traffic and the whole thing fell over.

The details vary. The pattern doesn't.

Andrej Karpathy coined "vibe coding" to describe a mode where you "fully give in to the vibes" and let the model drive — no reading the diff, no worrying about structure. For engineers using it as a sketchpad, fine. For non-engineers shipping the output to real users, it produces something that looks like software the way a stage set looks like a building. Convincing from the front. Hollow from any other angle. The moment someone tries to move in, the whole thing collapses.

Why It Feels Like It Works

Vibe coding is seductive because it delivers immediate, visible results. You describe what you want, code appears, something happens on screen. The feedback loop is tight, the dopamine is real. It's also the feeling of driving downhill with no brakes — you're covering ground fast, you just haven't hit the curve yet.

What you've built isn't a product. It's a demonstration. Demonstrations need to work once, under controlled conditions, for a sympathetic audience. Products need to work continuously, under adversarial conditions, for customers who'll find every edge case you didn't consider. The gap between them is engineering — the scaffolding that keeps software standing when the audience stops being sympathetic.

The Anatomy of the Collapse

Across the vibe-coded codebases we've been called in to triage — SaaS MVPs, internal tools, a handful of B2C products that hit real traffic — the progression is uncomfortably consistent. Three phases, same order, every time.

Phase one is euphoria. Features materialize from prompts. The founder ships a demo, shows investors, maybe onboards early users. Everything works because the surface area is small and usage is gentle. This phase produces a dangerous conviction: we don't need engineers.

Phase two is friction. New features conflict with old ones. Changes in one area produce unexpected behavior in another. The AI's suggestions become less reliable because the codebase has grown beyond what any single prompt can reason about. The founder responds by prompting harder, longer, more specifically. Sometimes it works — and always makes the underlying problem worse. The stage set now has load-bearing walls made of cardboard.

Phase three is crisis. Something breaks that can't be fixed by prompting. Data corrupts, a payment processes incorrectly, the application crashes under load. The founder opens the codebase and confronts a system they don't understand, built from layers of AI-generated code that even the AI can no longer reason about. Simon Willison, who writes extensively on working with LLMs, draws the line explicitly: vibe coding is fine for throwaway projects, but the moment real users are in the loop, the code has to be good enough that a competent human can maintain it. Phase three is what happens when nobody in the loop is.

The only variance is how long each phase lasts.

The Root Cause Isn't the AI

Blaming AI for these failures is like blaming a power saw for a collapsed deck. The tool cut exactly where it was told. Nobody with structural engineering knowledge was directing it.

AI generates code that satisfies the literal request. Ask for a login page, get a login page. What you don't get — because you didn't ask — is rate limiting, session management, secure password storage, injection protection, or graceful failure handling. The invisible requirements that separate a login page from a secure authentication system outnumber the visible ones ten to one.

Senior engineers spend their careers building a mental model of everything that can go wrong. Vibe coders don't know what they don't know. AI faithfully builds exactly what was asked for, which is never enough. The expertise gap isn't about knowing the answers. It's about knowing which questions to ask — and every unasked question is another hairline fracture.

That's how the pattern compounds into what we've started calling the vibe coding death spiral: each prompt closes a visible problem while opening two invisible ones, and the invisible ones take the system down.

What We Find When We Look Inside

Every vibe-coded codebase we've inherited has the same missing load-bearing pieces. Each prompt generated a self-contained layer; nobody ensured the layers composed into a coherent system.

No separation of concerns. Business logic, data access, presentation, and configuration are interleaved in ways that make any individual change unpredictable.

No error handling. The code assumes every operation succeeds — database queries return results, API calls respond, networks hold. In production, none of that is reliable. The result is silent failures, half-completed operations, and states that should be impossible but aren't.

No security model. Authentication exists as a UI feature but not as a system guarantee. The login form is there. The server-side enforcement isn't. That's not a minor omission — it's a liability waiting to become a headline.

No observability. When something goes wrong, there's no way to determine what happened. Charity Majors has made this argument for years: the less of your code you wrote yourself, the more instrumentation you need to understand what it's doing in production. Vibe-coded systems run the inverse ratio. At 3am, with customers locked out, guessing isn't a strategy.

No tests. "It worked when I tried it" is the entirety of QA. Every change is a gamble.

These aren't edge cases. They're the default outcome of building software without engineering judgment.

The Alternative Isn't Slower

The persistent myth is that vibe coding is fast and proper engineering is slow. Backwards. Vibe coding is fast the way building on sand is fast — the foundation goes down easy, the structure doesn't stay up. Proper engineering with AI assistance is genuinely faster over any horizon longer than a weekend, because every piece of work builds on a coherent foundation. The second feature is easier than the first. The tenth is easier than the second.

At GigSmart, ToolWatch, and Oxen.ai — the companies our founding partners built as CTOs — AI tooling is woven into how code gets written. The difference is that someone with a mental model of production software is directing it. Failure modes. Security boundaries. Observability. The cost of the rewrite. That's what fractional senior technical leadership buys you: an experienced CTO setting the architecture, establishing the standards, and reviewing the output, whether it comes from AI, junior developers, or contractors.

Every vibe-coded product we've rescued has the same thing in common: the founder paid twice. Once to build it, once to rebuild it. The second bill is always larger than the first would have been done right. If you're somewhere in the three phases of the death spiral — or building something new and want to skip them — let's talk. For how we pair expertise with AI in practice, see our take on AI-amplified engineering.