What Is Vibe Coding? The Term, the Practice, the Risk

Vibe coding is writing software by describing what you want in plain language and letting a large language model produce the code, then steering it with follow-up prompts rather than editing the output line by line. Andrej Karpathy coined the term in February 2025. The defining move is not the AI, it is choosing not to read the diff.

That last part is what makes the term useful and what makes it contentious. Plenty of people use AI assistance and read every line it produces. That is not vibe coding, that is just working with a good autocomplete. Vibe coding is the further step of treating generated code as a black box you evaluate by running it.

Where did the term come from?

Karpathy, a co-founder of OpenAI and previously the head of AI at Tesla, posted the phrase in February 2025. His description was deliberately loose: you give in to the vibes, embrace exponentials, and forget that the code even exists. He described accepting all changes without reviewing diffs, pasting error messages back in without comment, and sometimes routing around a bug instead of fixing it.

It spread fast. Merriam-Webster listed it as “slang and trending” by March 2025, about a month later. Collins English Dictionary named it Word of the Year for 2025. For a phrase that started as one person’s half-joking description of a Saturday afternoon, that is an unusual trajectory, and it happened because the phrase named something a lot of people had started doing and had no word for.

A close-up of two hands typing on a laptop keyboard, the screen above them filled with code. — Nothing in the physical act changed. What changed is how much of what appears on the screen passed through the head of the person at the keyboard. *Photo: cottonbro studio via Pexels. Pexels License.*

What does vibe coding actually feel like?

The honest answer is that it feels like flow, which is exactly why it caught on and exactly where the danger sits.

Ordinary programming has a high switching cost. You hold a model of the system in your head, and every interruption knocks it over. The research on this is old and unambiguous: a study of 24 information workers, shadowed second by second at their desks, found 57 percent of their working spheres were interrupted, and that the expensive part was never the interruption itself but the climb back to where you had been.

Vibe coding lowers the height of that climb. You are not holding the syntax in your head, so losing it costs less. You describe, you run, you look at the result, you describe again. The loop is short enough to stay inside, and staying inside a short loop is most of what flow is.

That is a real benefit and worth naming plainly, because most writing on this subject is either sales copy or scolding. The reason people vibe code is not laziness. It is that the loop feels good, and a loop that feels good is one you stay in for four hours instead of forty minutes.

Is vibe coding safe for real projects?

This is where the evidence turns against the practice, and it is worth being specific rather than vague.

An analysis published by CodeRabbit in December 2025 found that AI co-authored code contained 1.7 times more “major” issues than human-written code, and 2.74 times more security vulnerabilities. In May 2025, applications built on the Lovable platform were found to carry vulnerabilities affecting 170 of 1,645 web apps examined.

The maintainability picture is separately concerning. GitClear’s analysis in early 2025 documented that the share of code being refactored fell from around 25 percent to under 10 percent by 2024, while duplicated code quadrupled. Those two numbers describe the same problem from both ends: more code is being added and less of it is being consolidated.

The four measurements this section cites, on one axis. The bottom two are the same problem seen from each end: more code arriving, less of it consolidated afterwards. Chart: Vibefu, from the figures cited above.

Simon Willison, who is broadly positive about AI-assisted development, put the limit clearly: vibe coding your way to a production codebase is clearly risky. A January 2026 academic paper went further, arguing the practice reduces maintainer engagement in open source and pushes projects toward the same small set of library choices.

None of that says do not do it. It says be honest about which mode you are in.

When is it the right tool?

The distinction that survives contact with the evidence is not “AI good” or “AI bad”, it is whether anyone will have to understand this code later.

Vibe coding suits work where the output is disposable or self-evident: a script you will run twice, a prototype whose job is to be thrown away once it has answered a question, a personal tool with one user, a visual experiment where you can see whether it worked. In those cases you genuinely do not need to understand the implementation, because the cost of it being wrong is that you notice and try again.

It suits production systems badly, for the reason the research keeps pointing at. Code that other people maintain, code handling anyone’s data, anything where a failure is quiet rather than loud: these need someone to have read the diff. The 2.74 times figure on security vulnerabilities is not an argument against the tool, it is an argument against skipping review on the code paths where a vulnerability matters.

A practical version of the rule: if you could not describe, in a sentence, what the code you just accepted does, do not ship it anywhere it can hurt someone.

A decision diagram branching from the question of whether anyone will have to understand this code later. No leads to throwaway scripts, prototypes, single-user tools and visual experiments. Yes leads to code others maintain, anything handling user data, and anything whose failures are quiet. — One question does most of the work, and it is not a question about the tool. *Diagram: Vibefu.*

Does vibe coding make you a worse programmer?

Not automatically, but the failure mode is real and worth watching for.

A working programmer's desk in an office cubicle: two monitors, a wall of reference books and manuals, papers, cables and accumulated hardware. — A desk like this is a record of somebody having read a great deal of code, most of it not their own and much of it bad. That reading is where the modelling skill comes from, which is the specific thing a practice built on not reading does not build. *Photo: Bsmalley via Wikimedia Commons. CC BY-SA 3.0.*

The skill that atrophies is not syntax, which was never the valuable part. It is the modelling: holding a system’s shape in your head well enough to predict where a change will ripple. That skill is built by reading code, including bad code, including your own from six months ago. A practice built on not reading the output does not build it.

The people who seem to do well with this are the ones who move between modes on purpose. They vibe code the exploratory parts, then slow down and read carefully at the boundaries where it matters, and they know which one they are doing at any moment. The people who struggle are the ones who slid into one mode and stopped noticing.

The useful way to think about it

Vibe coding is a legitimate entry into flow, which is why this site treats it as part of the same subject as the six conditions that decide whether a working session goes well. The loop is short, the friction is low, and those are the conditions creative work has always needed.

It is also a way of producing code nobody has read. Both of those are true at once, and the practice only gets dangerous when someone forgets the second one because they are enjoying the first.

Use it where being wrong is cheap. Read the diff where it is not.