// AI PROJECT RESCUE

How do you fix an AI-built app instead of rebuilding it?

Something in the AI-built app is broken, and the instinct is to burn it down and start over with better prompts. That instinct is almost always wrong. You fix an AI-built app instead of rebuilding it by triaging which of four kinds of broken you are actually looking at before you commit to a path, because most rebuilds re-run all the old work to solve a problem that was never in the code. The four categories: stale-state breakage, where the runtime is not running the code you think it is, and the fix is minutes not days. Surface-versus-semantic mismatch, where the page shows the right number but the calculation ignored an input, and the fix is surgical once you trace the gap. Structural drift, where each change made sense alone but the whole no longer holds one architectural opinion. And genuine fundamental mismatch, the rare case where rebuild really is the answer. A rebuild reproduces the same failure, because the same prompts produce the same kind of code. The discipline that catches the bug is the same discipline whether you fix or rebuild, so you may as well install it against the code you already have. That is the whole rescue-spec idea: write down what the system must do, then repair against it. If you inherited an AI-built codebase that is drifting and the rebuild clock is ticking, this cluster is the triage that tells you whether it is warranted.

// the method

// related topics

If you inherited an AI-built codebase that's drifting and want someone to think through the stabilization with you, /work-with-us.

→ work with us

← back to the log