Concept

Vibe Coding

Vibe Coding

Vibe coding is a term coined by Andrej Karpathy in early 2025 to describe a mode of software development in which the programmer narrates intent in natural language to an AI agent — and largely defers code-writing, debugging, and iteration to the agent.


Origin

Karpathy coined the term after noticing a qualitative shift in his own experience with agentic coding tools in December 2024. The model — previously useful but requiring frequent correction — began producing coherent chunks reliably. He kept asking for more; it kept working. He couldn’t remember the last time he had corrected anything. That was vibe coding.

He published this observation on X to communicate that the shift was not incremental. The experience of building had changed fundamentally: ‘a different relationship with the machine.‘


What it is and is not

What it is:

  • Giving control to an agent (e.g., Cursor’s Composer, Claude Code) and narrating requirements.
  • Side-projects completing in a single session that would previously have taken weeks.
  • Anyone — not just trained engineers — building functional software.

What it is not:

  • Professional-grade software engineering with correctness guarantees.
  • A substitute for understanding when quality, security, or correctness matters.

Relationship to Agentic Engineering

Karpathy is careful to distinguish vibe coding from Agentic Engineering:

‘Vibe coding is about raising the floor. Agentic engineering is about preserving the quality bar of professional software while moving faster.’

Vibe coding is valuable for exploration, prototyping, and use cases where the cost of errors is low. For production software — where security vulnerabilities introduced by a careless agent remain your vulnerabilities — agentic engineering discipline applies instead.


The MenuGen insight

Karpathy built a restaurant menu app (vibe-coded, on Vercel): it photographs a menu, OCRs the items, calls an image generator for each, and renders a visual version. Then he saw that a multimodal model with a single prompt could annotate the menu directly, with no pipeline. ‘All of my MenuGen is spurious. The app shouldn’t exist.’

This captures the deeper point: some intermediary software that vibe coding makes easier to build is software that shouldn’t exist in a Software 3.0 paradigm at all.


Michael Truell: vibe coding as the messy present

Michael Truell on Cursor and the World After Code provides the most critical product-builder view of vibe coding in the wiki. Michael distinguishes three states:

  1. Today’s vibe coding — generating code without understanding details. Problem: when the codebase grows large enough, you reach a point where you cannot change it because you do not understand what is underneath. Vibe coding creates things you cannot maintain.

  2. The world after code — the end state Michael is building toward: a representation of software logic that is terse, human-readable, and closer to pseudocode than formal language. You can edit it directly. You understand it at a high level. You do not need to understand the code underneath because the representation is designed to be comprehensible.

  3. The gap — the current lack of a product interface that gives non-coders (and vibe coders) real control over all aspects of the software. Vibe coding creates things where ‘the AI makes decisions that are unwieldy and you don’t have control over.’ This is a product design problem Cursor is trying to solve.

‘Right now, we lack the ability to let the tastemakers actually have complete control over the software.’

The implication: vibe coding is not the end state; it is the first step toward a new paradigm that does not yet exist as a product. The path from vibe coding to the world after code requires solving the control and comprehensibility problem — giving humans the ability to understand and directly edit the logic that AI is generating.

Taste as the irreplaceable skill. In the world after code, the engineer’s job is having the right idea for what should be built (taste) rather than getting the implementation details right (carefulness). Taste — specifying the what and the how things should work — is the irreplaceable human contribution when the implementation translation is automated. This connects to Product Taste.


Simon Willison: vibe coding as an irresponsibility claim

Simon Willison sharpens Karpathy’s definition into an explicit responsibility claim. Vibe coding = not looking at code = not responsible for it. Fine for personal tools where only you face the consequences. Not fine for code other people use.

The corollary: ‘agentic engineering’ (Willison’s term for professional AI-assisted coding) is not vibe coding, even if superficially similar. Agentic engineering requires the full weight of professional experience and you remain responsible for the output. The two are not a spectrum — they differ in accountability structure. [§ Simon Willison on Agentic Engineering and the Future of Code]


Lazar Jovanovic: vibe coding as a profession

Lazar Jovanovic is the first professional vibe coder in the sense of a full-time titled role — vibe coding engineer at Lovable. He arrived with no software engineering background (forestry engineering degree) and has built production tools including Lovable’s Shopify integration templates and internal analytics dashboards. His account documents what professional vibe coding looks like when pushed toward production quality and operational scale.

The two constraints. Jovanovic identifies two root causes behind almost every vibe coding failure: (1) the context window — the agent’s finite token budget forces trade-offs between reading existing code, reasoning, and producing output; (2) clarity of intent — vague inputs produce technically correct but wrong outputs. Most failures fall into the second category.

The genie framework. His framing: the AI agent grants the literal wish, not the intended one. ‘Make me taller’ produces a 13-foot giant. This demands spending the majority of work on wish-crafting (80% of time in planning/chat mode, 20% in execution) before any code is produced. [§ Lazar Jovanovic on Vibe Coding as a Profession, the Genie Framework, and PRD-Driven Development]

PRD-driven development. For production builds, Jovanovic generates five planning documents before writing any code: masterplan.md (project intent and audience), implementation.md (ordered technical decisions), design-guidelines.md (exact visual rules), user-journey.md (user flows), and tasks.md (granular execution queue). A sixth file, rules.md, goes into agent settings and tells the agent to read all PRDs before every action. This system means prompts in execution mode collapse to ‘proceed with next task,’ and the agent maintains coherence across sessions without re-explanation.

