Vibe coding: what it is, where it works, and where it costs you

The term arrived as a joke and stopped being one within about six months. Andrej Karpathy described a way of working where you "fully give in to the vibes" — prompt, run it, prompt again, and never really read what came back. It was self-deprecating. It also described what a lot of people had quietly started doing.

The interesting question is not whether vibe coding is good or bad. It is which category of work it belongs to, because the answer is unusually clear-cut.

What it actually is

Vibe coding is a review posture, not a tool. You are vibe coding when you accept generated code on the evidence of its behaviour rather than its content — it ran, the output looked right, ship it.

That is a real and legitimate mode. Every engineer has used a library without reading its source, and that is the same trade: trusting behaviour over inspection, because reading it is not worth the time.

The difference is that a library has been read by other people, has a maintainer, and has been battered by thousands of users. Freshly generated code has none of those. You are extending trust that nothing has earned.

Where it is straightforwardly right

For work with a short, known lifespan, reading every line is waste. Vibe coding is the correct engineering decision in all of these:

• Prototypes that answer a question. Does this interaction feel right? Is this API usable? Build it, look at it, delete it.
• Internal tools with one or two users. The migration script, the dashboard for the ops team, the thing that reconciles two spreadsheets once a quarter.
• Exploration. Trying four approaches quickly to find out which is worth doing properly.
• Learning a new library. Generating working examples is often faster than reading the documentation, particularly for badly documented libraries.
• Anything you would otherwise not build at all. A lot of vibe-coded software exists in the place where nothing previously existed, and it is a clear improvement on nothing.

Where the cost lands

The failure modes are specific and worth naming, because they do not announce themselves at the time.

Nobody can debug it. The most expensive one. Production breaks, and the person on call is reading code for the first time under pressure, with no mental model of why it was built that way.

Security flaws that look like ordinary code. Missing authorisation checks, injection-prone string building, secrets in the wrong place, overly permissive defaults. These are not exotic — they are the OWASP list — and they are invisible if nobody reads the diff.

Unvetted dependencies, and a measured attack surface. This is the failure mode with the hardest numbers attached, so it is worth being precise.

A USENIX Security '25 study generated 2.23 million code samples across sixteen code-generating models in Python and JavaScript and measured how often the models imported packages that do not exist on PyPI or npm. Hallucination rates ran from 5.2% on commercial models to 21.7% on open-source models, and the invented names were not random: roughly 38% were conflations of two real packages, 13% typo-variants, and 51% outright fabrications (USENIX ↗).

That predictability is the problem. A name a model reliably invents can be registered by someone else — the attack now known as slopsquatting. The victim is not a developer who mistyped; it is a developer who never typed at all.

A 2026 replication on five frontier models released between October 2025 and March 2026 found overall rates between 4.62% and 6.10% (arXiv:2605.17062 ↗). The range narrowed. It did not close, and at the volume of code now being generated a 5% rate is a large absolute number of opportunities.

Silent error handling. Generated code loves a catch that logs and continues. Failures stop failing loudly, which means you find out about them from customers.

Architecture by accumulation. Each prompt produces a locally reasonable change. Fifty prompts later the system has no coherent shape, because no one was holding one.

How to tell whether your team is vibe coding without having decided to

Almost nobody sets out to vibe code production software. It arrives by drift, and the drift is detectable if you look for it.

The honest test is not "do we use AI" — everyone does. It is whether anyone read the diff with enough attention to disagree with it. A few probes that surface the answer:

• Pick a merged pull request from last week at random. Ask the approver to explain what it changed and why. Not as a gotcha — as a measurement.
• Ask how many dependencies were added in the last month and who evaluated them.
• Look at whether review comments are still being left. A team whose comment rate has fallen while merge volume has risen has stopped reviewing and started approving.
• Ask what proportion of changes come with a test that would have failed before them.

None of these require you to read code. All of them distinguish a team using AI deliberately from one that has quietly stopped checking.

