Skip to main content

Inteltech

Vibe Coding Is for Throwaway Code, Not Delivery

The practice means not reading what the model writes. Fine for a weekend project, disqualifying for anything someone else has to maintain.

By Amyn PorbanderwalaApril 4, 20254 min read

Contents
  1. Two practices behind one word
  2. Where the fast mode is fine
  3. What delivery requires
  4. The honest version of the pitch

Andrej Karpathy coined the term in February 2025, and the line that matters is buried in the middle of his post: "I don't read the diffs anymore." (opens in a new tab)

That is the whole practice. You prompt, you run it, you accept what comes back. He was explicit that it works for throwaway projects and that the code grows past his comprehension.

The term then escaped and attached itself to something else, which is people using AI to write code they do read, test and own. That is a different job with a different discipline, and confusing the two is how teams end up shipping code nobody understands.

Two practices behind one word

One practice is exploration. You have an idea, you want to see it run, and the fastest path is to describe it and accept the output. Reading the code would slow you down and add nothing, because the artifact is disposable. A script that parses a CSV once does not need an architecture.

The other practice is engineering with a faster keyboard. The model drafts, you read the diff, you reject most of it, you keep the part that is right, and you own the result. The output is not disposable, so the review is not optional.

Both are legitimate. They have different rules, different failure costs and different staffing. The problem is that the same word now covers both, so a policy written about one gets applied to the other.

If nobody read the diff, nobody reviewed the change. That is the control, and no amount of test coverage replaces it.

Tests are necessary and they are not a review. A test tells you the behavior you thought to check still holds. A reviewer tells you the code does something you did not think to check. Generated code fails at exactly the boundary you did not imagine, which is the boundary no generated test covers.

Where the fast mode is fine

Being precise about the safe case makes the rest of the argument credible.

  • Throwaway analysis. A one-off script to answer a question this week. If it breaks, you rerun it.
  • Prototypes. A working mock to settle a design argument. Nobody ships the mock.
  • Personal tools. Something only you run, on data only you own, with no credential that reaches anything else.
  • Test scaffolding. Fixtures, generators and harnesses, as long as a human checks what they assert.

The common property is blast radius. If the worst outcome is that you spend an afternoon, the fast mode is rational. If the worst outcome is a wrong number in a report, a credential in a log, or a database that no longer has the rows it had yesterday, the calculus changes completely.

Two failures show up repeatedly in generated code and both are hard to see in a demo. The first is a plausible implementation of a boundary condition that the model guessed at, which passes the happy path and misbehaves on the edge. The second is a dependency or credential assumption that quietly widens the attack surface. Neither is caught by "it runs."

What delivery requires

If the code is going to be maintained, four things are not negotiable.

  1. Read what you merge. Every line. If the diff is too large to read, it is too large to merge. That is a size limit, not a discipline problem.
  2. Keep changes small enough to review. Generated code arrives in large batches by default. Break it up. A 600-line diff from a model is a 600-line diff you will approve without reading.
  3. Make the tests the contract, then read them too. A test written by the same model that wrote the code agrees with the code, including when both are wrong.
  4. Write down why. A comment explaining why you rejected the model's approach is worth more than a comment explaining what the code does, because the next person will face the same suggestion.

There is a fifth rule for federal and regulated work. Nothing generated goes into a boundary you cannot test, and nothing generated touches production without the same change record as hand-written code. The tool that wrote the line is not a control, and "the model produced it" is not a review note.

The honest version of the pitch

AI assistance is real. It compresses the distance between an idea and a working thing, and for people who could not write software at all it is a genuine expansion of what they can do.

What it does not do is remove the obligation that comes with code other people depend on. Karpathy said the practice was fine for throwaway work. That was not a hedge. It was the operating instruction, and it is the part that got lost.

Use the fast mode to think. Use the slow mode to ship. The cost of confusing them is not a bad afternoon. It is a system that nobody on the team can safely change.