How to debug an AI-built app
Debugging is narrowing, not guessing. Reproduce the failure reliably, read the actual error text rather than the friendly message, work out which layer it came from, change one thing, and confirm the failure is gone by repeating the original steps.
Why is guessing so tempting and so slow?
Because an AI tool will happily act on a guess. You describe a symptom, it produces a change, the change looks plausible, and nothing improves — but now two things are different. Three rounds of that and you no longer know what the original problem was.
One change at a time is not caution. It is the only way to know which change did anything.
Step 1: Reproduce it on purpose
- 1Write down the exact steps, including who you were signed in as.
- 2Do it again and confirm it fails the same way every time.
- 3Try it signed out, and as a second account.
- 4Try it on the live site and in your development environment.
The answers to those last two often solve the problem before you read any code: fails only in production points at configuration, fails only for other accounts points at permissions.
Step 2: Read the real error
'Something went wrong' is a design choice, not information. The real error lives in one of four places, and you should look in this order: the browser console, the browser's Network tab, your server or function logs, and your provider's dashboard.
| Where | Tells you |
|---|---|
| Browser console | Front-end crashes and thrown errors |
| Network tab | Status code and response body of the failing request |
| Server logs | Why your own endpoint returned 500 |
| Provider dashboard | Rejected requests, quota, verification problems |
Step 3: Decide which layer it is
- Nothing rendered at all → front end or the build.
- Page rendered, request failed with 4xx → your request, the credential, or permissions.
- Request failed with 5xx → your server code, or the provider.
- Request succeeded but the data is wrong or empty → query or access rules.
- Works locally, not deployed → configuration, not code.
Naming the layer before touching anything eliminates roughly three-quarters of the codebase from consideration.
Step 4: Change one thing
If you ask an AI tool for help, give it the real error text, the layer you have identified, and the constraint that it should change one thing. A prompt like 'the request to /api/notes returns 401 while signed in; the Authorization header is missing from the request — find why it is not attached' gets a targeted fix. 'Notes are broken, fix it' gets a rewrite.
Step 5: Verify like you doubt it
- 1Repeat the original reproduction steps exactly.
- 2Repeat them as a second account and signed out.
- 3Check the thing that was previously working next to it still works.
- 4Say in one sentence what was wrong and why the change fixed it. If you cannot, you have not finished.
That last sentence is the actual goal. A fix you cannot explain is a fix you cannot repeat when it happens again in a different corner of the app.
Frequently asked questions
- What if I cannot reproduce it?
- Add logging around the suspected path and wait for it to happen again. An intermittent bug you cannot reproduce cannot be verified as fixed either.
- Should I revert instead of debugging?
- If the break is recent and the site is live, revert first and debug afterwards. Reverting is a fix for users and a pause for you.
- How do I stop the AI from rewriting everything?
- Name the file, name the symptom, and state what must not change. Ask for the smallest change that addresses the error.
Practice this in MessyDev
Reading it once helps. Doing it once sticks. These are the hands-on parts of MessyDev that cover the same ground.
Keep going
- How to troubleshoot an AI-built applicationA symptom-to-cause index. Start from what you can see — a blank page, an empty list, a failed login, a dead deploy — and follow it to the layer responsible.
- 401 vs 403 vs 404 vs 429 vs 500Five status codes that cover most failures in an AI-built app, what each one is really saying, and who has to fix it.
- Why does my app work locally but not after deployment?The differences between your machine and a deployment — configuration, case sensitivity, build strictness, real users — and how to find which one bit you.