Vibe Coding Was Never the Problem. Skipping Review Was.

In February 2025, Andrej Karpathy posted a description of how he'd been building small projects: describe what you want in plain English, let the model write it, accept the diffs, keep moving. He called it "vibe coding." It was a throwaway phrase for a genuinely useful technique — and within a year it had mutated into a scapegoat for every AI-generated security incident, every bloated pull request, every "how did this ship" postmortem.

That's the wrong target. Vibe coding, as Karpathy described it, is a mode for prototypes, throwaway scripts, and bounded, low-stakes tasks — the kind of code you'd delete in a week anyway. What broke wasn't the technique. It's that teams took a workflow designed for exploration and ran it, unmodified, on code that was going to sit in production for years, touch customer data, and outlive the person who typed the prompt.

The distinction matters because it changes where you point the fix. If vibe coding itself is the problem, the fix is "stop vibe coding" — which nobody is actually going to do, because it's faster and it works for what it's for. If the problem is that review got skipped, the fix is much narrower: put a review step back in before code crosses the line from prototype to production, and leave the rest of the workflow alone.

What "vibe coding" actually described

Karpathy's original point was about a specific kind of trust: you stop reading every line because the cost of reading is higher than the cost of occasionally being wrong, for the kind of code where being wrong is cheap. A weekend project. A one-off data script. A UI mockup you're going to throw at five people for feedback. In that context, not auditing every generated line isn't recklessness — it's a reasonable bet given the stakes.

The failure mode nobody named at the time is that the same bet doesn't scale to different stakes. A UI mockup with an XSS hole is a curiosity. A production checkout flow with the same hole is a breach. The technique didn't change between those two cases. The stakes did. And stakes are exactly the variable that should determine how much scrutiny code gets before it ships — that's not a new idea, it predates AI coding assistants by decades. What's new is a technique efficient enough that teams stopped asking the stakes question at all.

The data makes the distinction for you

Escape.tech scanned more than 1,400 production applications built with heavy AI code generation and found 65% had security issues, with 58% containing at least one critical vulnerability. Read that number as an indictment of AI-written code in general and you'll conclude the tool is broken. Read it as an indictment of unreviewed AI-written code in production, and a more useful question appears: what fraction of that 65% would a single focused review pass have caught?

Based on what shows up repeatedly in these audits — hardcoded credentials, missing input sanitization, permissive defaults — the honest answer is: most of it. These aren't subtle logic bugs that require deep domain expertise to spot. They're the kind of pattern-matching a competent reviewer, human or automated, catches in minutes. The vulnerability wasn't inevitable. The absence of anyone looking was.

Why the habit formed so easily

Nobody consciously decided to skip review. It happened because the friction that used to force a pause disappeared. Writing code by hand, badly, took long enough that you naturally reread it while typing. Generating code via a prompt removes that friction entirely — the code arrives fully formed, plausible-looking, often syntactically perfect, and the natural next action is to accept it and move to the next task, especially under deadline pressure.

The core mechanism behind nearly every AI-coding security failure isn't a model limitation — it's a review step that used to exist by accident and now has to exist on purpose. That's an uncomfortable thing to admit, because it means the fix isn't "wait for better models." It's organizational: someone has to decide review is mandatory, and then actually enforce it when the deadline is tight and everyone wants to ship.

The habit compounds beyond security

Security is the most visible symptom, but it's not the only one. A study of 8.1 million pull requests found technical debt rising 30–41% after teams adopted AI coding tools — not because the code was categorically worse, but because volume outpaced the team's capacity to review it. When you can generate ten times the code in the same time, and your review capacity hasn't grown, nine-tenths of what used to get scrutinized now doesn't. That's a capacity problem wearing a technology costume. We'll get into what that actually costs a team in dollar terms later in this series — for now, the point is that it's the same root cause as the security numbers: velocity without a matching review discipline.

What changes when you separate the two

Once you stop treating "vibe coding caused this" as the diagnosis, the fix stops being vague. You don't need to slow down prototyping — that's genuinely faster and better with AI assistance, and pretending otherwise wastes the actual gain. You need a clear, visible line: code that's exploratory stays exploratory, and code that's about to touch production, real users, or real data crosses through a review gate before it does. Not a rewrite. Not distrust of the model. A checkpoint.

Some teams are already building this instinct back in deliberately — security engineers running internal 2026 workshops specifically on reading AI-generated code for the vulnerability patterns that recur, treating it as a skill to teach rather than a gate to bolt on later. That's the right shape of response. It puts review where the leverage is: not in slowing down generation, but in catching the fraction of generated code that's about to matter.

The technique that got you to a working prototype in an afternoon is not the technique that should decide whether that prototype is safe to expose to the internet. Those are two different questions, and conflating them is what actually got teams burned.

The rest of this series digs into specifics — the credential leak rate in AI-assisted commits, the exact vulnerability classes that keep recurring, what a workable review protocol looks like for a small team that doesn't have a dedicated security function. But the frame stays the same throughout: vibe coding is a legitimate, fast, valuable way to build things you intend to throw away or iterate on quickly. The failures we've been documenting all come from applying it, unmodified, to things you intend to keep.

Part of the "From Vibe Coding to Production" series on aiskill.market.