Where Vibe Coding Breaks: 6 Failure Modes and Their Fixes

Every vibe-coding disaster I've been called to look at — my own included — traces back to one of six failure modes. Not sixty. Six. The tooling changes monthly as of this writing, the models keep getting better, and yet the postmortems keep sorting into the same six folders, because the failures aren't really model failures. They're places where the workflow let generated code skip the judgment it needed.

That's actually good news. Six named failure modes means six named fixes. Here's the catalog.

1. Auth: works for the demo user, leaks for everyone else

The signature vibe-coding incident. The model builds a login flow, it works flawlessly for you, you ship. What nobody tested: whether user A can see user B's data by editing an ID in the URL, whether the API routes enforce the same checks the pages do, whether "logged in" got conflated with "authorized for this resource."

Generated auth code has a specific pathology: it optimizes for the happy path the prompt described. "Users can log in and see their expenses" produces exactly that — including, sometimes, any user seeing any expenses, since the prompt never said otherwise and the demo never noticed.

Symptom: everything works in your own account; the incident report arrives from someone else's. Fix: authorization tests written from the attacker's seat — "user A requests user B's resource, expect 403" — before the feature ships. Plus the iron rule from the guardrails system: auth code is in the always-read category. Every line, every time. And when you can, don't let the model hand-roll auth at all; managed providers exist precisely because this failure mode predates AI.

2. Migrations: the only mistake you can't revert

Bad code is recoverable — revert the commit. A bad migration that ran against production is a different animal: the revert restores your code and none of your rows. Models generate migrations confidently and occasionally catastrophically, especially when they've misread which schema state is current: a "rename" implemented as drop-and-create, a type change that silently truncates, a column-order assumption from an outdated context window.

Symptom: deploy succeeds, app runs, and data is quietly gone or mangled. Fix: three habits, none optional. Generated migrations get read by a human — they're short; there's no excuse. Destructive operations (drop, rename, type-narrowing) get rehearsed against a copy of production data first. And backups get verified before the migration runs, not discovered-missing after. During the one-day-build workflow in From Idea to Deployed, schema review is the single checkpoint I refuse to compress.

3. Edge cases: the model builds the demo, not the product

Prompt for a feature and you'll get its sunny-day version: the form that assumes valid input, the list that assumes items exist, the parser that assumes well-formed data. Models don't volunteer edge-case handling, because prompts don't volunteer edge cases — and the gap stays invisible until real users arrive with empty states, pasted emoji, 4MB uploads, and double-clicks.

Symptom: a stream of small production errors from inputs no prompt imagined; each fix reveals two more. Fix: edge cases have to be summoned. End feature prompts with an explicit sweep: "now handle: empty, absent, duplicated, oversized, malformed, concurrent." Better, use test-first prompting from the prompt-patterns playbook and put the edges in the test list, where they become executable rather than aspirational. Adversarial twenty minutes on staging before launch catches the rest.

4. Security: the vulnerabilities cluster where the shortcuts live

Generated code isn't uniquely insecure, but it's predictably insecure. The shortcuts cluster: string-built queries instead of parameterized ones, input trusted because it came from "our own" frontend, permissive CORS to make an error disappear, secrets inlined "temporarily," dependency choices made by vibes. Each one is the locally-easiest path to a working demo — which is exactly what generation optimizes for.

Symptom: none, for a while. That's the problem. Fix: mechanical, not heroic. A standing constraint block that bans the known shortcuts (parameterized queries only, no new dependencies without asking, secrets via environment only). Automated scanning in CI — dependency audit, secret detection, the boring stuff. And human reads concentrated at trust boundaries: anywhere user-controlled data meets a query, a shell, a file path, or someone else's browser. The vulnerabilities cluster, so the review can too — that's what makes this manageable at vibe speed.

5. Cost: the bill scales, the testing didn't

A quiet, modern failure mode: the code works and the invoice doesn't. Generated code is optimistic by default — retry loops without backoff or caps, an LLM call per item instead of per batch, polling where a webhook belonged, no rate limit on the shiny public endpoint. In testing, with one user, all of it is invisible. At a few hundred users — or one hostile script — it's a four-figure surprise.

Symptom: the product's best week is the billing month's worst. Fix: treat cost as an edge case and summon it explicitly. Spending alerts on every metered service before launch — the five-minute task with the highest panic-prevention ratio in this whole article. Rate limits on anything public. Caps on every retry loop. And one review question added to the gate: "what does this code do a thousand times that it only needs to do once?" Models are actually good at answering that question — when asked.

6. Drift: every diff fine, the codebase rotting

The slowest failure and the one that kills projects rather than weekends. Each generation solves its task locally: this one imports a new date library, that one invents a second error-handling style, the next duplicates a helper it didn't know existed. No single diff fails review. Six weeks later the codebase has three ways to do everything, and generation quality itself degrades — the model, learning from the mess in its context, produces messier code. Compound interest, but for entropy.

Symptom: velocity decays; every new feature takes longer than the last in a codebase that's supposedly getting more mature. Fix: a standing constraint block naming the codebase's conventions, pasted into every session, so "local" solutions stay globally consistent. A recurring consolidation pass — a refactor-only session every week or two that merges duplicates and enforces one blessed pattern per problem. And honesty in the gate: "does this diff fit?" is a review question, not just "does it work?"

The catalog in one table

The pattern behind all six

Look at the table again and one thing jumps out: not one fix says "prompt better" and every fix is a process, applied at a known choke point. That's my sharpest opinion on this whole subject: vibe coding doesn't fail where the AI is weak — it fails where the human decided, usually silently, that judgment was optional this time. The six modes are just the six most expensive places to make that decision.

The models will keep improving and the six folders will keep filling, because the folders were never about the models. Build the choke points into your loop and vibe coding is the best deal in software. Skip them and you're not moving fast — you're borrowing speed at incident rates.

I dissect one real failure (or one clean save) most weeks in the newsletter, guardrails included. Get it here.

Keep reading