Where the Term Comes From

A term born from observation, not marketing

In early 2025, Andrej Karpathy—a prominent AI researcher and educator—noticed that a specific pattern of code generation had become popular among developers using tools like Cursor and Claude Code. Rather than the careful, line-by-line handoff many people expected from AI coding tools, some developers were simply describing an outcome, accepting the full generated code, running it, and then feeding error messages or screenshots back to the tool to iterate. When it worked, it was noticeably faster than traditional development. When it failed, it often failed in surprising ways. Karpathy named this practice "vibe coding"—coding where you're optimizing for the vibe of the running result, not for understanding or reviewing every line of generated code.

The term stuck not because it was marketing genius, but because it named something that was already happening. Within weeks, thousands of developers recognized themselves in the term. For solo makers, people prototyping new ideas, and teams building exploratory projects, vibe coding turned out to be a real productivity win. For teams building production software, it often turned out to be a real liability. The term's power was that it made the distinction clear enough to argue about productively.

Why naming this practice matters

Before "vibe coding" had a name, conversations about AI-assisted development were often muddled. Someone would say "I use Claude to write code," and listeners would imagine radically different things depending on their own risk tolerance. Did that mean reading every change? Spot-checking? Accepting everything without review? The term "vibe coding" clarified the conversation by naming a specific end of that spectrum: the end where you trust the tool's output enough to run it without reading it, at least on the first iteration.

This clarity was valuable for everyone. Developers who wanted to move fast had permission to do so. Teams concerned about code quality had a shared language for saying "we can't do that here." Tool makers like Anthropic (Claude Code), Anysphere (Cursor), and OpenAI (Codex) could tailor their products to different use cases explicitly—some emphasizing the vibe-coding workflow, others emphasizing deep understanding and review. The conversation became less about "AI coding: good or bad?" and more about "what's the right review and testing strategy for what I'm actually building?"

The practice is older than the name

The irony is that the practice of turning descriptions into code without carefully reading every line is not new at all. Developers have been trusting code generators of various kinds—from scaffolding tools, to API client generators, to ORM libraries—for decades without reading every generated line. What changed is that the generator got good enough that a developer could describe a specific, novel feature and get working code back quickly, and the generator stayed good enough that iterating on error messages worked more often than not.

Vibe coding didn't invent trusting generated code. It named the moment when language models got good enough that this pattern went from "acceptable for boilerplate" to "viable for substantial new features."

What made the term resonate

A good term does three things: it describes the practice accurately, it carries no false judgment (even if people's reactions to it are strong), and it makes the underlying tradeoff visible. "Vibe coding" does all three. It doesn't say "AI wrote it all and that's great" or "AI is replacing developers." It says "this person is steering toward a running result and not reading every line on the way there," which is both accurate and neutral about whether that's wise (the answer: it depends on what they're building).

The term also worked because it was memorable and slightly playful. Karpathy's word choice—"vibe"—carries a hint of lightheartedness that made it easier for people to discuss something they were nervous about without sounding like they were defending recklessness or predicting doom. You can say "I vibe coded this prototype" and people mostly understand: fast iteration, not production-ready, trust-but-verify assumed.

How the term evolved in practice

Six months after Karpathy's post, the term had already picked up more precise usage in different communities. In academic and research settings, "vibe coding" usually meant pure iteration on error messages, with minimal reading. In professional startups, it usually meant accepting an AI-generated first draft, then doing a careful review pass before shipping. In open-source communities, it meant "this code came from an AI and the reviewer needs to look harder." The term was elastic enough to cover all of these practices while still being clear that something different was happening compared to a developer hand-writing every line.

This evolution is healthy. The term stuck not because everyone uses vibe coding the same way, but because it creates a shared reference point for a crucial conversation about how much trust to put in generated code, what review and testing practices that implies, and how to match the approach to the actual stakes of the project.

Common mistake

Treating "vibe coding" as either a universal best practice or a universal failure mode. The term names a real technique and a real tradeoff. The tradeoff is different for every project. It's not that vibe coding is inherently right or wrong—it's that it's right or wrong in specific contexts, and the term's value is that it makes those contexts and tradeoffs explicit enough to argue about clearly.