What Is Vibe Coding, Really?

Andrej Karpathy coined the phrase in early 2025, describing a way of building software where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." You describe what you want, the model writes it, you look at the result rather than the implementation, and you iterate on the behavior instead of the source.

That original framing was half joke, half prophecy. The joke part was real — he was describing weekend throwaway projects. The prophecy part is that within a year, people were running businesses on software built exactly this way.

The actual definition

Vibe coding is building software by describing intent in natural language and letting an AI produce the implementation, where your primary feedback loop is the running result rather than the source code.

That last clause is the whole thing. It's what separates vibe coding from ordinary AI-assisted development.

If you're reading every diff, understanding each change, and using AI as a very fast typist — that's AI-assisted coding. Valuable, but not new in kind. You're still the engineer.

If you're describing an outcome, running what comes back, and responding to what you see rather than what was written — that's vibe coding. The code is an intermediate artifact you may never fully read.

Both are legitimate. They fail in completely different ways, which is why conflating them causes so much confusion.

What it's genuinely good at

Getting to something real, fast. The distance between "I have an idea" and "I have a working thing on a URL" has collapsed from weeks to hours. For validating whether an idea is worth pursuing at all, nothing else comes close.

Removing the setup tax. A huge amount of what stopped non-programmers from building was never logic — it was toolchains, package managers, environment variables, and deployment. Those barriers are now largely negotiable in plain English.

Unfamiliar territory. Even experienced engineers vibe code in stacks they don't know. Writing your first Swift app is far faster when something else already knows the idioms.

Throwaway work. Internal scripts, one-off data transforms, personal tools with one user. The code quality genuinely does not matter, and pretending otherwise is its own kind of waste.

Where it breaks

The failure mode is specific and predictable, and it isn't "the AI writes bad code." Modern models write reasonable code most of the time.

The failure is that you accumulate a system nobody understands. Every prompt adds working behavior and a small amount of structural debt. For the first while, nothing is wrong. Then you hit a bug that spans several of those additions at once, and you're debugging a codebase you didn't write, can't hold in your head, and can't explain to the model well enough for it to help.

This has a shape. It shows up around the point where the project has real users, real data, or real money attached — precisely when it stops being acceptable to start over.

Three specific things go wrong most often:

1. Security is invisible until it isn't. An exposed API key or a database table without access rules doesn't produce an error. The app works perfectly. You find out when someone else finds out.

1. Nobody owns the architecture. Each prompt is locally sensible. Fifty prompts later there are three different ways to fetch data and two competing patterns for state, because no one was making decisions above the level of the individual request.

1. The context runs out. The model can't see your whole project. As it grows past what fits in a prompt, the AI starts making changes that are correct in isolation and wrong in context — the single most common source of the "it fixed one thing and broke two others" spiral.

The useful mental model

Think of it as a spectrum with a decision point, not a binary.

At one end: prototypes, personal tools, throwaway experiments. Vibe code freely. Don't read the code. Don't write tests. Speed is the entire point and rigor is pure cost.

At the other end: anything with users, payments, or personal data. Here the code has to be understood by someone — not necessarily written by hand, but understood. Reviewed, tested, and structured deliberately.

The decision point is the moment a project crosses from the first category to the second. Almost every vibe-coding disaster is the same story: a project crossed that line and nobody noticed, because crossing it doesn't generate an error message.

That transition is worth being deliberate about. It usually means: get it into version control, add tests around whatever handles money or credentials, read the parts of the code that touch authentication, and actually understand your data model. None of that requires abandoning AI assistance. It requires changing what you're asking for.

Why the definition matters

There's a loud argument online between people who say vibe coding is the future of software and people who say it produces unmaintainable garbage. Both camps are describing real things and talking past each other, because they're using one term for two different activities.

Vibe coding a prototype is not the same activity as vibe coding a production system, in the same way that sketching is not the same activity as drafting a blueprint. Nobody argues that sketching is bad engineering. The problem only appears when someone tries to build from the sketch.

Know which one you're doing. If you're sketching, sketch fast and don't apologize for it. If you're building something people will depend on, the AI is still doing most of the typing — but you need to be the one holding the map.

---

Stuck somewhere in the middle of this? The Rescue service exists for exactly that: projects that got 80% built and stopped moving.