How to troubleshoot an AI-built application
Start from the symptom, not the code. Each visible failure has a short list of plausible causes, and one check that separates them. This page is the routing table; the individual guides handle each destination in depth.
The symptom index
| What you see | Most likely cause | The one check |
|---|---|---|
| Blank white page | A crash while rendering | Browser console, first red error |
| Empty list, no error | Access rules or a filter | Query the table as the owner |
| Login does nothing | Redirect URL or session handling | Network tab during the login round trip |
| 401 everywhere | No credential attached | Is the Authorization header sent? |
| 403 on one action | Permission rule | Does the rule name this user? |
| Works locally only | Environment configuration | Compare variables in both environments |
| Deploy shows old code | Wrong branch or failed build | Check the latest deployment's commit |
| 429 from an AI provider | Rate limit or a loop | Count requests in ten seconds |
| Payment taken, nothing changed | Webhook not received or not verified | Provider's webhook delivery log |
| Emails never arrive | Unverified sending domain | Provider's delivery log, then spam |
How do you tell a front-end problem from a back-end one?
Open the Network tab and trigger the action. If no request is made, the problem is in front-end code — a handler that never ran, a condition that blocked it. If a request is made and fails, the problem is the request, the credential, or the server. If the request succeeds and the page still looks wrong, it is rendering.
What information should you collect before asking for help?
- 1The exact steps to reproduce, and who you were signed in as.
- 2Whether it fails in production, development, or both.
- 3The exact error text, copied not paraphrased.
- 4The failing request's URL, status code and response body.
- 5What changed most recently — the last commit or the last configuration edit.
That list is also what makes an AI tool useful rather than destructive. Paste those five things and you get a diagnosis; paste 'it is broken' and you get a rewrite.
What did the AI probably do?
- Added code that assumes a value exists — a column, a variable, a session.
- Made something work for the owner account without testing another user.
- Introduced a second way of doing something that already existed, so two paths now disagree.
- Removed a line it considered redundant that was load-bearing.
- Reported success after editing rather than after testing.
Checking the most recent diff against this list resolves a surprising share of 'it worked yesterday' reports.
When should you stop and revert?
When the live site is broken for real users, when you have made three changes without improvement, or when you can no longer describe the original failure. Revert to the last known good state, confirm it is genuinely good, and start the method again from a clean base.
Frequently asked questions
- Where do I find server logs?
- In your hosting platform's dashboard, under the deployment's functions or runtime logs. Browser tools cannot show you server-side errors.
- Is it ever the AI provider's fault?
- Sometimes — check their status page for a 5xx or a sudden wave of failures. It is worth thirty seconds before an hour of rewriting.
- How do I know a fix is real?
- You can reproduce the original failure on the old version, cannot reproduce it on the new one, and can explain why in one sentence.
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 debug an AI-built appA repeatable method: reproduce it, read the real error, find the layer, change one thing, verify. Written for apps whose code you did not type.
- Why am I getting a 401 error?A 401 means the server could not identify you. The causes, how to tell which one you have, and how to confirm the fix.
- 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.