What Is Vibe Coding? Definition, Origin & Limits

Vibe coding is a way of building software in which you prompt an AI model in plain language, accept the code it generates without reading it carefully, and keep steering by describing what you want rather than editing what the model wrote. The defining move is the abdication of review: you trust the output, run it, and if something is wrong you describe the problem back to the model rather than debugging the code yourself. Taken to its logical end, you barely look at the code at all.

The term has a precise origin. On 2 February 2025, Andrej Karpathy, a co-founder of OpenAI and the former director of AI at Tesla, posted: “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.” He described accepting diffs without reading them, pasting error messages back with no comment, and treating the codebase as something you talk to rather than something you read. Crucially, he framed it as fun for throwaway weekend projects, not as a recipe for production software.

The phrase escaped its origin almost immediately. Within months it was shorthand for AI-assisted development in general, and by late 2025 both Merriam-Webster and Collins were tracking it as a notable word of the year. That popularity is exactly why the definition is now contested: many people use “vibe coding” to mean any coding with AI, when Karpathy's original sense was narrower and more honest, the low-discipline mode where you deliberately do not review the code.

In practice, vibe coding is a tight prompt-accept-run loop. You are not writing code so much as negotiating with a model that writes it for you, and the whole session lives in natural language. A typical loop looks like this:

1. 1

   Describe the outcome, not the implementation

   You state what you want in plain language, "build me a landing page with a signup form" or "make a script that renames these files by date," and let the model choose the stack, structure, and approach. The prompt is the plan; there is no separate design step.
2. 2

   Accept the generated code without reading it

   The model produces files or diffs, and you accept them. This is the load-bearing part of the definition: you do not review the code line by line, you assume it is roughly right, and you move straight to running it.
3. 3

   Run it and react to what happens

   You execute the result and judge it by behaviour, not by reading. Does the page render? Does the script produce the right files? The running artifact, not the source, is your feedback signal.
4. 4

   Feed problems back as prompts

   When something breaks, you describe the symptom or paste the error message back to the model and let it patch itself, rather than opening the file to fix it. You debug by conversation, staying in the vibes rather than dropping into the code.

Modern coding agents make this loop remarkably smooth, because they do more than emit text: they read your files, run commands, install packages, and iterate on their own output. That is why the experience feels less like autocomplete and more like delegating to a very fast junior who never asks you to read their work. The quality of what you get out depends heavily on what the agent can see, which is the subject of context engineering, even when you never look at the code yourself.

Vibe coding is not a mistake to be corrected, it is a legitimate mode that is correct for a specific class of work. The common thread is that the code is disposable or personal, so the cost of an unreviewed defect rounds to near zero, and skipping review is a rational trade rather than negligence.

In all four cases, vibe coding earns its keep by removing steps, no spec, no review, no process, that would be pure overhead on code nobody has to live with. This is also why it lowered the barrier so dramatically: people who could never have written the code themselves can now produce working software by describing it, which is a genuine expansion of who gets to build.

The same properties that make vibe coding fast make it dangerous on code that has to last. When nobody has read the code, several problems compound quietly, and they usually surface at the worst possible time, after the software already has users.

The important distinction is not between using AI and not using AI, it is between two ways of using the same agents. Vibe coding accepts the output; the disciplined alternative operates the agent like a team member. That alternative, called agentic engineering, keeps the exact same Claude Code or Codex session but wraps it in engineering controls: a written spec before any code, a human approval gate, an isolated branch per task, verification against acceptance criteria, and a reviewed pull request at the end.

The dividing question is simple: will anyone have to maintain this code? If no, review is ceremony and vibe coding is the right call. If yes, every unread diff is a small loan against the future, and the disciplined loop is what pays it back on time. The full side-by-side, when each is right and how a prototype graduates, is in vibe coding vs agentic engineering, and the successor discipline itself is defined in what is agentic engineering. The case that orchestration, not generation, is now the real bottleneck is made in engineering with AI agents.

You will see “vibe coding is dead” headlines, and the honest answer is that the word is fading while the practice split in two. Karpathy, who coined the term, called it passé in early 2026 and proposed agentic engineering as the successor, right around the time it hit peak mainstream saturation. But the casual mode he originally described, prototyping and personal tools, is alive and completely fine. What died is vibe coding as an acceptable description of production work, which rebranded around discipline. The full timeline is in is vibe coding dead?

AIDEN is built for the honest version of this story, that you want to vibe code sometimes and engineer carefully at other times, often on the same project as it grows up. It is a macOS desktop app that orchestrates your local Claude Code and Codex CLIs on a kanban board of epics and stories, and you bring your own inference: your existing Claude or Codex subscription, or an API key. AIDEN does not replace the agents, it is the cockpit around them.

Its edge is making the graduation from vibes to engineering a setting, not a rewrite. When you want speed, prompt freely. When work has to be maintained, AIDEN drafts a spec from your story and its codebase analysis, gated on your approval so no agent codes until you say so, runs each story in its own git worktree, and lands it as a PR with the spec attached for review. That is the same discipline covered in spec-driven AI development, made structural rather than a matter of willpower. Vibe when you want, engineer when it matters, without ever leaving the tool. Solo is $19/month, and it is free for one project, which is a cheap way to feel the difference on a real story in your own codebase.