Design taste as the durable skill. Jovanovic’s hierarchy: judgment (knowing what to build) > design taste (knowing what good looks like) > copy (resisting AI-generated defaults) > technical orchestration (PRD management — temporary, will be automated). He argues that the taste gap is closed by deliberate exposure: following world-class designers, attempting to replicate work and studying the gap between the attempt and the original.

This view parallels Michael Truell’s ‘taste as the irreplaceable skill’ but from the practitioner rather than the product-builder side — Truell argues tools should give non-coders control over the logic; Jovanovic has built workflows that function within today’s tools while that product design problem remains unsolved.


Max Schoening: the first 10% is free

Max Schoening on Malleable Software, Agency, and Building Products in the AI Era articulates the product-design consequence of vibe coding’s cost collapse.

The claim: with AI-assisted development, the cost of building the first version of almost anything has collapsed to near zero. This is not just faster prototyping — it is a restructuring of what questions are worth asking.

Previously: ‘Can we build this?’ was load-bearing. Validation was expensive. You front-loaded research and design because implementation was the costly step. The question ‘what should we build?’ came after a long qualification process.

Now: ‘Can we build this?’ is almost always yes. ‘What should we build?’ is now the load-bearing question. The constraint has moved from implementation to judgment.

The skill whose value has increased: taste and strategy — knowing which of the many now-buildable things is worth building. This connects directly to Product Taste: when anything can be built quickly, the scarce resource is the ability to simulate how a specific audience will respond to it before committing to full execution.

The playground method operationalises this. Keep everything in a prototype as rough as possible except the one interaction that matters most. If you polish everything equally, you never discover whether the core interaction is worth investing in. If you polish only the core and keep everything else minimal, you get a direct answer. This is vibe coding with editorial discipline.


Naval Ravikant extends the vibe-coding framing along two axes: the substitution axis (PM work) and the economic axis (app store structure).

Vibe coding is the new PM. In Naval’s formulation, the role of product manager — describe what the product should do; give feedback to iterating builders — has been absorbed into the vibe-coding loop. Anyone with taste and a prompt now has the leverage profile previously reserved for PMs directing engineering teams. The AI coding agent is tireless, egoless, and operates 24/7.

The app tsunami. Naval predicts a structural outcome from the collapse of build costs: (1) best-of-category apps still win entire categories; (2) middle-tier 5–20-person SaaS companies serving enterprise niches get disrupted by vibe coding; (3) a long tail of micro-niche apps explodes; (4) platform aggregators capture super-wealth. ‘There’s no demand for average.’ [§ Naval Ravikant on Vibe Coding, Training Models, and the New App Economics]

The personal app store. Naval built his own: a webpage that receives AI-generated apps on demand, delivers them to his iPhone, and handles upgrades. The apps are tuned to his exact preferences — no compromise with the median user. This is the consumer end-state of vibe coding: software as a fully personal artefact. [§ Naval Ravikant on Vibe Coding, the Personal App Store, and Code as a Video Game]

Claude Opus 4.5 as the December 2025 inflection. Naval identifies this release as the moment coding agents crossed from novelty to genuinely productive — ‘an agent that stays on track, can build apps soup to nuts, can solve thorny problems, and really feels like having a junior programmer at your disposal.’ Before this inflection, vibe coding was interesting. After it, it became addictive.

Vibe coding as unbounded video game. Unlike a conventional game (fake rewards, bounded rules), vibe coding operates on a Turing machine. The objective is created by the builder and can expand indefinitely; the rewards are real. This makes it more engaging and more dangerous as a time sink than any designed game.


Zevi Arnovitz: vibe coding as PM practice

Zevi Arnovitz on Vibe Coding as a PM, Multi-Model Review, and Building with Claude Code documents the most complete practitioner workflow from the non-technical PM perspective.

Zevi Arnovitz (PM at Meta, zero coding background) built a paying product — StudyMate, a quiz-generation platform — using Cursor and Claude Code. His account provides a systematic workflow: seven /commands that encode each phase of development (create issue → explore → plan → execute → review → peer review → update docs), stored as markdown files in the codebase and invoked by name.

The multi-model peer review technique. Zevi’s most novel contribution: running three models simultaneously (Claude Code, Codex, Cursor Composer/Gemini) and using a /peer-review command that frames other models’ findings as ‘other team leads’ while asserting the primary agent’s greater context. The primary agent must explain why their findings are wrong, or fix them. This solves the code review problem for someone who cannot read code: you do not need to evaluate the reviews yourself; you let the agents adjudicate.

The postmortem loop. When the AI makes a mistake, the question is not ‘how do I fix this?’ but ‘what in your system prompt caused this error?’ The answer updates the CLAUDE.md or the relevant /command. Each failure is a prompt-improvement step. This is the mechanism by which vibe coding workflows compound over time.

This account bridges Lazar Jovanovic on Vibe Coding as a Profession, the Genie Framework, and PRD-Driven Development (professional vibe coder at Lovable) and Full Stack Builder (organisational model for any-function building). Jovanovic argues for spending 80% of effort in planning mode; Zevi’s workflow encodes that principle as a concrete /exploration-phase /command.


See also