When the AI-built app breaks, start here

AI Code Design editorial · September 2026 · 3 min read

Pause the guessing cycle

When a feature fails, repeated requests to “fix it” can produce a chain of changes without a shared understanding of the problem. Stop and reproduce the issue. Record the shortest sequence that causes it, what you expected, and what actually happened. That evidence makes the next step much smaller.

Inspect the relevant boundary

Ask where the expected behavior stops: input, validation, state update, storage, network request, or display. You do not need to understand the entire application to isolate one boundary. Read the actual error carefully and avoid sharing secrets or personal data from logs.

Ask for a cause before a patch

Give the AI partner the reproduction steps and relevant code. Ask it to identify the likely cause, what evidence supports that explanation, and which assumption remains uncertain. A confident answer still needs to be checked against the project.

Change one thing and verify

Keep a recoverable checkpoint. Apply the smallest reasonable fix and repeat the original steps. Then check the nearest related behavior: an empty value, a second submission, a reload, or a slower connection. Avoid accepting a fix merely because the visible error disappeared.

Record what you learned

Write a short note describing the cause and the check that now protects the behavior. This is more useful than preserving a long debugging transcript. If you cannot explain the fix, ask for a plain-language walkthrough before building more features on top of it.