Stabilize & Fix
Stabilizing means breaking the loop where each fix creates new failures — usually caused by duplicated logic, files too large for the model to edit reliably, and no tests to catch what a change broke.
There is a specific failure state that AI-assisted projects reach, and the people in it recognize the description immediately. You ask for a fix. You get one, plus two new bugs. You fix those. The original problem comes back. Several hours and a lot of credits later, the app is in worse shape than when you started.
This is not a sign that you are bad at prompting. It is structural. Once the same logic exists in four places, changing one of them is guaranteed to produce an inconsistency, and once a file grows past the point where a model can hold it in context, edits to it become unreliable in ways that look random.
This sounds like you if…
- “Every fix breaks two other things.”
- “The AI keeps rewriting code that was already working.”
- “It says it fixed the bug and it clearly did not.”
- “I've burned through my credits going in circles.”
- “I'm scared to touch it now.”
What this covers
- Stop the bleeding first: get the current version into version control with a known-good commit you can always return to.
- Reproduce the failures reliably. A bug that cannot be reproduced on demand cannot be verified as fixed.
- Find the duplicated implementations and collapse them, so there is one place where each rule lives.
- Break apart the files that have grown too large to edit safely.
- Add tests around the paths that keep breaking, so the next change tells you immediately if it broke them again.
- Fix the actual bugs, in priority order, with each fix verified rather than assumed.
Worth knowing
Stabilize & Fix — questions
Why does the AI keep breaking things it already fixed?
Two reasons, usually together. It cannot see the whole codebase at once, so it rebuilds context from whatever it was shown and can miss that a rule already exists elsewhere. And when the same logic has been duplicated across several files, fixing one copy leaves the others contradicting it. The model is behaving reasonably given what it can see; what it can see is the problem.
Is my project too far gone?
Almost never, and the people who ask are usually further from that line than they think. Rebuilding is occasionally the cheaper option, but it is a conclusion that should follow from reading the code, not from a vendor's preference for larger projects.
Can you just fix the one bug that's blocking me?
Sometimes, and if it is genuinely isolated we will say so. But if the bug is a symptom of the structural problem, fixing it in isolation is work you pay for twice. We will tell you which situation you are in before you commit to anything.
Not sure how bad it is? That's the normal starting point.
Tell us what you built and what's worrying you. If the honest answer is that you don't need us, we'll say so.