How to Use AI to Debug Code Safely

A bug report arrives at 4 p.m. on Friday. You paste the stack trace into an assistant and, within seconds, get a patch. It makes the error go away. You ship it. On Monday you discover that the error went away because the patch quietly swallowed it, and now the wrong data is being written without any warning.

Debugging is where AI help is most tempting and where the gap between "the error disappeared" and "the bug is fixed" is widest. This article shows how to get the speed without the trap.

• A safe, step-by-step debugging workflow with an assistant.
• What to share and what never to paste.
• A worked example in which the obvious fix is wrong.
• Common "fixes" that hide bugs.
• How to treat commands that an assistant suggests you run.

Debugging is the scientific method applied to code: observe what happens, form a hypothesis about why, test it, and repeat. An assistant is very good at generating hypotheses, because it has seen countless similar bugs. It is much less reliable at knowing which one is true for your program, because it cannot run your code, see your data or know your environment (unless it is an agent that can, in which case the same caution applies to its actions).

So split the work: it proposes, you test. For a foundation in systematic debugging without AI, see How to Debug Any Bug: A Calm, Repeatable Process.

1. Reproduce. Make the bug happen reliably. If you cannot reproduce it, no assistant can help you fix it.
2. Shrink it. Cut away everything that is not needed to trigger the bug, until you have the smallest example. This often reveals the cause by itself.
3. Write down expected versus actual. "I expected 35. I got 25."
4. Prepare a safe, minimal share (see below).
5. Ask for hypotheses, ranked, with a test for each, not a patch.
6. Test the hypotheses yourself: a log line, a debugger, a unit test, a print.
7. Ask for the smallest fix for the confirmed cause.
8. Review the diff (see the symptom-hiding list).
9. Add a regression test that fails before the fix and passes after.
10. Explain the bug in a sentence. If you cannot, you have not finished.

A prompt for step 5:

I have a bug. Expected: average_of_last([10, 20, 30, 40], 0) should not returna number, since there is nothing to average. Actual: it returns 25.0.Python 3.11. Code: [paste function].Do not give me a fix yet. List the three most likely causes in order oflikelihood, and for each give one quick way I can test whether it is the cause.

Asking for causes and tests keeps you in control, and it works well because the assistant's strength (breadth of experience) is used while its weakness (not seeing your runtime) is routed around.

The function. It should return the average of the last n values of a list.

# File: last_n_average.pydef average_of_last(values, n):    """Return the average of the last n values (buggy first version)."""    window = values[-n:]    return sum(window) / len(window)def average_of_last_fixed(values, n):    """Return the average of the last n values, or None when there is nothing to average."""    if n <= 0 or not values:        return None    window = values[-n:]    return sum(window) / len(window)scores = [10, 20, 30, 40]print("n=2 buggy:", average_of_last(scores, 2))print("n=0 buggy:", average_of_last(scores, 0))print("n=2 fixed:", average_of_last_fixed(scores, 2))print("n=0 fixed:", average_of_last_fixed(scores, 0))print("empty fixed:", average_of_last_fixed([], 3))

n=2 buggy: 35.0n=0 buggy: 25.0n=2 fixed: 35.0n=0 fixed: Noneempty fixed: None

The symptom. average_of_last(scores, 0) returns 25.0, which is the average of all the values. A user reported "my chart shows an average when I selected zero days".

What a hurried assistant might suggest (illustrative): "Wrap the function in a try/except and return 0 on error", or "add if n == 0: return 0."

Why those are wrong. Neither explains the cause. The real cause: in Python, values[-0:] is the same as values[0:], because -0 equals 0, so the slice starts at the beginning and returns the whole list. The code never failed, so a try/except does nothing. And return 0 invents a number: an average of nothing is not zero.

Hypothesis testing. Quick checks confirm it: print values[-0:] and values[-2:] and compare. Cause confirmed.

