Skip to main content
Troubleshooting9 min readPublished September 19, 2026Updated September 22, 2026

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

  1. 1Write down the exact steps, including who you were signed in as.
  2. 2Do it again and confirm it fails the same way every time.
  3. 3Try it signed out, and as a second account.
  4. 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.

WhereTells you
Browser consoleFront-end crashes and thrown errors
Network tabStatus code and response body of the failing request
Server logsWhy your own endpoint returned 500
Provider dashboardRejected 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

  1. 1Repeat the original reproduction steps exactly.
  2. 2Repeat them as a second account and signed out.
  3. 3Check the thing that was previously working next to it still works.
  4. 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