How to debug AI generated code when you are not an engineer

Why is AI generated code hard to debug when you did not write it?

Because the code is close to right, and you have no memory of how it was built. In the Stack Overflow Developer Survey 2025, 66 percent of developers named "AI solutions that are almost right, but not quite" as their biggest frustration with AI tools, and 45 percent said "Debugging AI-generated code is more time-consuming." Those are professional developers. For a product manager who built an app by describing it, the gap is wider: you know what you asked for, but not what the tool actually wrote.

The good news is that debugging is mostly a method, not a language skill. You already do the core of it when you triage a bug report from a user: reproduce, narrow down, confirm the fix. The loop below applies that same discipline to an AI tool that will happily propose fixes whether or not it understands the problem.

This page is about fixing an app that is already broken. If the question is whether AI code is correct before it merges, see how to verify AI-generated code as a product manager.

What is the debugging loop, step by step?

Seven steps, in order, every time:

Step	What you do	Why it matters
1. Reproduce	Write the exact steps that trigger the bug, what you expected, what happened	A bug you cannot trigger on purpose cannot be confirmed fixed
2. Read the error	Copy the full error from the browser console or the tool's logs	The error usually names the file and line where things went wrong
3. Ask for an explanation	Ask the AI what the error means and what might cause it, with no fix yet	You can check an explanation; you cannot check a fix you do not understand
4. Isolate	Work out whether the problem is in what you see, the logic, or the stored data	Narrows the fix to one part of the app
5. Fix one thing	Ask for one specific change, then stop	Tells you which change caused which result
6. Retest everything	Rerun the bug steps and the whole main flow	Catches fixes that broke something else
7. Checkpoint	Save a working version and name it	Gives you a known-good state to return to

The step people skip is 3. The instinct is to paste the error and type "fix it." The AI will produce a change, and it will often look confident, but you have no way to tell a real fix from a change that hides the symptom.

How do you reproduce a bug precisely?

Write it like a bug report you would accept from someone else. Take an invented example: a team lunch-order app where the total is wrong.

A weak report: "The total is broken."

A useful report: "Add three orders: Ana €12, Ben €9, Caro €15. Total shows €36, which is correct. Delete Ben's order. Expected total €27. Actual total €36. Refreshing the page shows €27."

The useful version tells the AI almost everything. The calculation is right on a fresh load, so the maths works. The total is stale only after a delete, so the problem is in how the app updates after removing an item, not in the formula. You have isolated the bug before asking for anything.

How do you read an error when you cannot read code?

You do not need to understand the whole message, only where it points. In a browser app, right-click the page, choose Inspect, and open the Console tab. Red lines are errors. Most name a file, a line number, and a short description such as "undefined is not a function" or "cannot read properties of null."

Copy the full error, including the lines underneath it, and paste it with your reproduction steps. Ask for an explanation first:

Here is a bug and the full console error.

Steps: [your reproduction steps]
Expected: [what should happen]
Actual: [what happens]
Error: [full error text]

Before changing any code, explain in plain language:
1. What this error means.
2. Which part of the app it comes from.
3. The two or three most likely causes, and how I could tell them apart.

If there is no error at all, which is common with logic bugs like the stale total above, say so. "No console error; the number is simply wrong" is itself information, because it rules out a crash and points at the calculation or the update logic.

How do you isolate which part of the app is broken?

Most small apps have three layers, and a bug usually lives in one. What you see on screen is the interface. The rules that turn inputs into outputs are the logic. What gets saved and loaded is the data. Ask which layer each symptom points to:

Symptom	Likely layer	First thing to check
Button does nothing, layout broken, text missing	Interface	Console errors when you click
Wrong number, wrong order, wrong result	Logic	Does the right answer appear after a refresh?
Data gone after refresh, or old data reappears	Data	Is the save actually reaching the database?
Works for you, fails for someone else	Data or access rules	Different account, permissions, or empty starting data
Worked yesterday, broken today	Whatever changed last	Compare with the last checkpoint

Once you know the layer, tell the AI: "The problem is in how the total updates after a delete, not in the calculation. Change only that." Constraining the fix is how you stop the AI from rewriting half the app to solve a small problem.

How do you get the AI to fix one thing without breaking others?

Ask for one change, then test before asking for anything else. A prompt that bundles a fix with an improvement ("fix the total and also make the list sortable") produces two changes you cannot separate.

After every fix, rerun your reproduction steps and then the whole main flow, not just the part you fixed. Then ask for a test that captures the behaviour, in plain language: "Write a test that adds three items, deletes the middle one, and checks the total." Run it after every later change. That test is the cheapest insurance against the same bug returning.

Simon Willison's rule for production code is a useful standard even for a prototype: "I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else." You do not need to explain every line. You should be able to explain, in plain words, what the fix changed and why it solves the bug you reproduced.

When should you roll back instead of trying another fix?

After two or three failed fixes, or the moment a fix breaks something that used to work. Each failed attempt adds code, and the AI starts fixing its own previous fixes. By attempt five, the app is further from working than when you started.

Rolling back is cheap if you saved checkpoints. Replit's documentation describes its checkpoints as "save points in a video game - you can always go back to a working version of your app." Lovable's prompting guide recommends bookmarking a version after each working state and ends with the attitude that makes debugging calm: "Then prompt boldly, and revert freely."

After a rollback, do not repeat the same prompt. Take what you learned from the failed attempts (the explanation, the layer, the error) and ask for a smaller, more specific change.

When should you stop and bring in an engineer?

When the bug involves payments, logins, personal data, secrets or anything you cannot afford to lose, bring in someone who can read the code, even if the AI proposes a fix that seems to work. A wrong fix in those areas does not show up as a broken screen. It shows up later as a leaked key, a charge, or data someone else can see.

The other signal is being stuck: you have rolled back twice and still cannot reproduce the bug reliably or get an explanation that makes sense. At that point the method has done its job by telling you the problem is beyond it. When not to use an AI coding agent sets out where that line sits more generally.

Does using AI to debug actually save time?

The honest counterpoint comes from a randomised trial. METR studied experienced open-source developers working on their own repositories and found that "when developers use AI tools, they take 19% longer than without." The developers had expected AI to speed them up by 24 percent. The study measured experienced engineers on large, familiar codebases with early-2025 tools, which is very different from a product manager fixing a small prototype, so it does not tell you AI debugging is slower for you. What it does show is that the feeling of speed and actual speed can diverge, and that unstructured back and forth with an AI is where time disappears.

That is the argument for the loop. The steps that feel slow (writing reproduction steps, asking for an explanation first, rolling back instead of stacking fixes) are the ones that stop an afternoon of prompting from going in circles.

Where can you practise debugging a broken vibe coded app?

The vibe coding practice exercise is a debugging task by design. It comes from Builders Camp's Zero to Shipped with Vibe Coding bootcamp: a product manager built a meeting cost calculator in 45 minutes, left it half-working and broken in four ways, and you have 60 minutes to get it to a shippable state for a leadership presentation. One of the four problems is a total that recalculates wrongly after an attendee is deleted from the middle of the list.

The bootcamp runs 1 week with 2 live sessions and 11 self-paced microlessons, directed by Andre Albuquerque, and sits in the Vibe Coding Expert Track. Its published syllabus covers scoping the smallest shippable MVP, prompting for building, backend logic and integrations, shipping and deployment, and the post-ship iteration loop. For the mistakes that create most bugs in the first place, see vibe coding mistakes to avoid.

Next time something breaks, write the reproduction steps before you open the chat. Half the time, writing them tells you where the bug is.