What Is Vibe Coding? The Term, the Practice, and the Limits

Where the term came from

Andrej Karpathy, a founding member of OpenAI and formerly director of AI at Tesla, coined the phrase in a post on X on February 2, 2025. His wording is worth quoting exactly, because most later definitions soften it: "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 his own practice in the same post as seeing stuff, saying stuff, running stuff and copy-pasting stuff — and noted it mostly works. He was talking about weekend projects, using voice dictation into an AI coding tool, deliberately not looking at what came back.

The phrase spread quickly enough that Collins Dictionary named vibe coding its word of the year for 2025, announced on November 6, defining it as using AI prompted by natural language to write code, and citing a sharp rise in usage since the term first appeared that February.

Two things are worth noticing about the origin. It came from someone with deep expertise describing a deliberately casual mode of working, and it was about throwaway projects. Both details get dropped when the term is used as a pitch.

What it actually means in practice

The loop is simple. You describe what you want. The model writes code. You run it. If it does the right thing, you move on. If it does not, you describe the problem and the model tries again. You never open the files.

That last clause is what makes it vibe coding rather than ordinary AI-assisted development. The judgment moves from the code to the behavior: you are not asking "is this written correctly?" but "does the thing do what I wanted when I ran it?" Errors get pasted back rather than diagnosed.

It is genuinely fast, and the speed is not an illusion. For a certain class of problem you can go from an idea to something working in an afternoon without knowing the language it is written in. That is a real change and it is why the term caught on.

If you would rather have this built for you than build it yourself, an AI consultation is where we scope that.

Vibe coding is not the same as using AI to code

This is the distinction that matters most and the one most articles blur, usually because blurring it makes for a better headline.

A professional developer using an AI assistant reads every diff, rejects the parts that are wrong, and remains responsible for what ships. That is AI-assisted engineering. It is now ordinary practice, and it is not vibe coding, no matter how much of the typing the model did.

Vibe coding is specifically the version where nobody reads the output. Karpathy's phrase — forget that the code even exists — is precise about this. The two get conflated constantly, and the conflation is how you end up with unreviewed code in places it should never be, described in a status update as "we used AI for it," which sounds like the first thing and is actually the second.

If you take one thing from this: the question is never whether AI wrote it. The question is whether a competent person read it before it reached anything that matters.

Where vibe coding genuinely works

There is a real category of work where not reading the code is the correct trade, and it is larger than skeptics allow.

• Prototypes meant to be thrown away — proving an idea is worth building properly before anyone commits to it.
• Personal tools with one user. A script that renames your files or reformats a spreadsheet has no blast radius beyond your own afternoon.
• Internal one-offs: a chart for a meeting, a data cleanup, a quick conversion between formats.
• Learning and exploration, where seeing something work is what makes the concept stick.
• Spikes inside real projects — answering "is this approach viable at all?" before designing it, then discarding the spike.
• Anything where the cost of it being wrong is that you notice and try again.

Where it fails, and how you find out

The failure pattern is consistent and it is not that the code does not work. It is that the code works, right up until it does not, and by then nobody understands it well enough to fix it.

Unread code accumulates decisions nobody made deliberately. Which library it pulled in, how it handles an empty input, what happens when two people do the same thing at once, where it put the credentials. Each of those is fine until the day it is not, and the person who has to answer for it has never read the file.

The specific problems worth naming: secrets written into source because the model needed somewhere to put them; input passed unvalidated into a database query; error handling that swallows failures silently, so the system looks healthy while quietly losing data; and a dependency list nobody has audited.

Then there is the eighty percent wall. The first eighty percent of a project vibe codes beautifully. The last twenty — the edge cases, the failure states, the awkward integration, the thing that only breaks under real load — is exactly the part that requires understanding the code. Projects do not fail at the start of vibe coding. They fail at the point where the approach quietly stopped being appropriate and nobody noticed the transition.

The line: does it touch anything that matters?

One question separates the safe use from the dangerous one. Does this code touch real customers, real money, real personal data, or anything you would have to explain to someone if it went wrong?

If no, vibe code freely. The worst outcome is a wasted afternoon, and the speed is worth far more than the rigor would be.

If yes, the code has to be read by someone who can evaluate it before it goes anywhere near production. That person can absolutely have used AI to write it — that is normal now and it is faster. What they cannot do is skip the reading.

For a business the practical version is a rule about environments rather than about tools: anything running against production data or facing a customer gets reviewed, regardless of what wrote it. That is enforceable and it does not require anyone to relitigate whether AI is acceptable.

If you are not a developer

The honest position is somewhere between the two loud ones. You will not be told that software is now free, and you will not be told to stay away.

What has genuinely changed is that a non-developer can now build working internal tools — the small automations and utilities that were never worth a developer's time and so never got built. That category is large and it is real value.

What has not changed is the distance between working and shippable. Software that other people depend on needs authentication, error handling, backups, monitoring, and a plan for the day it breaks at an inconvenient hour. None of that shows up in the demo, and none of it is what the model optimized for when it made your prototype run.

The useful way to think about it: vibe coding gets you a convincing answer to "should this exist?" That is a genuinely expensive question to answer any other way, and it is worth doing. Turning the answer into something customers rely on is a separate job with a different standard.

Using it well

A few habits separate people who get value from this from people who generate a mess and conclude the tools do not work.

Decide up front which mode you are in and say it out loud. "This is a throwaway prototype" and "this is going to production" are different activities, and the damage comes from starting the first and silently drifting into the second.

Keep the throwaway work genuinely separate — its own directory, its own repository, not a branch of something real. Code migrates toward production by accident when it is sitting nearby.

Put it in version control anyway, even for prototypes. It costs nothing and it is the difference between rolling back a bad change and losing the afternoon.

And when a prototype turns out to be worth keeping, rewrite it deliberately rather than hardening it in place. That decision is much cheaper made once, on purpose, than discovered six months later in an incident.