Why It Works for a Weekend

Vibe coding is the right way to write some code: code whose only job is to answer a question and then be deleted. Karpathy said as much when he named it, and he was right. The failure is not the practice. It is the promotion, the moment a throwaway quietly becomes something other people depend on.

This page takes the legitimate uses seriously, puts a price on them, and names the guard rails that keep a throwaway thrown away. Its subject is not whether to read generated code, which the rest of the book settles, but which code is honestly not worth reading.

The Legitimate Uses

Four kinds of code qualify. A prototype that answers "is this worth building?": a clickable mock of a class-pass bundle that the business can try before anyone writes a specification. A one-off script, such as Kai's count of last month's no-shows from a spreadsheet export, run once, read for its answer and deleted. A learning spike in an unfamiliar library, where the goal is to find out what the library does, not to keep what you wrote while finding out. And a mock-up to show the business what a screen could look like.

In each of these, the code's value is the answer it produced. Kai wants to know whether no-shows cluster on Monday evenings. Once the count says yes, the script has done its job, and an afternoon spent reading 200 lines of generated spreadsheet parsing would buy nothing the answer did not already give.

The learning spike is the use most often underrated. You want to know how the date library behaves around a change of clocks, or what a payment provider's sandbox returns when a card is declined. Asking an agent to write throwaway code that pokes at the library, and watching what comes back, is a fast way to learn the shape of a thing. What you keep is what you learned. The code that taught you is usually wrong in ways that did not matter for the lesson.

The Economics

Reading is the expensive stage of the loop. Chapter 1 put a 300-line change at the better part of an hour, and Chapter 6 puts a careful read of 140 lines at about twenty minutes. For code deleted tomorrow, the cost of an unread bug is small and bounded: the worst outcome is a wrong answer to one question, which you can often check by eye. For code that will be changed for three years, the cost of an unread bug is unbounded, because every later change builds on it and every later reader inherits it.

So the same 400 lines are a good deal on Friday and a liability on Monday, if anyone keeps them. Nothing about the code changes over the weekend. What changes is its expected lifetime, and lifetime is what decides whether reading pays for itself.

Notice who pays when the deal goes wrong. On Friday the person who saved the reading time is the person who wrote the spike. On Monday, if the spike is kept, the cost of the unread code moves to whoever changes it next, who never agreed to the trade and does not know it was made. That is why promotion is a team problem rather than a personal one.

A prototype the business clicks through, then discards→Vibe code it, contained

A script that reads last month's export and prints a count→Vibe code it, then delete it

A 30-line script that fixes rows in the production database→Read every line first

A feature due next sprint, built on last week's spike→Build it again through the loop

Keeping It Throwaway

A throwaway needs no review, but it does need containment. Put it in a separate repository or a directory outside the product, where nothing can import it by accident. Keep production credentials and shared databases out of its reach: a vibe-coded script can do anything the environment lets it do, and you agreed in advance not to read what it does. Give it a name that says what it is, a directory called "spike" or a repository with "throwaway" in its name. And set one rule: nothing merges from it into the product.

The rule that matters most is the last one. The answer moves into the product; the code does not. If the no-show count shows a Monday cluster, what reaches the booking service is a decision, perhaps a reminder sent on Monday mornings, specified and built through the loop. Kai's script stays in his scratch directory until he deletes it.

Time-box it too. A spike with an end date, a day or two, is a spike. One that is still being extended three weeks later, a fix here and a feature there, has quietly become a product without ever going through the decision to build one, and it carries every unread line of its spike days with it.

Promotion Is the Failure

"It already works, let's just tidy it up" is the sentence that turns unread code into product code without anyone reading it. Tidying is not reading. It renames variables, splits a long function and adds a docstring, and leaves every decision the agent made in place, now looking deliberate.

Spikevibe-coded, answers a question

→

"Just tidy it up"promotion

→

Product codethat nobody has read

Spikevibe-coded, answers a question

→

Findings and examplescarried forward

→

Built againthrough the loop

The cheap path from spike to feature keeps the spike's lessons and the examples it proved, and builds the feature again. The examples are the valuable part: concrete inputs and the outputs that turned out to be right, which become the acceptance criteria of the task in Chapter 5 and then the tests. Rebuilding takes a fraction of the time the spike did, because the spike spent most of its time finding out what to build, and that part does not need doing twice.

Throwaway Scripts That Touch Real Data

A script that only reads an export is throwaway. A script that writes to the production database is not, however short and however soon you plan to delete it. A 30-line fix that sets a flag on bookings matching some condition runs once, but it runs once on the real thing, and a wrong condition in a line you did not read updates rows you did not mean to touch.

For a script like this, what it touches matters more than how long it lives. Read every line of anything that changes real data, run it first against a copy, and keep the output of that dry run. "Only run once" describes the script's lifetime. It says nothing about the size of the mistake it can make in that one run.

The habit that makes such scripts safe is cheap. Have the script print what it would change, the number of rows and a sample of them, before it changes anything, and run that version first. If the count says 3 when you expected 40,000, or 40,000 when you expected 3, you have learned something no amount of reading the code would have told you as quickly.