Vibe Coding
Why it matters
Deep Dive
Karpathy's original description was deliberately provocative: he talked about using voice input instead of typing, pressing "accept all" on every suggested change without reading the diffs, and fixing bugs by pasting error messages back at the model until they disappeared. Strip away the provocation and the workflow is simple — describe, generate, run, react — with the human acting as a product manager and tester rather than an author. What made it viable in 2025 was not that AI could write code — coding assistants had done that for years — but that the underlying LLMs became good enough to hold a whole small project together across many turns of that loop. Within months the term had escaped tech circles entirely, showing up in mainstream media and on Collins Dictionary's word-of-the-year shortlist, and it became the default shorthand for a real shift in who gets to build software.
The Tools That Make It Possible
Vibe coding became practical when coding assistants grew agent modes. Instead of completing one line at a time, tools like Cursor, GitHub Copilot, and Windsurf can now edit several files at once, create new ones, run shell commands, execute the program, read the output, and iterate — which is exactly the loop a vibe coder wants to delegate. Long context windows let the model hold a small project's worth of code in mind at once, and better instruction following means a loose description of intent usually produces something runnable. More autonomous tools such as Devin push the same idea further, taking a task description and working on it for extended periods with minimal supervision.
Where Vibe Coding Shines
The sweet spot is software that is useful but disposable: weekend projects, personal tools, one-off data scripts, prototypes, demos, and internal dashboards. Karpathy's own framing was throwaway weekend projects — things you would never have bothered to write by hand because the effort outweighed the payoff. For non-programmers, the appeal is even more direct: a teacher, marketer, or small-business owner can describe a small app and get a working version in an afternoon, something that previously required hiring a developer or learning to code. Experienced engineers use the same mode for boilerplate, migrations, and glue code, where the shape of the solution is obvious and reading every line adds little. In all of these cases the cost of a subtle bug is low, so skipping the review step is a rational trade.
The Review and Security Debt
The risks are the flip side of the same choice. A model can hallucinate library functions, pick deprecated APIs, or wire up authentication incorrectly, and if nobody reads the diff, those mistakes ship. Security researchers have repeatedly found that AI-generated code carries a meaningful rate of vulnerabilities — injection flaws, missing authorization checks, hard-coded secrets — and 2025 saw a string of incidents where quickly vibe-coded apps exposed user data or API keys in production. There is also a slower, structural cost: a codebase nobody fully understands is hard to debug, and once it grows past what fits in the model's context window, even the AI starts making inconsistent changes. Critics lump the worst of this output under the label slop — code that looks plausible, mostly works, and quietly rots.
It Is Not the Same as AI-Assisted Coding
A common misconception is that vibe coding is just a new name for any AI-assisted programming. It is not. The term refers specifically to surrendering the review step: if the model wrote the code but you read it, understood it, and took responsibility for it, that is ordinary AI-assisted development with better tooling — a distinction writers like Simon Willison drew early and sharply. The flip-side misconception is that the human contributes nothing. In practice, good vibe coding is a skill: describing intent precisely, knowing what to ask for next, and recognizing when the output smells wrong all matter, which is why the discipline overlaps with prompt engineering and context engineering.
How Professionals Actually Use It
Most working teams land on a blended pattern. The prototype gets vibe-coded — fast, disposable, judged on whether it demos well — and anything destined for production goes through normal review, with tests and CI acting as the safety net that replaces reading every line up front. A common boundary is risk: internal tools and scripts are fair game, while authentication, payments, and anything touching user data gets human scrutiny no matter how it was written. Senior developers tend to get the most out of the style, because their instincts catch wrong-looking output quickly; juniors who lean on it too early risk shipping code they cannot explain or fix. Treating generated code like a pull request from a fast but careless junior colleague — useful, welcome, and never merged unread — is the mental model many teams have converged on.