Guides / Rescue
The failure loop is familiar: something breaks, you ask the AI to fix it, the fix breaks two other things, and an hour later the app is worse than when you started. The way out is not a better prompt. It is the same discipline engineers use on any unfamiliar codebase: rank the damage, pin the version, and change one thing at a time.
Before touching anything, place the problem in this order of severity, and deal with the highest one that applies:
The most expensive vibe-coding injury is self-inflicted: regenerating over a half-working app with no way back. Whatever state you are in, freeze it first:
git init # if the project somehow is not a repo yet git add -A git commit -m "checkpoint: before attempting fix" git branch known-good
From now on, every AI-assisted fix happens on a branch, gets tested, and is either committed or discarded whole. The known-good branch is the state you can always return to. This single habit converts "the AI destroyed my app" into "I threw away a branch".
Call in a senior engineer when the bug touches money, sign-in, or data integrity; when the same symptom has survived three disciplined ladder attempts; or when fixing anything requires understanding everything, which is a sign the architecture, not a bug, is the problem. The economics are simpler than they feel: a focused day of senior debugging is routinely cheaper than a week of divergent prompting, and it usually ends with you understanding your own codebase better.
And if the app mostly works but launching it scares you, that is not a bug at all; that is the production-readiness checklist.
Questions
If the core flows work and users like the product, fix and harden; the working version embodies decisions worth keeping, and most breakage lives in a few identifiable seams. Rebuild only when the architecture itself blocks every change, which is rarer than frustration makes it feel. A review can settle the question in a day.
Unconstrained regeneration: the model rewrites more than the bug required, guided by an increasingly contradictory conversation, and it cannot see the whole system it is editing. The countermeasures are boring and effective: version control, narrow evidence-rich prompts, one change at a time, verify before committing.
Yes, on three conditions: the code lives in version control with meaningful commits, changes are verified rather than assumed, and the security fundamentals from the twelve-point checklist have been run. Under that discipline AI-built code behaves like any other code: imperfect, improvable, and shippable.
Start by asking the AI to explain, not to fix: a guided tour of the files, the data flow, and where each feature lives costs nothing and cannot break anything. Beyond that, an engineer can map the codebase for you in a session. Understanding is the durable fix; prompting without it is what created the loop.
When the loop will not close
We take broken and fragile AI-built apps, stabilise them, and hand back a working product with the fixes explained. If it only needs a few small changes, the review says exactly that, and you keep the list.