The Hangover of Vibe Coding
Fast to build. Faster to break.
In February 2025, Andrej Karpathy posted something that would define the year.
Karpathy co-founded OpenAI. He led AI at Tesla. When he talks, people listen.
He wrote: “There’s a new kind of coding I call ‘vibe coding,’ where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
Within weeks, everyone was doing it. Non-programmers building apps. CEOs writing code. Students shipping products.
By November, Collins Dictionary named “vibe coding” Word of the Year.
And by then, the hangover had already set in.
There’s a pattern in how new technologies get adopted.
First comes the magic. Then comes the measurement. Then comes the mess.
The magic was real. People who had never written a line of code were suddenly building functional apps. Prototypes that used to take weeks appeared in hours. The barrier between having an idea and shipping a product seemed to vanish overnight.
Here’s where it gets weird.
In July 2025, a nonprofit called METR ran one of the most rigorous studies on AI coding tools ever conducted. They recruited 16 experienced open-source developers—people who’d spent an average of 5 years on their repositories. Real developers working on real codebases, some with over a million lines of code.
The developers were randomly assigned tasks where they could either use AI tools (mainly Cursor with Claude) or work without them.
Before starting, the developers predicted AI would make them 24% faster. After finishing, they estimated they’d been 20% faster with AI.
The actual result? They were 19% slower.
Not 19% faster. 19% slower.
That’s almost a full workday lost per week. And the developers didn’t even notice. They felt faster while actually being slower.
The study found developers spent significant time cleaning up AI-generated code, dealing with suggestions that didn’t fit their codebase, and tracking down weird changes the AI made in unrelated parts of the code. One participant compared the AI to “a new contributor who doesn’t yet understand the codebase.”
James Gosling created Java. He’s been building software for decades. He watched the vibe coding trend unfold.
His assessment was blunt: “You get started on a vibe coding session, and it can actually be pretty cool. But as soon as your project gets even slightly complicated, they pretty much always blow their brains out.”
He added: “It’s not ready for the enterprise because in the enterprise, software has to work every fucking time.”
Every time.
Your bank has to work every time. Your medical records have to be accurate every time. Your flight control system cannot mostly work.
Vibe coding produces software that mostly works. That gap—between mostly and always—is where disasters hide.
The core problem is simple but easy to miss.
Simon Willison, a well-known programmer, drew a line: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book—that’s using an LLM as a typing assistant.”
The key word is understood.
Vibe coding means accepting code you haven’t examined. You’re not reviewing it. You’re not questioning it. You trust the vibes.
When you ask AI to “build a login system,” it doesn’t know your security requirements. It doesn’t know your scale. It doesn’t know your users. It guesses.
Sometimes the guesses are good. Sometimes they’re not. You can’t tell the difference because you never looked.
Here’s what worries me most.
We’re not just creating fragile code. We’re creating developers who can’t fix fragile code.
There’s a phrase going around: “the new tutorial hell.” The old version was watching tutorials without building anything. The new version is building things without understanding anything.
You encounter a problem. You throw it at AI. You get a solution. You ship it. You move on.
You never learn why it works. Which means you can’t debug it when it breaks. Which means you throw it at AI again. And the cycle continues.
Someone will eventually have to maintain these systems. They’ll look at commit histories that say “AI improvements” and “fixed with Claude.” No reasoning. No explanation. Just vibes, frozen in time.
There’s a lesson here that shows up in every technology cycle.
Tools amplify what you already have.
If you understand software architecture, AI makes you faster. If you understand security, AI handles the boring parts while you handle the thinking.
But if you don’t understand these things, AI helps you create bigger messes faster.
Karpathy knew this from the start. He said vibe coding was for “throwaway weekend projects.” He called it “not really coding.” He warned us.
But warnings never travel as fast as excitement.
The rise of vibe coding was about possibility. Anyone could build anything.
The hangover is about reality. Anyone could build anything badly.
The future is somewhere in the middle.
Understanding will never go out of style. Knowing why code works—not just that it works—will remain valuable. Maybe more valuable than ever, precisely because fewer people bother to learn.
The vibe was fun while it lasted.
Now comes the work.
Fantastic article. The main problem in my view is that in most companies bad practices like vibe coding are being forced on developers by clueless upper management. It has gotten to the point that it doesn't matter if you write good code or not, if you don't use AI you are a bad developer.
Fantastic read. The METR study finding (19% slower, not faster) is a killer datapoint that cuts through all the hype. I've been on code reviews where AI-generted chunks look fine at first glance but then u notice they're solving slightly wrong problem or using patterns that don't match the rest of the system. The 'new contributor who doesn't understand the codebase' analogy is perfect. What stuck with me most is the 'tutorial hell 2.0' framing becuz it captures exactly what happens when speed replaces understanding.