What the post actually said

On 2 February Karpathy described a new kind of coding in which you fully give in to the vibes, embrace exponentials, and forget that the code even exists. The details are the point. He was talking to Cursor's Composer through the SuperWhisper dictation tool and barely touching the keyboard. He asked for things like halving the sidebar padding because finding the CSS was too much effort. He always clicked Accept All and no longer read the diffs. When an error came up he pasted it back with no comment and that usually fixed it. When it did not, he asked for random changes until the bug went away.

He also wrote that the code grows beyond his usual comprehension, that it is not too bad for throwaway weekend projects, and that it is not really coding, since he just sees stuff, says stuff, runs stuff and copy pastes stuff, and it mostly works. Every qualifier that later got dropped from the term was in the original text. It was a description of a mode of play, offered with some amusement, by someone who could have written every line himself.

Why it stuck

The phrase filled a gap. People had been using models to write code for two years and had no word for the specific practice of not reading what came back. Copilot users had a name for autocomplete. Nobody had a name for the thing where you stop being the author. Karpathy's post gave the practice a label and, because he is who he is, gave permission to admit to it.

Uptake was fast. Merriam-Webster listed it as slang and trending on 8 March, defining it as writing code by telling an AI program what you want and letting it create the product for you. On 6 March, Jared Friedman of Y Combinator said that a quarter of the Winter 2025 batch had codebases that were about 95 percent generated, with the caveat that every one of those founders was fully capable of building the product from scratch, and that the 95 percent figure excluded routine code like imports. By November Collins had named it word of the year, ahead of a shortlist that included clanker, broligarchy and aura farming, and summarised it as programming by vibes rather than variables.

The argument over what it means

The word spread faster than its definition, and the definition drifted. In March Simon Willison tried to pin it down. His version is that vibe coding is building software with a model while deliberately not reviewing the code. If a model wrote every line but you have reviewed, tested and understood it all, that is not vibe coding, that is using a model as a typing assistant. On that definition most professional use is not vibe coding, and the YC founders with 95 percent generated codebases may or may not be doing it depending on whether they read the output.

Andrew Ng objected to the term itself in June, on the grounds that it misleads people into thinking engineers using these tools are just going with the vibes, when the work of specifying, testing and steering is real. Both objections are about the same thing. The word that caught on names the least careful version of a practice that mostly is not done that way, and people who do the careful version resent being described by it.

What the term revealed

We find the drift more informative than the definition. Karpathy's post was a candid account of what a researcher does with a model when nothing is at stake. It was popular because a great many people recognised themselves in it, including people who would never admit to Accept All on a codebase they are paid to maintain. The practice existed before the word. The word made it visible, and the visibility is what caused the argument.

It also exposed a split in how researchers talk about model capability. In the same breath as the joke, Karpathy said the models were getting too good, which was the serious claim. If you can build a working web app without reading the code, then the code reading step was doing less than we thought, at least for throwaway projects. What the following months added is the other half. Willison's distinction, the YC caveat about technical founders, and the growing list of security and maintainability worries all point at the same fact. The step you skip when vibe coding is the step that carries the risk, and the risk scales with how long the code has to live.

What we would want measured

The word is now a dictionary entry and the practice is still mostly anecdote. We would like to see a study that takes a set of small projects, has half built by vibe coding in Willison's strict sense and half with review, and follows them for six months. The interesting number is how the defect rate and the cost of the first substantial change differ, and whether the gap is closing as models improve.

Until someone runs that, our own rule is Karpathy's original one, stated plainly instead of as a joke. Give in to the vibes on things you are willing to throw away. Read the diffs on anything you are not.

Sources

  1. Wikipedia, Vibe coding
  2. Andrej Karpathy's post of 2 February 2025 (archived on Thread Reader)
  3. Simon Willison, Not all AI-assisted programming is vibe coding (but vibe coding rocks), 19 March 2025
  4. TechCrunch, A quarter of startups in YC current cohort have codebases that are almost entirely AI-generated, 6 March 2025
  5. Collins Dictionary, Word of the Year 2025