18

Beyond Vibe Coding

What responsible practice looks like once you've accepted AI-assisted coding is real

A word got stretched too far

Module 01 covered the basic split: vibe coding versus agentic coding. This module goes one level deeper — not "did a human look at the output," but what disciplined, production-grade practice looks like once you've moved past that first question.

Where this comes from

Simon Willison flagged that writers kept using "vibe coding" as a stand-in for all AI-assisted programming. That erases a real distinction: code nobody reviewed versus code that was AI-assisted but still went through normal engineering rigor. He pointed to Addy Osmani's book being retitled from "Vibe Coding" to "Beyond Vibe Coding" as a sign the field is catching up to that distinction.

Vibe coding isn't wrong — it's scope-dependent

The original definition describes a real, useful mode. The mistake is applying it everywhere regardless of what's at stake.

1
Prototype, thrown away tomorrow

Low stakes, nobody else depends on it. Accepting output without reading every line is a reasonable trade for speed.

2
Personal script, one-off task

Same trade applies — if it's wrong, you notice and rerun it. The blast radius is you.

3
Shared codebase, production system

The blast radius is now teammates, users, or customers. Unreviewed AI output here isn't efficiency — it's negligence wearing efficiency's clothes.

The discipline that doesn't show up in a demo

"AI-assisted engineering," as Osmani frames it, combines the creative speed of vibe coding with the rigor of traditional engineering. In practice, that rigor is a short list of habits:

Spec first

Write down what "done" means before generating code, so there's something to check the output against.

Read every diff

Every line, before it merges — the one non-negotiable that separates this from vibe coding.

Test before trust

"It ran once and looked right" is not verification. Reproduce the behavior with a test.

Security pass

AI-generated code fails in the same categories human code fails in — injection, auth gaps, secrets in plaintext. Check for them.

Maintainability

Someone (maybe future-you) has to read and change this later. Optimize for that person, not just for shipping today.

Human accountability

Whoever merges it owns it. "The AI wrote it" is never the answer to "why is this broken."

A spec is the difference-maker

Vibe coding has no spec — you just look at the result and decide if it "feels right." A written spec, even a short one, gives you something concrete to check the AI's output against.

Feature: CSV export
- Export visible table rows only (not full dataset)
- Columns in the order shown on screen
- Dates in ISO 8601, not locale-formatted
- Empty result set still produces a valid header row
Scopes the feature — stops the AI from quietly exporting everything.
Locks the column order — stops silent reordering from breaking a downstream import.
Removes ambiguity that "make it work" would leave to guesswork.
Names an edge case up front, instead of discovering it in production.

Right and constructive are different things

Willison's earlier post calling out this exact confusion was, by his own admission, sharper in tone than it needed to be — even though he still stood by the substance. Being correct doesn't excuse being needlessly harsh, and the same point usually lands better delivered calmly.

"Just ship it, the AI wrote it and it ran fine on my machine."
Ran once isn't tested. Did you read the diff, or just the output?
Fair. I skimmed it. Didn't check the error handling path.
That's the whole difference between vibe coding and engineering — not the tool, the review.

Check your understanding

Source note

Based on a short commentary post by Simon Willison reacting to Addy Osmani's book retitling. The vibe-coding-vs-engineering distinction is the durable idea; the book title and release date are just where the quote came from.

You ask Claude Code to write a script, it runs and produces the right-looking output, and you never open the diff to check how it did it.

By the original (Karpathy) definition, is this vibe coding?

Yes — accepting output without reading it is the definition
No — any use of an AI coding tool counts as vibe coding
No — vibe coding only applies to prototypes, never to scripts
A team writes a short spec, has Claude Code draft the implementation, reads every line of the diff, and runs a security checklist before merging.

Is this "vibe coding"?

Yes — AI wrote most of the code, so it's vibe coding by definition
No — the spec, review, and security pass are the added rigor that makes it AI-assisted engineering
Yes — anything shipped fast with AI help counts as vibe coding
Someone asks what single habit most separates responsible AI-assisted engineering from vibe coding.

Which is it?

Using a more capable model
Reading and understanding every line before it ships
Writing longer, more detailed prompts