August 11, 2026
We got a project. The app works, the client is happy, the previous "team" shipped it in record time. Then you open the repository and realize that nobody — not the client, not the original author, and soon not you either — actually knows how this thing works. No tests. No architecture. The same logic copied into seven places because the model generated its own version every single time. That's not an application. That's a pile of prompts that happens to compile.
This isn't a hypothetical. This is work we do more and more often.
The term was coined in February 2025 by Andrej Karpathy, co-founder of OpenAI. He described it as an approach where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Prompt goes in, code comes out, you don't read it — you just test the result and ask for the next change. Collins English Dictionary named it Word of the Year for 2025. Y Combinator reported that 25% of startups in its Winter 2025 batch had codebases that were 95% AI-generated.
And let's be clear: we have nothing against AI in development. We use it every day. The point isn't the tool — the point is where you let it run.
It has a perfect place, and that place is genuinely useful:
Karpathy himself envisioned it for "throwaway weekend projects." Key word: throwaway. Simon Willison, one of the most level-headed voices in this whole story, framed the line perfectly: if an LLM wrote every line of your code, but you've reviewed, tested, and understood it all — that's not vibe coding. That's using an LLM as a typing assistant. The distinction isn't semantic. The distinction is everything.
The problem starts the moment nobody throws away the "throwaway prototype" — instead it goes to production because "well, it works."
The numbers aren't our anecdote, they're research. GitClear analyzed 211 million lines of code changes between 2020 and 2024. Refactoring dropped from 25% of changed lines in 2021 to under 10% in 2024. Copy-pasted code roughly quadrupled and, for the first time in two decades, exceeded moved code. Translation: people generate more and more, and clean up less and less.
In December 2025 CodeRabbit analyzed 470 open-source pull requests and found that code co-authored with generative AI contained roughly 1.7 times more "major" issues than human-written code — more logic errors, 75% more misconfigurations, 2.74 times more security vulnerabilities.
And security? A Veracode study from October 2025 showed that over three years models improved dramatically at generating functional code, but the security of generated code generally did not improve. Larger models were no better than smaller ones. A real-world reminder: on the Lovable platform, 170 of 1,645 generated web applications had a flaw that let anyone access personal data.
And the most painful part — the productivity vibe coding promises. In July 2025 METR ran a randomized controlled trial with 16 experienced developers on mature repositories. They expected AI to speed them up by 24%. The result: they were 19% slower. On someone else's mature code — and production is always someone else's mature code — the help becomes a burden.
Fast Company called it by its real name: the "vibe coding hangover." And the hangover is always paid for by someone else.
The one who maintains it pays. When the database goes down at 11pm on a Tuesday — the now-legendary case where Replit's agent deleted a production database despite an explicit instruction to touch nothing — you don't debug a prompt, a human does. And if that human never understood the code, they debug nothing. They stare at something a machine generated, that shifts every time you run it, with no one left to explain it.
That's the essence of technical debt: it's not that the code is bad. The debt is that nobody knows why it works — so nobody knows why it stopped, either.
Vibe coding is a tool, not a strategy. Use it to get quickly to "is this even worth building." When the answer is yes — build it like it'll live for five years, because it will. That means architecture, tests, code review, and people who understand every critical path. Let AI sit at the keyboard all it wants. But the accountability stays with the engineer.
If you have an app that "somehow works" and nobody knows how — that's not a success waiting to scale. It's a bill waiting to arrive. Better to look at it before it does.
Related:
Inherited code nobody understands? Or building something meant to last longer than a weekend? Get in touch — from prototype to production that holds.
