My Trip to Vibe Coding Hell
Let me start by saying that I use AI to generate a ton of code. After 10 years of writing code for monies, I have a pretty decent idea of what will and won’t work and opinions on how to construct and deploy web apps.
Recently, I joined a new team and we are creating a prototype for a new product. We’re attempting to do this with pure Vibe Coding.
Vibe Coding is essentially using AI to craft nearly ALL your code. This means that an engineer who might not know JavaScript or TypeScript can build an app via prompts.
What could go wrong?
It started like this: a product manager showed the (non technical) exec team how use Vercel’s v0 to prompt their way to a beautiful application.
They built a prototype in a weekend.
It looked incredible.
It did nothing.
- 1000 line-long files — who cares?
- Optional types everywhere — what could go wrong?
- Massive amounts of videos and large, unoptimized images but hey, it works on my machine!
- Fake data but don’t worry, we’ll figure that out… later
None of that mattered. Because it felt like magic.
So began our descent into what I now call: Vibe Coding Hell.
When “Working Software” is a Shack With a Nice Paint Job
The prototype wowed the execs. They were giddy.
“If we can build this in a weekend, imagine what we can build in a month!”
So we kept building. We wanted this to work.
Cursor-assisted feature after feature.
It looked real. It felt real.
But underneath? It was a house of cards glued together with fake data and half-baked TypeScript.
Every new line of code made it worse.
Deploying became a nightmare. All those massive video files couldn’t fit in GitHub. They needed to be hosted somewhere.
A resource intensive component looked great in v0 but brought our laptops to a crawl because
The build failed because of wrong types and slight differences between versions of NextJS.
The more code we added, the more unstable the app became. One moment, we were demo-ready. The next, we were breaking everything because Cursor agents went HAM and broke something that had just been working.
Yes, we had robust cursor rules.
Yes, the team is all senior developers.
Yes, we made it clear to the leadership team that this could NEVER, EVER work in real life.
At least not yet.
CEOs Want to Believe the Myth
And I get it.
AI makes them feel like they’ve cracked the code. Like they don’t need a team of 20 engineers anymore — just some prompts and a dream.
We gave them a toy they could run locally. They thought this was the same as deploying. They thought they understood development. They started questioning what their actual devs were doing all day.
I suspect this is what many early career developers believe as well.
You start to wonder if you have any value.
If this can do my job, faster — then what the hell will I be doing?
Vibe coding can get you to the first 80% of a feature if you’re incredibly lucky and/or your app is simple.
The final 20%? That’s where the real engineering happens.
That’s where tests live. And edge cases. And actual performance. And that’s ONLY on the front end.
What about your database schema?
Your data pipelines?
Security?
We’ve only scratched the surface.
That’s where you stop building demos and start building software.
If you’re a career changer who wants to become an actual software engineer who can think through difficult problems, join me at Parsity.io
The Trap of Fast Prototypes and Slow Deaths
Every startup caught in this vibe coding trap will end up in the same place:
- Fragile code that can’t scale.
- Teams that can’t debug what the AI wrote.
- Founders who thought they were building a Ferrari but got a cardboard cutout instead.
Eventually, someone will suggest rewriting it “the right way.”
Guess what? That takes real time.
And that’s when reality hits: AI didn’t replace the need for engineers. It just made it easier to lie to ourselves and produce trash at scale.
Vibe Coding Isn’t the Future. Engineering Still Is.
I was a believer.
I wanted it to work.
I thought, maybe I’m just old. Maybe this IS the future.
I want to slap myself.
The best engineers in the coming years won’t be the ones who prompt the fastest.
They’ll be the ones who know when to say no, who understand systems, refactor and test and debug.
Vibe coding makes great presentation decks.
It doesn’t make great products.
If you’re leading a team — or building your own thing — don’t fall for the magic show.
Fast isn’t free.
And real software still requires real work.
If you’re a career changer who wants to become an actual software engineer who can think through difficult problems, join me at Parsity.io
