The Vibes Are Off
When AI-generated code hits real-world complexity, the cracks show.
Eighteen months ago, the internet decided that software engineering was over. Not obsolete - just unnecessary. Why bother learning syntax when you could simply tell an LLM, “make me a finance app with a login screen and a database” and out pops code? Voilà. Startup in a weekend. Launch on Monday. Series A by Thursday.
Thus was born vibe coding - the art of building software by manifesting it. Mix one part natural language, one part vague ambition, and one part blind confidence as you paste mystery code into production.
For a brief, shimmering moment, it almost felt like the future. Until it didn’t.
AI code assistants unlocked a wave of creative energy. Non-technical founders could spin up MVPs. Engineers could eliminate boilerplate. Students built entire apps in a weekend.
But here’s the problem: prototype-grade code is not production-grade code.
Many teams that started with LLM-assisted scaffolds are now spending weeks rewriting or refactoring. I’ve heard of entire codebases being scrapped - declaring what one founder called “code bankruptcy.”
It turns out there’s a difference between writing code and writing software.
The former is syntax. The latter is systems thinking.
At some point, every serious technical team has the same moment of reckoning: you don’t just need code, you need engineering. Not just output, but architecture. Not just velocity, but durability.
A Mismatch of Tool and Context
Vibe coding isn’t a technological failure, it’s a categorical error. It assumes that the problem in software development is code generation speed. But for most companies past the napkin stage, that’s not the bottleneck. The bottleneck is:
Understanding and reflecting business logic
Architecting clean, extensible systems
Managing side effects, state, latency, auth, concurrency, observability
Reasoning through edge cases and failure modes
LLMs don’t hold context beyond a few thousand tokens or infer trade-offs yet. They don’t ask: “Why does this route even exist?”
So when teams use LLMs to generate full features - or worse, entire codebases -they end up with systems that appear functional but are structurally unsound. Like a house with beautiful wallpaper but no load-bearing walls. There’s a market for vibe-coding. It’s just not software.
A Tool, Misapplied
To be fair, vibe coding is very useful. It’s just often used in the wrong context.
And this is where the real distinction lives: vibe coding and AI in software development are not the same thing.
Vibe coding tries to replace engineering. It hands the keys to the model and hopes for the best.
AI in software development is about amplifying engineering - using AI to accelerate the rote parts while humans still own the architecture, logic, and trade-offs.
The first treats AI as a substitute; the second treats it as a lever.
Used the right way, AI saves time, reduces boilerplate, and expands what small teams can ship. Used the wrong way, it produces elegant prototypes that can’t survive contact with reality.
Vibe coding is fantastic 0 → 1. It’s a liability 1 → 100.
It’s like bringing a balloon animal to a knife fight. Wonderful at a birthday party. Less helpful in real combat.
There’s a real market for fast, disposable, front-of-the-house code. But most tech companies are in the business of building the kitchen, not just plating food.
We Are Not Yet in the “AI Builds AI” Era
You might reasonably say, “But the models are getting better!” And they are - they autocomplete better, hallucinate less, scaffold boilerplate, and even write tests. But they still don’t hold a mental model of your system. Which means they’re still bad at system design.
AI is a remarkable accelerant for the right kinds of tasks: scaffolding, linting, test writing, doc generation. It compresses iteration cycles and raises the productivity ceiling. But used as a replacement for human reasoning, it amplifies chaos.
As Andrej Karpathy pointed out after trying to use LLMs for his nanoChat project, it felt like arguing with an overconfident intern - helpful for grunt work, useless for design.
These models do not reason. They autocomplete. They predict the next likely token based on training data. Which works if your problem looks like something that’s been done before. But the moment your software needs to be original - or integrated across multiple subsystems - prediction becomes pathology.
The Future of Engineering Still Looks Like Engineering
There are two different conversations happening:
Vibe coding - AI as replacement. Fast, fun, fragile.
AI-assisted development - AI as accelerant. Practical, powerful, already useful today.
Vibe coding builds facades. AI-assisted engineering builds foundations.
The current panic about engineering being dead is mostly coming from people who didn’t understand engineering in the first place.
Engineering isn’t syntax. It’s constraint management. It’s abstraction design. It’s knowing when to optimize and when to punt.
The irony is: as AI makes building easier, the value of engineering judgment goes up. Because now, anyone can build a thing. But only a few can build the right thing, the right way, that scales. The faster you can go, the more you need someone to steer. So no, engineering is not dead. It’s just wearing a new exosuit.
Great article, loved reading it.
I am a PM, and use AI prototyping tools like Lovable, Cursor to build the first MVP of a feature/module I want to present, only for brainstorming purposes. It has definitely improved ideation to finalization speed.
Later, when the brainstorming is complete, business use cases have been concretely defined, i move to the designer for sample screens, that match the design language of existing platform, and functional aspects of my prototype.
Design creation timeline went from 1-2 weeks to well within 3-4 days, for standalone, e2e features. only because, i have covered all the scenarios in the MVP AI vibe coded prototype.
Great write up, as usual. Thank you!