What Vibe Coding Costs
The term arrived in 2025 and now covers three different things, which is most of why arguments about it go nowhere.
Sense one: describing what you want in plain language and letting a model write the code, reviewing it afterwards. For teams translating this assistant-related trade-off into day-to-day controls, cognitive offloading provides a practical reference.
Sense two: the same, without reviewing it — accepting output on the basis that it appears to work.
Sense three: a general term of abuse for any AI-assisted development, used by people who dislike the practice.
Sense one is ordinary assisted development with a fashionable label. Sense two is a distinct practice with a specific failure mode, and it is the only one worth discussing seriously. This page is about sense two.
What it is genuinely good for
Not nothing, and dismissing it entirely is as unhelpful as the hype. Cursor is one of the better-known AI-first coding environments See Cursor.
Prototypes you will throw away. The point is to find out whether an idea works. Correctness beyond "does it demonstrate the thing" is wasted effort.
Personal tools. Something you use, that fails visibly, where you are the only person affected.
Exploring an unfamiliar space. Building something rough to understand a domain, then discarding it.
One-off scripts. Verification is proportional to consequence, and there is none.
The common factor is that nobody else bears the cost of it being wrong. That is the whole boundary condition.
Where it fails, with evidence
Once the output reaches other people, the failure mode is not that the code is bad. It is that the code works, looks finished, and contains things no one examined.
The security data is substantial and it comes overwhelmingly from firms selling security tooling, which is stated where relevant. The more independent signal is academic.
Georgia Tech's Systems Software and Security Lab runs a tracker of CVEs attributable to AI-generated code, built by scanning tens of thousands of security advisories. The count climbed from single digits in early tracking to dozens per month across 2026. Figures quoted in secondary coverage differ by period and definition, so treat the trajectory as the finding rather than any specific total.
Veracode — which sells application security testing — reports that across more than 100 models and 80 tasks, 45% of generated samples introduced an OWASP Top 10 vulnerability, with Java worst at over 70%, and that the rate did not improve across testing cycles from 2025 into early 2026.
Cloud Security Alliance research reports that across 2.23 million generated samples from 16 models, 19.7% contained at least one package name that does not exist — a dependency an attacker can register.
GitGuardian — which sells secrets detection — reports AI-assisted commits leaking credentials at roughly double the baseline rate for public commits.
None of this says generated code is bad. It says unreviewed generated code ships problems at a rate that unreviewed human code did not, because a human writing slowly encounters more of the edge cases on the way.
The cost that arrives later
The security findings are the visible half. The other half is quieter.
Code nobody understands. It works until it needs changing, and then the cost arrives with interest. One industry framing calls this trust debt — code that functions and is not understood.
Architecture by accumulation. Each generated piece is locally reasonable. Together they are three ways of doing the same thing, because nothing had a view of the whole.
No one to ask. The person who "wrote" it cannot explain the decisions, because there were none — which is exactly what makes later review expensive.
Where the line actually is
Not a category of tool, and not a level of skill. One question:
Will anyone other than you bear the cost if this is wrong?
No: vibe away. Genuinely, and the productivity is real.
Yes: it is not vibe coding any more, it is development, and it needs the verification that development has always needed.
The transition is easy to miss because it happens without any change in how the work feels. A prototype becomes the product because it works and there is no time to rebuild it — and prototypes cross into production more often than anyone plans.
For studios, the commercial version
Do not quote a build from prototype velocity. The prototype was sense two. The build is not. They are different activities that produced similar-looking artefacts.
Be explicit with clients about which you are selling. At this price you get something that demonstrates the idea; at that price you get something that keeps working. Making "done" explicit is the useful conversation, and it is more honest than competing on a number.
And if you inherit a vibe-coded system, price the archaeology. Understanding code nobody understands is verification-heavy work in its purest form, and it is routinely underquoted because the codebase looks small and tidy.
The short version
- The term covers three things; only "generating without reviewing" is worth discussing as a distinct practice
- It is genuinely right for throwaway prototypes, personal tools, exploration and one-off scripts
- The boundary is whether anyone other than you bears the cost of it being wrong
- Security evidence is substantial and mostly vendor-produced; the university tracker's trajectory is the more independent signal
- The quieter cost is code nobody understands and architecture by accumulation
- Never quote a build from prototype velocity — they are different activities with similar-looking output