Vibe Coding

Letting the model drive -- describing intent in natural language, accepting the generated code, and running it without reading most of it. Coined by Andrej Karpathy, the term took off fast and split the community: a liberating way to build prototypes and personal tools, a liability when unreviewed code reaches production.

The Pattern

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." -- Andrej Karpathy (source)

Vibe coding is letting the model drive. You describe what you want in natural language -- often by voice -- accept what it generates, run it, and paste back errors until it works, without reading most of the code. The defining move is not the use of AI but the deliberate surrender of comprehension: you trust the vibes over the diff.

That makes the boundary matter. As Simon Willison puts it, "not all AI-assisted programming is vibe coding" -- if you are reading and understanding every change before it lands, you are doing AI-assisted engineering, not vibe coding. The term names the specific mode where you stop looking. Held to its original meaning, that mode is best suited to prototypes, throwaway scripts, and personal tools -- "putting the soft back in software" -- where being wrong is cheap and nobody else depends on the result.

Why It Matters

The term spread faster than almost any in the field -- Karpathy's original post drew tens of thousands of shares within days -- and it "somewhat polarized the community" (AI Native Dev). One camp reads it as a dystopia of unreviewed slop flowing straight to production; the other, including Willison and Dion Almaer, celebrates that it "grants millions of new people the ability to build their own custom tools" (source). Both can be right, because they are describing different uses of the same technique. That is why this pattern is contested: the disagreement is rarely about what vibe coding is and almost always about where it belongs. The practical line teams draw is by stakes -- vibe freely on the disposable and the personal, and switch back to reviewed, understood code the moment something ships or someone else has to maintain it.

Discover what to build

There is a generative upside the production-risk framing tends to bury: vibe coding is one of the fastest ways to discover what to build. Standing up a rough, working prototype in an afternoon -- and being willing to throw it away -- surfaces the real requirements, edge cases, and dead ends far quicker than a spec written in the abstract. For an AI product engineer, that makes it a tool for exploring the problem domain as much as for producing code: vibe a throwaway version to feel out the shape of the problem and put something in front of users early, then rebuild the parts that survive as reviewed, understood code -- often via spec-driven development. The artifact is disposable; the learning is the deliverable.

Last reviewed: 2026-06-25