The AI Broke My App: 7 Ways to Fix Errors Without Starting Over

AI tools make mistakes. A change that looks small can affect a shared component, data request, or route. The difference between frantic rebuilding and useful debugging is a repeatable process. Work down this seven-step ladder and record what happened at each step.

Step 1: read the actual error

Do not paraphrase “it broke.” Copy the exact visible message, note the page and action that produced it, and record the build or version. If the app shows no message, write down the observable result: “Selecting a time and pressing Confirm leaves the button disabled; no confirmation appears.” Specific evidence gives the next prompt a target.

Step 2: inspect available diagnostics

Check the browser console, network activity, build output, and service logs that are appropriate to the project. A red console message can identify a rendering problem; a failed network request can separate a screen problem from a server problem. Do not paste secrets, private customer data, or unrestricted logs into a prompt. Capture only the relevant error and surrounding context.

Step 3: ask for fresh eyes on one path

Use a narrow prompt: “The booking submission fails after a user chooses a valid slot. Review the files involved in that submission, identify the root cause from the error below, and preserve unrelated styling and payment behavior.” Name expected and actual results. Ask the tool to explain the diagnosis before changing broad areas.

Step 4: return to a scoped checkpoint

If a recent change caused the failure, restore the last known working version of the affected code or revert that change. A rollback is a controlled checkpoint, not permission to delete a database, erase user records, or replace the entire project. Back up important data before any destructive operation and confirm exactly what the platform will restore.

Step 5: rebuild only the broken piece

When repair is harder than replacement, isolate the smallest function or component that can safely be rewritten. Preserve its inputs, outputs, accessibility labels, analytics, and surrounding contracts. Then test the path that failed plus nearby paths that share the same code.

Step 6: simplify the behavior

Complexity can hide the cause. Temporarily remove optional animation, secondary fields, or extra branching while keeping the core outcome. Prove the simple path works, then add one requirement at a time. Do not simplify away permission checks, payment verification, privacy controls, or error handling.

Step 7: ask for an explanation and a regression check

Ask what failed, why the change fixes it, and what test prevents the same class of failure. Keep the explanation in plain language. Add a focused frontend assertion for visible behavior, verify the relevant server path if data changes, and manually repeat the user journey.

Prevent the next panic rebuild

Test after each meaningful change, save working checkpoints, and keep a short list of paths that must remain intact. A defect log should include page, action, expected result, actual result, evidence, severity, build, and retest status. This turns a confusing session into a sequence of falsifiable checks.

Fixes take as long as their causes require; there is no honest universal ten-minute promise. The reliable habit is smaller changes, specific evidence, and retesting. For a complete workflow, use How to Test a Vibe-Coded App.