Vibe Coding, Named

On 2 February 2025 the AI researcher Andrej Karpathy described "a new kind of coding" in which you "forget that the code even exists": you accept every change the assistant proposes and stop reading the diffs. The phrase he used for it, vibe coding, spread fast enough to become Collins Dictionary's word of the year for 2025, and it blurred as it spread.

By the end of that year people used it for any programming with AI help, as praise, as an insult and as a job description. This book needs a narrower meaning, one you can test against a specific change on a specific afternoon. Vibe coding is accepting code you have not read.

The Original Post

Karpathy's post was short and specific. "There's a new kind of coding I call 'vibe coding'," it began, "where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He described talking to the assistant instead of typing, accepting its changes without looking: "I 'Accept All' always, I don't read the diffs anymore." When an error message appeared he pasted it back in with no comment, and that usually fixed it.

In the same post he named the limit. "It's not too bad for throwaway weekend projects," he wrote. The post described a way of working and its scope in one breath, and the scope was a weekend project nobody would maintain. What spread was the first half of that sentence.

How the Term Spread and Blurred

Within weeks, "vibe coding" was being used for any code written with an assistant's help, including code that its author had read line by line. On 19 March 2025 the programmer and writer Simon Willison published a reply that drew the line this book adopts. If a model wrote the code, he argued, "and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that's not vibe coding, it's software development."

The blurred meaning won the popularity contest anyway. On 6 November 2025 Collins named vibe coding its word of the year, describing it as using AI, prompted in natural language, to write computer code. That broad sense is fine for a dictionary. It is useless for deciding whether a particular pull request is ready to merge, because under it every change written with an assistant is vibe coding and the word stops distinguishing anything.

The broad meaning fails a team in two directions at once. Engineers who read every line of what their agent wrote get lumped in with those who read nothing, and stop using the word because it insults them. Engineers who read nothing hide behind it, because if everyone is vibe coding then nobody is doing anything unusual. Either way, the one distinction that predicts a third week, whether anyone read the code, disappears from the conversation.

The Definition This Book Uses

Vibe coding is accepting code you have not read. The test is not who typed it, how much of it there is or whether it runs. The test is whether you could explain each line to a reviewer: what it does, why it is there, what would break if it were removed.

"Explain" is a real bar, and it is higher than "recognise". Most programmers can look at a plausible function and nod. Explaining it means saying why the comparison is greater-than-or-equal rather than greater-than, what happens when the list is empty, and why the result is rounded where it is. If a reviewer's question about any line would send you back to the agent to find out, that line was accepted unread.

By that test, the tool and the person do not decide anything. A programmer who accepts a 40-line agent diff unread at six in the evening is vibe coding as fully as someone with no programming background building an app by conversation. An engineer whose agent wrote 90% of a change, and who read and understood all of it, is not vibe coding at all. The definition is about one act, and it applies to a single diff.

What It Skips

Vibe coding skips three things, and each is a stage of the loop this chapter ends on. It skips reading, so nobody knows what the code does. It skips testing beyond clicking through a demo, so the only evidence is that the code ran once, on the inputs somebody happened to try. And it skips small versioned steps, so when something breaks there is no earlier good point to return to and nothing small enough to compare against.

Each skipped step has its own chapter later in the book: reading in Chapter 6, testing in Chapter 8, small commits in Chapter 9. What makes vibe coding dangerous on a team is that all three are skipped at once, and each one was the backstop for the others.

Why It Feels Like Progress

Every round of vibe coding produces visible change. You describe something, it appears. An error comes up, you paste it back, it disappears. The screen moves forward every few minutes, and nothing in the experience signals what was skipped. That feedback is real, and it is the reason the practice spread so fast: it feels like the most productive afternoon you have had in months.

The feedback measures one thing, though: does it run now. It says nothing about whether the code does the right thing for inputs you have not tried, whether anyone can change it next month, or whether the error that disappeared was fixed or hidden. Kai's waitlist, later in this chapter, is the bill for everything that feedback did not measure.

The error loop deserves suspicion of its own. When you paste an error back and it disappears, the agent has done one of two things. It has fixed the cause, or it has made the error stop appearing: caught the exception and carried on, added a default where a value was missing, skipped the check that failed. Both look identical from the outside, because in both the error is gone. Chapter 7 calls the second kind a symptom fix, and vibe coding is the practice that cannot tell the two apart.