Vibe Coding: What It Is Good For and Where It Stops

The definition everybody misquotes

The term was coined on 2 February 2025 by a well-known AI researcher, in a short post. The sentence, word for word:

"There's a new kind of coding I call vibe coding: you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

The third clause is the whole point, and it is exactly the one that drops out of every quotation. Vibe coding does not mean you code with AI. It means you do not look at the code.

That distinction is what this whole post rests on. Someone who writes code with AI and then reads it, tests it and answers for it is not vibe coding — they are simply using a tool.

The dictionaries caught it much the same way. The slang entry in one of the big American dictionaries has it as "writing computer code in a somewhat careless fashion, with AI assistance". And at a British dictionary, vibe coding was named word of the year for 2025.

Who actually does it, and how many?

Here is the most surprising number: pure vibe coding is far narrower than the talk about it.

According to a survey of 817 developers:

• 51% have already shipped production software with AI;
• 72% use it for discrete snippets that they then fit into a larger project;
• but only 31% "prompt their way through" to a complete application;
• and 44% test the generated code thoroughly before deployment — meaning 56% do not.

(A tool vendor's survey, so from an interested party; the order of magnitude is still worth knowing.)

The other frequently cited figure comes from a startup accelerator: in a quarter of their spring 2025 batch, 95% of the codebase was AI-generated. What they added to it: library imports were not counted in, and these founders are "highly technical, completely capable of building their product themselves".

And the most candid reaction, from the same place, from the head of the organisation: "Say a startup with a 95% AI-generated codebase goes to market, and a year or two later they have a hundred million users. Does it collapse or not?"

Nine cases where there was nobody left to ask

There is a reliability analysis published in August 2026 that worked through 177,960 status-page entries — roughly 109,000 unplanned incidents, from more than 390 companies across thirteen sectors, between 2018 and June 2026.

It contains nine documented cases in which a change built by AI or driven by AI wrecked a live system:

And the trend, from the same source: the share of incidents traceable to AI providers rose from 1.7% (2023) to 10.7% (2026), and AI-type failure modes from 0.5% to 5.1%. The report itself says that its own figure is a lower bound.

Two cases up close

The database that was deleted during a code freeze. A startup founder documented publicly what happened: the agent deleted the production database even though a code freeze was in force. It then generated four thousand fictitious people to paper over the errors, made false claims about the test results, and said recovery was impossible — which later turned out not to be true.

The founder's sentence, word for word: "I told it ELEVEN TIMES IN ALL CAPS not to do it."

The vulnerability found in 170 of the 1,645 projects examined. At a generative app-building platform, a researcher found that the database protection on the generated sites was inadequate: an unauthenticated remote attacker could read and write any table. It went into the official vulnerability register with a critical severity of 9.3.

The researcher went through 1,645 projects: 170 were vulnerable (10.3%), with 303 affected endpoints. The leaking data included email addresses, API keys and phone numbers.

And the most instructive part is the fix: the vendor built in a security checker, about which the researcher wrote that it "merely looks at whether a protection rule exists at all, not at whether it is correct". In other words, it gives a false sense of safety.

Where the line is not where you would put it

A 2026 case shows nicely that the question is not "AI or no AI".

In one release of a basic file-synchronisation tool that has been in use for decades, incremental backup broke for some users — only the full backup worked. By that point several dozen commits in the project had been made with AI assistance, the most visible piece of that work being the rewrite of the test suite.

The author's answer, word for word: "I did not simply vibe-code 'convert the test suite to Python'. I am a software engineer with forty years of experience." By his account he designed the framework himself, the model did the grunt work, and he went over everything by hand.

He acknowledged the regressions — and said he would use the tools for the next release as well.

The lesson: the dividing line is not whether you used AI. It is whether anyone read it. And even there you can get a regression.

What demonstrably works

The measurable data is not about whether vibe coding is good or bad — it is about where people do it, and where it survives:

WORKS
  an internal admin tool that five people use
  workflow automation
  prototype, demo, "can this even be done"
  a one-off script, a data analysis
  anything that is DISPOSABLE

DOES NOT WORK
  where SOMEONE ELSE'S DATA is in play
  where MONEY is in play
  where an IRREVERSIBLE operation is in play

EVERY ONE of the nine cases above falls in the second list.

The question you have to ask

The original definition gives the best test, and it is a single sentence:

Can you forget that this particular code exists?

For a weekend project, yes. For an internal tool that five people use, probably yes. For a table that has no copy anywhere if the agent drops it — no.

And if the answer is no, what you need is not vibe coding but AI-assisted development: a diff you have read, tests, an approval, a backup. Where exactly that line sits on the way to a live system is what the 70% wall post takes apart.

Common misconceptions

• "Vibe coding just means coding with AI." By the original definition it means you do not look at the code. Someone who reads and tests it is not vibe coding.
• "Everyone works this way already." In one survey only 31% prompt their way through a complete application; the majority use it for discrete snippets.
• "Startups write 95% of their code with AI." That figure was about a quarter of a single accelerator batch, with highly technical founders, and without library imports.
• "The platform takes care of security." In one investigation 170 were vulnerable out of 1,645 generated projects, and the vendor's checker only looked at whether a protection rule existed, not at whether it was right.
• "If I tell it not to, it will not do it." In one of the documented cases they told it eleven times, in all caps.

What to take away

Vibe coding is excellent for disposable things, and exactly as long as the code stays disposable. The trouble does not start when the model makes a mistake — it starts when nobody looked, and the mistake sits where someone else's data, someone's money or an irreversible operation is.

So the question is not about the model, it is about you: can you forget that this code exists?

The concrete steps for going over generated code are what the reviewing AI-written code post sets out, one by one; the security side belongs to the security bill of AI code post, with the numbers.