The Vibe Coding Hangover Is Real, But the Wrong People Are Getting Blamed
The “vibe coding is dead” posts have started showing up in my feed. Senior engineers writing eulogies for a thing that, if we are being honest, never actually existed. CodeRabbit put out numbers showing AI-coauthored PRs have 1.7x more major issues. METR ran a study where experienced devs were 19% slower with AI tools while being convinced they were 20% faster. Everyone is staring at these numbers and concluding AI coding was a lie.
That is the wrong conclusion. The lie was somewhere else.
Vibe Coding Was Never Real
Let us get this out of the way. The thing people called “vibe coding” — somebody with no idea what they are doing typing prompts into Cursor and shipping a production-ready app — was never a real thing. What those people were generating was VC-ready demos. A landing page. A dashboard with fake data. A flow that works if you click the buttons in the exact order the demo video shows. That is not software. That is a screenshot you can scroll.
The minute one of those “apps” had to handle a real user, a real edge case, a real database under load, the whole thing fell apart. It was always going to. The people making them did not know what they were building, the AI did not know what they wanted, and nobody in the loop had the judgment to catch the dozen places it was about to go wrong.
So when someone says “vibe coding is dead,” what they actually mean is “the demos stopped fooling people.” Fine. Good. But do not pretend something died that was alive in the first place.
The Coding Part Is Dying. Engineering Is Not.
Here is the part everyone keeps mixing up. AI is killing software engineering the same way digital cameras killed photography. Which is to say, it did not. It just changed who survived.
Photographers who actually understood light and composition and the craft kept working, and a lot of them got more productive because they were not waiting on a darkroom anymore. The people who got squeezed out were the ones whose entire skill was operating the equipment. That is what is happening right now. The mechanical part of writing code — typing the syntax, looking up the API, remembering whether it is map or forEach — that part is dying. The judgment part is more important than it has ever been.
AI is a tool. Like every tool, you have to know what you want from it and how to use it. Otherwise you break things. Or worse, you break things in ways you do not notice until production.
Seniors Are Not Slower. The Study Asked the Wrong Question.
For people who know where they are going, AI is an absurd accelerator. I am barely writing code by hand anymore. Most of my day is writing specs, sketching the shape of what I want, then reviewing and adjusting what comes back. I catch the bad patterns because I spent a decade writing the bad patterns by hand and watching them blow up.
The METR number — 19% slower while feeling 20% faster — is real, but it is measuring the wrong thing. If you hand a senior dev a tool and say “use this for everything,” of course they get slower on the tasks where the tool was the wrong choice. The skill is knowing when to reach for it. Some things I let the AI do entirely. Some things I do not even open the chat window for. That decision is the whole game now.
We have moved from rowing to steering. We still remember how to navigate. That is the part that matters.
The Real Damage Is to Juniors
This is the part I actually worry about.
I know in my bones that a 1500-line function is a recipe for bugs. I know that ten nested if-clauses are going to hide a bug that takes three days to find. I know this because I wrote those abominations by hand, fifteen years ago, and I had to debug them at 2 AM with no AI to ask. That pain is where taste comes from. You do not develop a sense for what good code looks like by reading clean code. You develop it by drowning in bad code and clawing your way out.
Juniors today do not get that experience. They look at a 1500-line function, paste it into Claude, ask “what does this do,” get a tidy summary, and move on. They never sit with it. They never reason about it line by line and feel the weight of it. The pain that builds taste never happens.
This is going to blow up the talent pool in about five years. We are going to have a generation of engineers who can ship things but cannot smell when something is wrong. They will not know why the code they accepted is bad until it takes down production, and even then they will ask the AI what happened instead of figuring it out themselves.
That is a real problem. That is the actual hangover.
So Who Is to Blame
Not the AI. AI did exactly what it was supposed to do — it gave you what you asked for, no more.
The blame is on the people who sold a tool that requires judgment to an audience that was promised it did not. The whole “anyone can build software now” pitch was always going to end with a pile of broken apps and a lot of confused founders wondering why their MVP falls over at a hundred concurrent users. Surprise.
If you are senior, AI is the best thing that has happened to your productivity in a decade. Use it. If you are junior, please, for your own career, write some bad code by hand sometimes. Sit in it. Suffer a little. That is where the engineer in you grows.
The coding is getting easier. The engineering is not.