# Debugging with AI: reproduce, give evidence and verify the cause

> To debug with AI, reproduce the error, give concrete evidence and ask for a hypothesis before touching code. Learn how to check that the fix is real.

*Tags: ai, debugging, quality, ux-for-ai*

---


> [!info] Quick Definition
> **Debugging with AI** means using an assistant to find the cause of an error, with a method: reproduce the failure, give concrete evidence, ask for a hypothesis, apply the smallest possible change and verify that the failure is gone.


## Why does the AI patch symptoms?

When an agent cannot run the failing command, it works from a description of the problem and tends to propose a plausible fix where the error seems to be. It looks right, but the error reappears somewhere else. The problem is not the tool's intelligence but the lack of evidence. The rule that comes out of the guides consulted is that no repair should be accepted until the failure can be reproduced ([Verdent, how to fix bugs with an AI coding agent](https://www.verdent.ai/guides/answers/fix-bugs-ai-coding-agent)).

## What evidence should you give?

Useful evidence is concrete. The most helpful items are:

| Evidence | What it is for |
|---|---|
| Full trace or the exact error message | Locates the file and the line |
| Failing test, with expected and actual results | Gives a pass or fail criterion |
| Recent changes (Git diff) | Helps find regressions |
| API or network response | Useful for integration errors |
| Screenshot | Useful for visual errors, not for logic |

What does not help: "fix the bug". The AI will have to guess which bug, and what "fixed" means.

## The method in six steps

A practical guide to AI-assisted debugging proposes this flow, which works in any tool ([WebReference, AI-assisted debugging](https://webreference.com/ai/building/ai-assisted-debugging/)):

1. **Reproduce the failure.** Write down the steps and the exact result.
2. **Copy the evidence.** Trace, message, failing test.
3. **Ask for a hypothesis.** The AI should say what it thinks causes the error and why, before editing.
4. **Apply a minimal patch.** Only in the files the hypothesis points to, and ask for the list of files before it edits.
5. **Rerun the failing command.** A fix is not proven until that command passes.
6. **Review the diff.** A person reads the change before accepting it.

Verdent's guide adds something useful: turn the reproduction into an automated test and choose the smallest patch that targets the root cause. That way the failure is documented and does not return later.

## Signs of a bad fix

Some shortcuts make the test pass without solving anything:

- Silencing the exception with an empty `try` block.
- Weakening validation so the case no longer fails.
- Deleting or marking as skipped the test that fails.
- Adding retries without explaining why the first attempt fails.
- Mixing the fix with refactors of unrelated code.
- Fixing only the spot where the error shows up, without checking other places that start from the same faulty assumption.

If the agent reports "fixed" without giving the root cause, the changed files and the tests it ran, ask for that report before accepting. The same rhythm of small changes is described in [[iterating-with-prompts|iterating with prompts]].

## How do you give the AI a way to verify?

Claude Code's documentation frames it like this: if the AI has no check it can run, the person reviewing becomes the verification loop, and every error waits for them to spot it. A check can be a test suite, a build's exit code, a linter, a script that compares output against an expected result or, for an interface, a screenshot compared against the design. With a signal like that, the agent works, runs the check, reads the result and repeats until it passes ([Anthropic, Best practices for Claude Code](https://code.claude.com/docs/en/best-practices)). If you have no written tests, the minimal equivalent is a concrete case with an input and an expected result, like the one in the example below.

## What should not be delegated?

Errors that depend on timing, such as race conditions or failures that appear one time in ten, need logs and profiles before any guess. Production incidents and security vulnerabilities also need a person in charge. AI can help summarize logs or review a checklist, but it should not decide the fix on its own. If the code belongs to someone else and you do not understand it, start with [[reading-code-without-coding|reading code without knowing how to program]]. The general criteria are in [[when-not-to-vibe-code|when not to vibe code]].

Verdent also recommends a rollback plan when the fix touches data, migrations, concurrency, permissions or external services, and starting the agent's work on an isolated branch without production credentials. If the change affects error handling, retries, transactions or security, a person should review it separately.

## Example

Illustrative example: a site's contact form fails only when the phone field has spaces. The designer copies the error message and the exact case ("'+34 600 123 456' fails, '+34600123456' passes"). The designer asks the AI for its hypothesis before touching anything. The AI says the validation compares against a pattern that does not allow spaces, and lists the two files it would change. The designer accepts the change only in the validation, reruns the test with both formats and reviews the diff. They did not accept a `try` block that hides the error.

## How to apply it tomorrow

1. Keep a bug report template in your project with five fields: what you did, what you expected, what happened, the exact message and how to reproduce it.
2. When an agent tells you it is "done", ask for the full report: root cause, changed files, tests it ran and what it could not reproduce.
3. Before accepting, rerun the failing case with your own data, not with the data the agent used.
4. Turn each reproduced error into an automated test. The next time someone changes that part, the test will warn before the user does.

This habit costs minutes and avoids arguing about the same bug three months later.

## Common mistakes

- Asking "fix the bug" without evidence.
- Accepting a fix that nobody reproduced.
- Letting the AI refactor while it investigates.
- Giving several bugs in one prompt.
- Trusting "it's fixed" without rerunning the test.
- Delegating a production incident or a vulnerability to AI without human review.

## Sources

- WebReference, "AI-Assisted Debugging": [https://webreference.com/ai/building/ai-assisted-debugging/](https://webreference.com/ai/building/ai-assisted-debugging/)
- Verdent, "How to fix bugs with an AI coding agent": [https://www.verdent.ai/guides/answers/fix-bugs-ai-coding-agent](https://www.verdent.ai/guides/answers/fix-bugs-ai-coding-agent)
- Anthropic, "Best practices for Claude Code" (giving verification criteria and evidence instead of trusting "looks done"): [https://code.claude.com/docs/en/best-practices](https://code.claude.com/docs/en/best-practices)


---

Source: https://www.fernandoux.com/en/wiki/ai/debugging-with-ai/