We vibe code at InfiniteUp. Most days, on real client work. I want to say that first, because what follows sounds like criticism and isn’t.
Describing what you want in plain language and watching working software appear is genuinely one of the best things to happen to this profession. It has made our small team faster at things that used to be tedious, and it has let designers and QA people on our team accomplish work that previously needed an engineer’s calendar. That is not hype. That is our Tuesday.
But there’s a specific thing it does that nobody puts on the box, and it’s the reason we keep getting calls from founders whose apps stopped working and who cannot explain why.
Vibe coding is cruise control
Cruise control is a wonderful invention. It holds your speed so you can stop thinking about your right foot and think about the road instead. On a long drive it’s the difference between arriving tired and arriving wrecked.
What cruise control does not do is know where you are going. It has no opinion about your destination. It will hold seventy miles an hour just as faithfully in the wrong direction as the right one — more faithfully, in fact, because nothing jolts you into checking the map.
That’s the whole thing. Vibe coding is extraordinary at maintaining momentum and completely indifferent to heading. If you know where you’re going, that’s a superpower. If you don’t, it’s the most efficient machine ever built for getting lost, because it removes the friction that would otherwise have told you something was wrong.
The route is not overhead. The route is the asset.
Here is the part that surprises people. When you build software, the finished product is only half of what you’re making. The other half is the record of how you got there — which approaches you rejected, why the data is shaped the way it is, what that strange-looking bit of logic is defending against, which parts are load-bearing and which are scaffolding.
Engineers don’t keep that record because we enjoy paperwork. We keep it because every future change depends on it. The reason a good team can add a feature to a two-year-old app in an afternoon isn’t that the code is beautiful. It’s that someone can still answer the question “why is it like this?” — and therefore knows what will break.
Vibe coding produces the destination and throws away the route. You get working software and no rationale. And you don’t notice, because working software is the thing you were looking at.
That’s the missed-exits problem. Not one dramatic wrong turn — a hundred small ones you had no reason to question. Each prompt papers over the last. Nothing objects. The app keeps running, so the feedback that would normally arrive as an error arrives instead as a bill, months later, when you try to change something and discover you can’t.
Why the same tool is a superpower for us
We get enormous value from AI-assisted development, and it’s worth being precise about why, because the reason is not that we’re better at prompting.
It’s that we already have the map. Before anyone writes a line, we have decided on the data model, the auth approach, where state lives, what happens offline, which third parties we’re trusting and what we do when they fail. We have opinions about all of it, and those opinions came from shipping 40+ apps and being wrong in public a few times.
Against that backdrop, AI is a spectacular accelerator on the known stretches of road. And critically, we can tell when it’s wrong — not by testing whether the app still runs, but by recognising that a solution doesn’t match how the system is supposed to work. That recognition is the entire skill. It’s what we wrote about in MCP is a scalpel, not a chainsaw: the tool is superb at the exact thing you point it at, and confidently shallow the moment it has to understand the whole project.
Same tool. Same prompts, more or less. Completely different outcome, because one driver knows the destination and the other is trusting the road.
How to tell you’re in the desert
Being stranded doesn’t announce itself. From the driver’s seat it feels like the app is nearly done and has been nearly done for a while. These are the actual signals, and none of them require you to read code:
- You can’t explain why it works. Not the whole thing — any single part. If the honest answer is “the AI did that,” you have no map.
- Fixing one thing breaks another, repeatedly. The signature of hidden coupling: parts that depend on each other in ways nobody documented, including the tool that wrote them.
- It was fine in testing and fell over with real users. Twenty friendly testers and two hundred real ones are different physics. Generated code is usually written for the happy path you described, not the mess users actually bring.
- Nobody else can work on it. If a second developer joining would take weeks to become useful, the knowledge isn’t in the project — and it isn’t in you either.
- You’re afraid to change it. The clearest tell of all. With no tests and no rationale, every edit is a gamble, so you stop editing, so the product stops improving.
- You don’t know where your users’ data goes. Not a maintenance problem. A legal one, and it doesn’t wait for you to be ready.
One or two of these is normal for any young product. Four or more and you’re out of fuel in the wrong biome — and, importantly, further from the mountains than when you started, because months went by.
What we do about it
Enough founders have arrived at our door in exactly this position that we treat it as its own kind of engagement rather than a normal build. We call it a vibe code rescue, and it runs in three stages.
- 1 · Reconstruct the map. We read what exists and write down what it actually does — data model, integrations, auth, where the real risk sits. You get a document that explains your own product to you. Some clients stop here, because the answer to “is this salvageable?” is worth knowing on its own, and it’s usually yes.
- 2 · Stabilise. Fix what’s dangerous before touching what’s untidy: data integrity, security and privacy exposure, the crashes real users hit. We add tests around the parts that matter so change stops being a gamble. This is deliberately not a rewrite — rewrites are how rescues turn into eighteen-month projects.
- 3 · Get moving again. With a map and a floor under you, we build the things you actually wanted — and hand back a project a normal team can work on, IP and all. Frequently with AI in the loop again, now that there’s a heading to hold.
Two honest caveats. Sometimes stage one concludes that you’re fine and should keep going as you are — we’ll say so, and that’s a good outcome, not a lost sale. And occasionally a rebuild genuinely is cheaper than a rescue; we’ll tell you that too, with the reasoning, because you’re paying for judgment rather than for reassurance.
Keep the cruise control on
The lesson here isn’t to distrust the tools. We’d be hypocrites, and you’d be slower for no reason. The lesson is that these tools are an accelerator, and an accelerator multiplies whatever direction you were already facing.
So decide the destination deliberately, before you’re moving at speed. Keep the route — write down why things are the way they are, even roughly, even in a document nobody else will read. And look up from the dashboard now and then to check that the terrain outside still matches the map.
If you’ve already looked up and the view is all sand: that’s a much more common place to be than the internet makes it sound, and it’s recoverable far more often than it feels. A free 30-minute call is the fastest way to find out where you actually are — or read how we approach app development for founders and custom business software when there’s a map from day one.