The fix and its design decision. The fixed function returns None for "nothing to average", so callers can tell it from a real average of 0. Whether to return None, raise an error or return 0 is a design decision that depends on the callers, not something the assistant can decide for you. In the output above, the fixed version gives 35.0 for n=2 as before, and None for both n=0 and an empty list.

Regression test. Add tests such as: n=2 gives 35.0, n=0 gives None, an empty list gives None, n larger than the list length uses all values. Verify that the n=0 test fails on the old code and passes on the new.

Understanding. One sentence: "A negative-zero slice index starts at the beginning, so n=0 returned the whole list." You could now spot this class of bug elsewhere.

Debugging prompts tend to contain the most sensitive material, because errors reveal internals.

Never paste, into any tool not approved for it:

• Passwords, API keys, tokens, private keys, connection strings, .env files.
• Customer data, personal data, production database contents.
• Proprietary source code, if your employer does not allow it.
• Stack traces and logs that include internal hostnames, user emails or file paths you should not expose.

What to do instead:

• Redact. Replace secrets and identifiers with placeholders (<API_KEY>, user@example.com).
• Minimise. Share the smallest function and the error, not the whole repository.
• Use a made-up reproduction. Often you can recreate the bug with fake data.
• If you ever paste a real secret by accident, treat it as exposed: rotate it (create a new one and disable the old) and tell your security contact if you have one.

Privacy and Security covers this in more detail.

Review every proposed change against this list:

Ask yourself after reading the diff: "Does this change the cause, or only what I see?"

Assistants will sometimes tell you to run shell commands, change permissions or reinstall packages. Before running anything:

• Understand it. Ask for an explanation of each part, and check it in the official documentation of the tool.
• Be wary of destructive or broad commands: deleting files, force-pushing, changing permissions recursively, running scripts downloaded and piped straight into a shell, disabling security features.
• Work on a branch or copy, with version control and backups, so you can undo.
• Prefer the smallest scope (one folder, one file, a dry run if the tool offers it).

If you use an agent mode that runs commands for you, set the permissions narrowly, require approval for risky actions and review what it ran. Module 8 returns to this.

If you have tried three fixes and the problem persists:

1. Stop and restate the problem in two sentences with expected versus actual behaviour.
2. Start a new conversation with the cleaned-up minimal reproduction, because the old thread may be cluttered by failed ideas.
3. Ask it to explain the code before fixing it. If the explanation is wrong, you have found the misunderstanding.
4. Question your own assumptions. Is the input what you think? Is it the code you think is running?
5. Take a break or ask a colleague. A person who sees the problem fresh often finds it quickly.

Concurrency problems, performance regressions and memory leaks are hard to guess at. Do not accept a confident diagnosis. Collect evidence with profilers, logs, traces and benchmarks, and give those results to the assistant.

• Pasting the error and applying the first patch.
• Skipping the reproduction and then not knowing if the fix worked.
• Pasting secrets or proprietary code.
• Accepting a fix you cannot explain.
• Not adding a regression test.
• Letting the assistant widen the change to "clean up" unrelated code.
• Running unfamiliar commands on a machine or data you cannot restore.

Bug: parse_price("Rs 1,200") returns 1, but I expect 1200. Python 3.11. Code:[paste the function]. Other inputs: "Rs 500" returns 500 (correct), "1200" returns1200 (correct).Do not give me a fix. List the three most likely causes, ordered by likelihoodgiven these inputs, and for each give one quick test (a print statement or a smallcall) that would confirm or rule it out.

File "/path/to/project/payments.py", line 88, in charge:requests.post("https://<internal-api-host>/v2/charge?key=<API_KEY>", json=card)

• Next: Testing, Reviewing and Refactoring AI-Generated Code shows how to test code you did not write.
• For the security side of fixes, see Security and Licensing Risks of AI-Generated Code.
• For what to paste and what not to, see Privacy and Security: What Not to Paste, Connected Tools and Prompt Injection.