What is vibe coding?

Vibe coding, defined

Vibe coding is programming by intent. You tell an AI system what you want ("a landing page with a waitlist form", "a script that renames these files by date"), the model writes the code, and you evaluate the outcome by using it rather than by reading the source. When something is wrong, you do not open the file; you describe the problem in plain language and let the model fix it.

The defining trait is not that AI writes code. AI writes code in almost every modern workflow. The defining trait is where your attention goes: in vibe coding you review behavior, not lines. The code itself becomes something like compiler output, an artifact you trust the tool to manage.

In practice there is a spectrum. On one end, pure vibes: never look at the code at all. On the other, supervised agentic coding, where an AI agent does the work but you gate risky commands and skim the diffs. Most people who do this seriously live somewhere in the middle, and move along the spectrum depending on what is at stake.

Where the term comes from

Andrej Karpathy, co-founder of OpenAI and former director of AI at Tesla, coined the phrase in a post on X on February 2, 2025:

"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." Andrej Karpathy, February 2, 2025

He was describing weekend projects, and he said so in the same post: fine for throwaway experiments, "not too bad for" quick demos. The internet took the first half and ran. Within weeks there were vibe coding courses, vibe coding startups and vibe coding job posts. By March 2025, Y Combinator was reporting that about a quarter of its winter batch had codebases that were roughly 95 percent AI-generated. In November 2025, Collins Dictionary named "vibe coding" its Word of the Year.

What actually happens when you vibe code

Modern vibe coding runs on AI coding agents: tools like Claude Code, Codex CLI or Gemini CLI that do not just suggest code but act. A typical loop looks like this:

1. You state an outcome. "Add dark mode to this site. Respect the system setting, add a toggle in the header, remember the choice."
2. The agent plans and reads. It searches your files, figures out where styles and state live, and lays out steps.
3. It edits and runs. It writes the changes, runs the build or the tests, reads the errors, and fixes its own mistakes, often several times in a row.
4. You react to the result. You look at the running app, not the diff: "the toggle is ugly, move it next to the logo." Repeat.

One loop like this can touch a dozen files and run twenty commands. That is the part most people underestimate: vibe coding is not one prompt and one answer, it is delegating an entire work session. Which is also why the biggest practical problem is visibility, knowing what the agent actually did while you were watching the result instead of the code.

Vibe coding vs. agentic coding vs. autocomplete

The three terms get mixed together constantly. They describe different levels of delegation:

The line between the last two is simply how much you look. The tooling is identical, which is why "vibe coding" in job posts usually means agentic coding done by someone who knows when to stop vibing.

What people actually vibe code

• Prototypes and MVPs: a working demo of a product idea in an afternoon, to test with real users before investing.
• Personal tools: the expense tracker, the CLI that organizes your downloads, the dashboard nobody else will ever see.
• Websites and landing pages: the single most common first project, because the feedback loop is visual.
• Internal utilities: scripts and small apps where "works for us" is the whole requirement.
• Learning experiments: poking at a new framework by having an agent build something in it, then asking it to explain what it did.

Where vibe coding shines

Speed is the obvious win, but it is not the deepest one. The deepest one is that the cost of trying things collapses. When a prototype costs twenty minutes instead of two days, you try ten ideas instead of one. People who cannot write code ship real tools. People who can write code stop burning their evenings on boilerplate. For anything where the stakes are low and the iteration speed matters, it is simply the right tool.

Where it bites

Everything that makes vibe coding fast comes from not looking, and everything that goes wrong comes from the same place. The failure modes are consistent enough to list:

• Security holes you never saw. Hardcoded API keys, missing auth checks, SQL built by string concatenation. The code works, which is exactly the problem: working and safe are different properties.
• Destructive commands. An agent that can run anything will occasionally run something you would not have approved: dropping a database, force-pushing, deleting files it decided were stale.
• Invisible debt. Ten quick sessions produce code that no human has ever held in their head. The eleventh session, the one where something subtle breaks, gets expensive.
• Confidently wrong fixes. Agents report success in the same tone whether or not the thing works. "Done!" is a claim, not a fact.
• Lost context. Close the terminal and the session's reasoning is gone. Next time, the agent rediscovers your project from scratch and sometimes contradicts its own earlier decisions.

None of these are arguments against the practice. They are arguments against doing it blind.

How to vibe code without losing the plot

The people who get consistent results follow the same few rules, whether they know each other or not:

• Everything in git, always. Checkpoint before and during agent sessions so any change can be rewound in seconds.
• Small tasks, small loops. One feature per session. Giant prompts produce giant, unreviewable changes.
• Make the agent prove it. "Done when the tests pass" turns a claim into a check the agent runs itself.
• Gate the dangerous stuff. Keep approval prompts on for deletes, deploys and anything touching credentials or data.
• Watch the work, not just the result. You do not need to read every line, but you should be able to see what the agent is doing: which files it reads, what it runs, what it costs.

That last point is the one we care about most. The terminal shows a wall of scrolling text that nobody actually watches, and that gap between "approved" and "seen" is where vibe coding goes wrong. It is the reason we built our own tool the way we did.