Guardrails that keep it useful

If you want the speed without the accumulation — and you should, because the speed is real — a small number of controls do most of the work. In rough order of return on effort:

Verify dependencies mechanically. Lockfiles committed. A registry allowlist or proxy. A CI check that fails the build if a package did not exist before your build ran. Given hallucination rates around one import in twenty, this is the highest-value control on the list and it takes an afternoon.

Require a human-authored failing test. For anything that will outlive the week. It closes the loop where generated code is validated by generated tests, and it forces the requirement to be pinned down before implementation.

Cap diff size. The pressure will be to raise the cap because generation is cheap. Review is not, and review is now your constraint.

Read the security-adjacent parts line by line. Authentication, authorisation, anything handling user input, anything touching money or personal data. Fluent, well-formatted code attracts less scrutiny than messy code doing the same wrong thing, which is precisely the problem.

Put an expiry on throwaway work. A comment at the top of the file, a ticket, a calendar reminder — anything that makes promotion to production a decision somebody takes rather than something that happens.

What it means for the people doing it

There is a second-order effect worth naming, because it does not show up in any codebase metric.

Reading and debugging unfamiliar code is a skill, and it atrophies without practice. It is also precisely the skill that agentic workflows demand more of — the job shifts from producing code to verifying it, and verification is exactly the muscle that vibe coding lets you stop using.

Teams that use AI heavily and stay strong tend to keep some deliberate practice in the loop: reading diffs properly rather than skimming, occasionally debugging without assistance, reviewing each other's work with real attention. Not out of nostalgia — because the capability is load-bearing, and by the time you notice it has gone, you need it.

A usable rule

Before you start, answer one question: how long does this code need to live, and who changes it next?

Note what is not on that axis: how complicated the code is, how good the model is, or how confident you feel. Those are the variables people actually use, and they are the wrong ones.

Promoting a prototype properly

If a vibe-coded thing turns out to matter, the move is not to gradually clean it up in place. It is to treat it as a working specification.

1. Write down what it does, from observed behaviour. You are producing the specification you skipped — see how to scope a software project for the format we use. You now have a requirements document you did not have to guess at — this is the genuine value the prototype created.
2. Decide what actually needs to be kept. Prototypes accumulate features nobody uses.
3. Rebuild the parts that carry risk with review and tests: auth, data handling, money, anything user-facing that fails visibly.
4. Keep what survives inspection. Plenty of generated code is fine. The point is that somebody has now read it and is accountable for it.
5. Delete the prototype. Two versions of the same thing is worse than either.

Where vibe coding sits against the other shifts

It is easy to read this as a standalone phenomenon. It is better understood as one end of a spectrum that also contains the more disciplined practices, and the useful question is which end a given piece of work belongs at.

All three use the same tools. What separates them is how much verification you attach, and the mistake is not picking the wrong one — it is picking without noticing you are picking.

The term will probably not survive

A prediction, offered with appropriate uncertainty: "vibe coding" is likely to stop being a useful label within a year or two.

Terms like this describe a transition rather than a stable state. They name the moment when a practice is novel enough to need a word and contested enough to argue about. Once the underlying capability becomes ordinary, the label dissolves into the general vocabulary — nobody says "using a compiler" as though it described a philosophy.

What will outlast the term is the underlying decision, which is not really about AI at all: how much verification does this code warrant, given how long it has to live and who has to change it next. That question predates language models by decades and will still be the right question long after this particular phrase stops being funny.

What this trend is really telling us

Vibe coding is a symptom of something structural: the cost of producing code fell dramatically and the cost of understanding it did not move at all. So the rational response is to produce more code and understand less of it — right up until the moment understanding is what you need.

The teams handling this sensibly have stopped treating "should we use AI" as the question. They have made lifespan an explicit, up-front decision, and they attach a review standard to it. Throwaway work gets thrown away. Permanent work gets read by a person.

That is a boring conclusion, and it is holding up better than the arguments on either side of it.