There's a moment every founder hits.
It's somewhere around user 47 to 53. The app that looked flawless in the demo starts doing something it was never supposed to do. A race condition nobody planned for. An auth flow that breaks under concurrent sessions. A database query that was fine with 10 rows and catastrophic with 10,000.
They go back to Bolt. Or Lovable. Or Cursor.
They ask the AI to fix it.
The AI generates a fix. The fix introduces two new bugs. They ask the AI to fix those. More code appears. The codebase is now a palimpsest of patches — each one locally optimal for the prompt that generated it, globally incoherent with everything around it.
At some point the founder opens a ticket with a freelancer: "Here's my repo. Can you just fix it?"
The freelancer opens the repo. And closes the tab.
What vibe coding actually produces 🧬
Let me be specific, because "vibe coding fails" is said a lot without anyone explaining what the failure mode looks like in code.
Here's what a vibe-coded codebase typically contains after 8 weeks of active development:
No migration strategy. The database schema was changed 14 times by prompting "add a column" or "rename this field." No migration files. No history. If you need to roll back, you cannot.
No error boundary strategy. Every API call either works or throws an unhandled exception that surfaces as a blank screen. No logging. No error tracking. The founder doesn't know the app is broken until a user tells them.
No deployment pipeline. The app is running on a shared server because the AI suggested it and the founder clicked yes. Every change goes straight to production. One bad prompt away from a 3 AM outage.
Ghost dependencies.
package.jsoncontains 47 dependencies. The app uses 11. The other 36 were installed for features that were later removed. Two have known CVEs.God components. One React component that is 840 lines long. It manages auth state, renders the dashboard, makes three API calls, handles form validation, and contains a function called
handleEverything. Never refactored because every attempt broke three other things.
💡 None of this is the founder's fault. They used the tools correctly. The tools just weren't built for what comes after the demo.
The gap nobody talks about 🕳️
AI coding tools are exceptional at one specific thing: producing code that looks correct and runs once.
They are genuinely bad at producing code that:
- Runs correctly under load
- Fails gracefully when something goes wrong
- Can be understood by a human who wasn't in the original chat
- Can be extended without understanding the full system
The gap between "demo-ready" and "production-ready" is not a gap in features. It's a gap in architecture. And architecture is the one thing you cannot prompt your way into.
When a senior engineer reads a codebase, they're not just reading the code. They're reading the decisions. Why is this service synchronous when it should be async? Why is this data stored here instead of there? Why does this component know about things it has no business knowing about?
A vibe-coded system has no decisions. It has outputs. You cannot fix that with more prompts.
The rescue pattern — what actually fixes it 🛠️
We've rebuilt or rescued vibe-coded MVPs at saro enough times that the pattern is almost always the same.
Weeks 1–2: Triage
What exists. What is worth keeping. What needs to go. Usually the UI is salvageable. Usually the data layer is not. We document what the system is supposed to do versus what it actually does — because those are almost never the same thing.
Weeks 3–5: Rebuild the foundation
Replace the database interactions with a real data access layer. Add error handling that actually handles errors. Put in a deployment pipeline with a staging environment. Strip ghost dependencies. Split the god components.
None of this is glamorous. None of it goes in a launch tweet. It's the invisible work that makes everything else possible.
Weeks 6–8: Build what was always the point
Now that the foundation holds, we add the features the founder actually needed at week 1. It takes 2 weeks instead of the 11 weeks they spent prompting. Because the foundation holds.
What actually breaks at user 50 📊
Three failure modes, in order of how often we see them:
Concurrent session failures. The app was tested by one person at a time. The state management was never built for concurrent access. The first time two users hit the same endpoint simultaneously, data gets corrupted.
Query performance cliffs. The database queries that worked at 100 rows don't work at 100,000. No indexes were added because nobody told the AI to add them. The app goes from fast to unusable overnight.
Auth edge cases. The happy path works. Expired token path doesn't. "User on two devices" doesn't. "User changes their email" definitely doesn't. These aren't hard problems. Nobody prompted for them.
None of these are AI problems. They are planning problems. The AI would have handled them correctly if someone had thought to ask.
A different way to think about AI in development 🤖
Here's what I actually believe, and I want to be precise because the discourse is sloppy in both directions.
AI coding tools are extraordinary for:
- Generating boilerplate fast
- Prototyping an idea to see if it's worth pursuing
- Writing tests for code you've already designed
- Filling in implementations when the architecture is already decided
AI coding tools are bad for:
- Making architectural decisions
- Understanding the consequences of a change across a system
- Knowing when NOT to add something
- Caring about what the codebase looks like in 6 months
The mistake is not using AI to write code. The mistake is using AI to make decisions that require judgment about the future state of the system.
The best developers I know use AI constantly. They use it to write fast. They don't use it to think.
The honest version of this advice 💬
If you're a developer working with a non-technical founder, the most valuable thing you can do is not write faster code.
It's to have the conversation about what "done" actually means before you start.
A prototype that proves the idea is done when it runs once and looks right.
A product that real users depend on is done when it fails gracefully, recovers automatically, can be understood by the next developer who touches it, and doesn't require the person who built it to be on call forever.
Those are different things. They require different approaches. Knowing the difference — and being able to explain it to someone paying you to move fast — that's the job.
Where the discourse goes wrong 🎯
People say "vibe coding is bad" as a moral statement about shortcuts. That's not what I mean.
Vibe coding is a tool. An excellent tool for what it's designed for. The problem is the mismatch between what the tool produces and what the founder believes they have when the demo works.
A founder who uses Bolt to validate an idea in a weekend is making a smart decision.
A founder who runs their first 200 paying users on that weekend prototype is making an expensive one.
The developer's job — the human in the loop — is to know which situation you're in, and build accordingly.
We run saro — an AI development agency for US startup founders who tried Bolt, Lovable, or Cursor and hit a wall. We rescue vibe-coded MVPs, build custom AI agents, and ship production-ready products. If you've got a broken codebase or want something built right the first time: shoparonline.com
If you've pulled apart a vibe-coded codebase — what was the worst thing you found? And how did you decide what to keep vs tear out entirely? Drop it in the comments.
Top comments (0)