"Vibe coding" has quietly become a synonym for "built with AI." That drift is worth resisting, because the original term named something specific, and the thing it named is not a development methodology. It is the absence of one.
What the Term Actually Meant
Andrej Karpathy coined it in early 2025, and he was precise: give in to the vibes and forget that the code even exists. Accept the diff without reading it. Paste the error back without understanding it. Ship when the tool stops complaining.
That is the definition. Not "using AI." Not "generating code." Not "prompting instead of typing." The defining characteristic is that nobody reads the output.
Between the coinage and now, the phrase broadened until it covered any workflow involving a model — which is how agencies ended up listing it on capability pages. It is not a capability. It is a description of what happens when review is skipped.
The Distinction
Who reads the output. Vibe coding: nobody. AI-assisted: someone who can evaluate it.
What happens to errors. Vibe coding: pasted back until they stop appearing. AI-assisted: understood, then fixed.
What the tests are worth. Vibe coding: whatever was generated alongside the code. AI-assisted: verified against real behaviour.
Where the architecture comes from. Vibe coding: it emerges by accident. AI-assisted: a person decided it.
What happens when it breaks. Vibe coding: nobody knows why. AI-assisted: someone knows where to look.
The same tools sit on both sides of that table. Same models, same editors, same prompts, often the same developer on different days. Which column a project lands in is determined entirely by what happens after the code appears on screen.
Why the Difference Is Commercial, Not Philosophical
Nobody buys keystrokes. They buy a system somebody understands well enough to change safely in eighteen months.
Code that nobody read has no owner. When a subtle permission bug surfaces in production, "the AI wrote it" is neither a diagnosis nor a fix. Someone has to open the file and say: this is what it does, this is why it is wrong, this is the change. That capability is the deliverable. The typing never was.
It is also why velocity claims around vibe coding usually measure the wrong quantity. First-draft speed is the cheapest part of building software. Review, integration, and the cost of being wrong later are where budgets actually go.
What Review Looks Like in Practice
Guardrails are easy to list and easy to skip under deadline. These are the ones worth keeping.
Read the diff before accepting it. Not skim — read. Code that cannot be explained is not ready to ship, regardless of who or what produced it.
Own the architecture. Models are good at producing code that works and indifferent to whether it belongs. Where a responsibility lives, what owns an invariant, which layer enforces a rule — those are decisions, and decisions stay with people.
Slow down at security and data boundaries. Authorization, tenancy isolation, input handling, anything touching money or personal data: read line by line. A generated policy that looks correct and permits one case too many is the most expensive class of bug there is.
Verify against the running system, not the build. This is the guardrail most often skipped, and the one that produces the worst surprises.
A Compile Is Not a Verification
The last point deserves its own section, because it fails in a way that feels like success.
Consider a common shape: a data file feeds a component, and the component indexes into an array at a fixed position. A change shortens that array.
TypeScript passes. The production build passes. Static pages generate cleanly. Every signal says green.
The page then returns a 500 in production, because that route was server-rendered on demand and nothing in the verification had ever executed it. Three lines of undefined index, and both checks were structurally incapable of catching it.
This is not an AI problem — a developer typing by hand writes exactly the same bug. It is a proof problem. A passing type check proves the code is internally consistent. A passing build proves it compiles and that prerendered routes render. Neither proves that a dynamic route returns 200 to a real request.
The remedy is unglamorous: start the production server and request the routes that matter.
npm run build
npx next start -p 3000 &
for path in / /work /blog; do
printf '%-24s %s\n' "$path" \
"$(curl -s -o /dev/null -w '%{http_code}' "http://127.0.0.1:3000$path")"
done
Two minutes. It catches an entire category of failure that no amount of static analysis will.
The general principle: proof has to match the failure mode being guarded against. "It compiled" is evidence for a much narrower claim than it feels like, and the gap between the claim and the feeling is where outages live.
The Honest Version of the Productivity Question
The question everyone asks is how much faster this makes things, and the honest answer is that most published numbers are marketing.
What can be said without inventing a figure: AI moves the bottleneck. Less time goes into producing a first draft, and correspondingly more into review, integration and judgment. Whether that nets out faster depends almost entirely on how disciplined the review is. Teams that skip it look fast for roughly a quarter, and then spend the next one paying for it.
An unmeasured percentage on an agency website is a claim nobody can check. A description of the actual workflow is something a client can evaluate.
Best Practices
- Read every diff before accepting it; unexplainable code does not ship
- Keep architectural decisions with people, not models
- Review authorization, tenancy and data handling line by line
- Write or verify tests against real behaviour rather than trusting generated ones
- Verify dynamic routes against a running server, not just a green build
- Treat generated code as a draft from a fast colleague, not as output from an oracle
Conclusion
"Vibe coding" is a useful term with a legitimate home: throwaway prototypes, personal scripts, exploring an unfamiliar API — anywhere being wrong costs nothing.
It has no place in software somebody is paying to depend on. So when it appears on a capability page, the question worth asking is what is actually meant by it. If the answer is "we use AI well," the word is wrong. If the answer is what Karpathy meant, it is not something to advertise.
The tools are not the dividing line. Using a model to draft a migration is not vibe coding. Shipping that migration without reading it is — and no client can tell the two apart from the outside, which is exactly why the distinction is worth stating plainly.