How to Ask AI to Fix a Bug Without Making It Worse
To get a good bug fix from an AI assistant, send three things together: what you did, what you expected, and what actually happened, plus the current code and any error message. Then ask for the smallest change that fixes that one problem. Vague reports such as “it’s broken” push the assistant to guess, and guesses are how a small bug turns into three.
This guide shows how to write the report, and how to check the fix before you accept it.
Reproduce the bug first
Before you write to the assistant, make the bug happen again on purpose. If you cannot repeat it, nobody can fix it. Write down the exact steps, in order, starting from a freshly loaded page:
- Open the page.
- Type 47.50 in the bill field.
- Click the 18 percent button.
- Look at the tip amount.
A report with numbered steps removes ambiguity. It also tells you whether the bug appears every time or only after certain actions, which is useful clue by itself.
Write the three-part report
Use a fixed shape every time:
What I did: [steps]
What I expected: [the result you wanted, with numbers if possible]
What happened: [the result you got, with numbers if possible]For example: “I entered 47.50 and chose 18 percent. I expected a tip of 8.55. The page shows 8.5.” With numbers, the assistant can see the pattern, here a rounding problem, almost immediately.
If something visible is wrong with layout, describe where: “On a narrow window, the Reset button overlaps the total.” A screenshot is useful if your tool supports attaching images.
Include the error message exactly
When the page is blank or a button does nothing, there is often an error in the browser console. Right-click the page, choose Inspect, and open the Console tab. Red lines there are errors.
Copy the whole line, including the file name and line number, and paste it as text. Do not retype it or paraphrase it. Small details, such as a variable name, point straight to the cause. If there are several red lines, the first one is usually the real problem and the rest are consequences.
Send the current code
Assistants do not see your file unless you paste it. If you fix a bug in your head from an older version of the code, the suggested change may not match what is on your disk. Paste the whole current file for small projects. For larger files, paste the relevant section and say which file it is from.
Also say what you changed since the last working version, if anything. Many bugs come from the most recent edit, and knowing which one narrows the search.
Ask for the smallest fix
State the limit in the request: “Fix only this bug. Do not change anything else. Show me the lines that change and explain why.” That last part is useful. A fix with a reason lets you judge whether it makes sense.
Avoid asking the assistant to “clean up” or “improve” the code while fixing a bug. Extra changes make it hard to tell what caused any new problem. Do those as separate requests later.
If the assistant returns a full rewritten file, compare it with your saved copy using a free diff tool, or ask: “List every change you made compared with my version.” Unrequested changes are a warning sign.
Confirm the fix and watch for regressions
After you apply the fix, run the exact steps from your report. The result should now match what you expected. Then test the things that worked before: if you fixed rounding, check a whole-number bill and a bill with many decimals; if you fixed a button, click the others.
Keep your list of test cases in a notes file and run it after every fix. This habit catches regressions, which are new bugs caused by fixing an old one. It takes a minute and prevents the most frustrating kind of problem, the one that appears days later with no obvious cause.
If the fix fails, do not just say “still broken.” Report the new result with numbers, as you did the first time. Often the result changed, and the change is a clue.
Check whether it is really a bug
Sometimes the code does what you asked, and the surprise comes from the request. Before you report a bug, reread your original prompt. Did you say what should happen in this case? If not, the behavior may be reasonable but unwanted, and the right message is a new requirement: “When the list is empty, show the text ‘Nothing here yet’ instead of a blank space.”
Telling the difference matters, because the fix for a missing requirement is a clear description, not a repair. It also keeps you from blaming the assistant for something you never specified, which makes the next prompt better.
When the same bug survives several tries
If three attempts do not work, stop and change approach. Options include:
- Ask the assistant to explain how the relevant part of the code works, step by step, before proposing another fix.
- Ask it to add temporary messages that print the values at each step, so you can see where they go wrong.
- Start a fresh conversation, paste the code and the report, and describe only the current state.
- Revert to your last working version and redo the latest change more carefully.
Long conversations can accumulate confusion. A clean restart with a clear report is often faster than a fourth patch.
Next steps
Pick a bug you have seen in a project, or create one by editing a working file, and practice the three-part report. Write the steps, expected result and actual result with numbers, paste the error text, and ask for the smallest fix. Run your test list afterward and note whether the fix was clean. Save the best report in your notes file as a pattern to copy next time.