Vibe Coding
A reader's summary of Andrej Karpathy's term for building software by prompting a model and accepting its output without reading it closely — its origin, the practice it names, and where the wager stops paying off.
The term at a glance
Vibe coding describes writing software mainly by describing what you want in natural language to an AI coding assistant, running what it produces, and iterating on the observed behavior rather than reading the generated code line by line. It is a description of a workflow and an attitude toward trust in the model, not a specific tool — it can be done with any sufficiently capable coding assistant.
Origin
Andrej Karpathy, a founding member of OpenAI and former Tesla AI director, coined the term in a February 2025 post on X, describing a new way he had started building small throwaway projects: giving in fully to the vibes, forgetting the code exists, accepting whatever an AI model output, and simply asking it to fix things when errors appeared, rather than debugging by reading the diff himself. The post spread quickly because it named, precisely, a workflow many developers had already started drifting into without a word for it.
History and context
The term landed at a specific inflection point: coding assistants had crossed from autocomplete-style suggestion (predicting the next few tokens) into agentic tools that could plan a change, edit multiple files, run the result, and self-correct across several turns with minimal supervision. That shift made it newly viable to build a working prototype — a game, a script, an internal tool — with almost no hand-written code, which is the specific capability Karpathy's post was naming rather than the older, more modest experience of accepting an autocomplete suggestion.
Main ideas
The defining move: stop reading the diff
Karpathy's original description was explicit that the practice means giving in to the vibes, forgetting the code even exists, and accepting whatever a model produces as long as it runs — a deliberate departure from the norm that every line a developer ships is one they've read and understood.
It shifts the bottleneck from typing to specifying
The scarce skill stops being the ability to write syntax and becomes the ability to describe intent precisely enough that a model produces something close to correct, then to notice — from behavior, not code review — when it hasn't.
It's the Bitter Lesson applied to the coding loop itself
Where the Bitter Lesson observes that scaled compute beats encoded human knowledge in model training, vibe coding is the same wager one layer up: that iterating fast against a capable model, rather than encoding careful human judgment line by line, is the better way to arrive at working software.
Verification, not generation, becomes the actual constraint
Generating code stopped being the bottleneck almost immediately; whether the result is correct, secure, and maintainable is now the harder and slower problem, and the term says nothing about how — or whether — that verification happens.
Trust without verification is a security model, not a shortcut
Skipping the read-the-diff step doesn't remove the need for review, it just removes the human doing it — which means whatever a model reliably gets wrong (auth checks, input sanitization, secret handling) reliably ships too, silently, at the volume the model can produce it.
Critique
- It scales the exact failures a model has, silently. Security researchers repeatedly found vibe-coded applications shipped with exposed API keys, missing authentication checks, and basic injection vulnerabilities — not because the model couldn't have avoided them, but because no one was reading the output closely enough to notice before it ran in production.
- Karpathy's own framing was scoped, and got dropped. His original post described the practice for weekend throwaway projects with no real stakes; much of the subsequent debate is really about whether the same low-verification approach is being applied, imprudently, to production systems it was never proposed for.
- It can hide the learning it depends on. Experienced developers can judge when a model's output is plausible; critics point out that the same workflow used by someone without that background has no equivalent way to notice when the vibes are wrong, which makes the practice's safety depend heavily on expertise it doesn't require you to have.
- Maintainability is a separate question the term doesn't address. Code that runs today says nothing about whether anyone — human or model — can safely extend it in a year, and vibe-coded codebases accumulate the specific kind of undocumented, unread complexity that makes later changes riskier.
Impact
The term gave a name to a workflow shift already underway across hobbyist projects, hackathons, and early-stage startup prototyping, and it became a fixture of 2025 tech-industry vocabulary alongside the rapid rise of agentic coding tools. It is best read as one instance of a broader pattern also visible in The Bitter Lesson and Scaling Laws: scaled machine iteration substituting for painstaking, encoded human process, with the same open question each time about what gets lost when the human stops checking the work.
Notable engagements
- Andrej Karpathy, X post (February 2025) — the original coinage, describing the practice for small, low-stakes projects.
- Security research on vibe-coded apps (2025) — repeated reporting of exposed credentials and basic vulnerabilities in publicly shipped vibe-coded products, cited as the practice's most concrete cost.
- Agentic coding tools (Cursor, Claude Code, Replit Agent, and others) — the class of tools that made the practice newly viable by planning and self-correcting across multiple files rather than suggesting one line at a time.