Guides / Prompting and shipping

How to Debug an AI-Built App: A Practical Method

A step-by-step way to fix bugs in apps built with AI: reproduce the problem, read error messages, use browser devtools, describe it well, and roll back.

Mythex Team · 2026-09-29 · 7 min read

To debug an app built with AI, first make the bug happen again on purpose, then collect evidence — the exact steps, the error message, and what the browser console and network tab show — and give that to the AI as "I did X, expected Y, got Z". If a fix makes things worse, roll back to the last working version instead of piling fixes on top. You don't need to read the code to do any of this well.

This guide covers the whole loop, including a quick tour of browser developer tools for non-developers.

The debugging loop

Every bug fix, whether a person or an AI does it, follows the same loop:

1. Reproduce — make the bug happen reliably.
2. Observe — gather the error message and what the app was doing.
3. Describe — give the AI precise steps, expected result and actual result.
4. Fix — let the AI change one thing.
5. Verify — repeat the exact steps and confirm it's fixed, and that nothing nearby broke.
6. Roll back if needed — if it got worse, undo and try again with better information.

Most time wasted on AI-built apps comes from skipping steps 1, 2 and 5: saying "it's broken", accepting a change without testing it, and then asking for another fix on top of a broken one.

Step 1: Reproduce the bug

A bug you can trigger on demand is half fixed. Try to find the shortest set of steps that causes it.

Ask yourself:

• Does it happen every time? If only sometimes, what's different when it happens — a particular record, a slow connection, being logged out?
• Does it happen for every user? Log in as a different account. Many bugs only show for new users with no data, or for a user with a different role.
• Does it happen on every device? Try a phone-width screen and a different browser.
• Did it start after a specific change? If it worked yesterday, the last few changes are the prime suspects.

Write the steps down as a short numbered list. You'll paste it into the prompt later.

Step 2: Read the error message

Error messages look intimidating, but you only need a few parts of them.

You don't need to understand it; you need to copy it exactly. "Cannot read properties of undefined (reading 'name')" tells the AI that the code expected some data (probably a booking or a user) that wasn't there. A paraphrase like "some undefined error" loses that.

A few common ones, roughly translated:

• undefined / null errors — the code expected data that didn't arrive. Often a loading state or an empty list the code didn't handle.
• 404 Not Found — the page or API address doesn't exist. Often a typo in a route or a link to a page that was renamed.
• 401 Unauthorized / 403 Forbidden — the request wasn't logged in, or the user isn't allowed to do that.
• 500 Internal Server Error — the server-side code crashed. The real reason is in the server logs, not the browser.
• CORS errors — the browser blocked a request to a different domain. Usually a configuration issue on the server side.

Step 3: Use the browser developer tools

Every desktop browser has built-in developer tools ("devtools"). They show what the page is doing behind the scenes. In Chrome, Edge and Firefox, right-click anywhere on the page and choose Inspect, or press F12 (Cmd+Option+I on a Mac). In Safari, turn on the Develop menu in Safari's settings first.

You only need three tabs.

Console

The Console tab lists errors and messages from the page's code. Errors are shown in red. If a button does nothing when you click it, the console will very often show a red error at the moment you click. Copy the full text of the error (right-click it for a copy option in most browsers).

Network

The Network tab lists every request the page makes — loading data, saving a form, logging in. Open it, then repeat the steps that cause the bug.

• Look for rows in red or with a status of 400 or above.
• Click a failing row to see its Response. A server error often includes a message there that's more useful than anything on screen.
• Note the request's URL and status code — "the POST to /api/bookings returned 500" is a very useful sentence to give the AI.

Tick Preserve log if the bug involves a page reload or redirect, so the requests don't disappear.

Elements

The Elements (or Inspector) tab shows the page's structure and styles. It's most useful for layout bugs: hover over an element to see its size and spacing highlighted. You don't need to edit anything here; it's enough to say "the footer is 2,000 pixels wide on mobile and pushes the page sideways".

Step 4: Check the server logs

Some bugs happen on the server, where the browser can't see them. A 500 error in the network tab is the classic sign. Server logs — the text output of your backend while it runs — usually contain the real error with a stack trace (a list of the functions that were running when it failed).

Where you find them depends on your tool. In most AI app builders you can open a terminal or log view for the project, or simply ask the AI: "Check the server logs for errors from the last request and tell me what failed."

Step 5: Describe the bug to the AI

Put what you've gathered into this shape:

On the Bookings page, logged in as a member: I clicked Cancel on tomorrow's 9:00 class. Expected: the booking disappears and the class shows one more free spot. Actual: nothing changes on screen. The console shows TypeError: Cannot read properties of undefined (reading 'id') at BookingCard.tsx:31, and the network tab shows DELETE /api/bookings/123 returned 500. Find the cause, fix it, and check that cancelling works for a member with one booking and with several.

Why each part matters:

• Where and as whom narrows it to one screen and one role.
• Exact steps let the AI reproduce it.
• Expected vs actual defines what "fixed" means.
• The error text and failing request point straight at the cause.
• "Check that…" asks the AI to verify, not just edit.

If the AI has attempted a fix twice and failed, ask it to explain before changing anything:

Don't change code yet. What do you think causes this, and what evidence supports it?

A wrong theory is easy to spot when it's written out, and much cheaper to correct than a wrong fix.

Step 6: Verify, then check nearby

When the AI says it's fixed, repeat the exact steps from Step 1. Then check the things around it:

• The same action for a different user role
• The same action with no data, and with a lot of data
• Pages that share components with the one you fixed
• A phone-width screen, if the fix touched layout

AI changes sometimes fix one path and quietly break another. A two-minute check now saves a confused hour later.

Step 7: Roll back instead of piling on

If a fix made things worse, or you've gone three rounds without progress, go back. Rolling back to the last version that worked and rephrasing with better evidence almost always beats asking for a fourth fix on top of three wrong ones. Each failed attempt leaves code behind, and that code confuses the next attempt.

Good habits that make rollback easy:

• Test after every change, so you know which change broke things.
• Keep changes small — one feature or fix per message.
• Note the last good version before starting something risky.
• If the code is in Git, commit working versions so you can return to them.

Common bug patterns in AI-built apps

When the problem isn't a bug

Some "bugs" are the AI building exactly what it was told, and the description was ambiguous. If the fix you're asking for is really a change in behaviour, say so plainly: "Change it so that…". If you find yourself unsure what the correct behaviour even is, decide that first. Our guide on writing prompts for AI app builders covers how to specify rules clearly. And if you're preparing an app for real users, taking an AI prototype to production covers the checks worth doing before launch.

Debugging in Mythex

Mythex has tools for each step of the loop:

• Preview to reproduce the bug, including a phone-size frame.
• /test has the agent click through your live preview like a user and report broken flows.
• /fix points the agent at breakage specifically.
• Plan mode lets the agent investigate and explain before it edits anything.
• Code → terminal shows your app's server logs.
• Revert to this point on any reply rolls the project back to that checkpoint.

If a publish fails, the publish dialog usually offers Fix with AI, which reads the build output or the app's logs. See Debug your app and Publish troubleshooting in the docs.