I stopped asking an AI agent to “fix the bug” and started asking it to reproduce it first
I noticed a small problem in my debugging workflow with AI agents.

When something broke, my first instinct was:
“Find the bug and fix it.”
The agent would usually do exactly that.
Sometimes it worked.
But occasionally it would make a plausible change without actually understanding what triggered the failure.
So I changed the order.
Now my first request is:
“Reproduce the failure before changing anything.”
I ask the agent to:
identify the exact failing scenario
reproduce it locally
show the expected vs actual behavior
identify the smallest failing case
explain what it thinks is happening
only then propose a fix
That extra step has been useful because it separates:
“I found some code that looks suspicious”
from:
“I can actually reproduce the problem this code causes.”
It also catches a second problem: sometimes the reported bug isn't actually a bug in the code being inspected. The reproduction exposes that the real issue is somewhere else entirely.
My current flow is becoming:
Reproduce → Understand → Plan → Fix → Verify
rather than:
Error → Fix → Hope
I'm curious what other people are doing with AI debugging agents.
Do you make the agent reproduce a bug before allowing it to modify the code, or do you usually let it investigate and fix in the same pass?
Replies
i like the approach because reproduction forces the agent to earn confidence before touching the code. I would also make the reproduction test part of the final fix verification.
@advin_jadis I agree. That’s actually a useful addition to the workflow.
The reproduction shouldn't just be a debugging step — it can become part of the verification process too.
So the flow becomes:
Reproduce → Understand → Plan → Fix → Reproduce again → Verify
That second reproduction matters because otherwise it's easy for an agent to say "fixed" simply because the code changed without proving the original failure is actually gone.
I think that small distinction is especially important with AI agents: a plausible fix isn't the same as a verified fix.
I have found reproduction especially useful when the error message points in the wrong direction. It gives the agent evidence to work from instead of assumptions.
I started doing something similar with tricky bugs. Reproduction gives me much more confidence in the fix, especially when the agent suggests changes across multiple files.
Yes, but with one guardrail that took me a while to learn: make it write the failing case before it reads the buggy code, and make it show you the test failing. Otherwise you get a reproduction that was quietly written to match whatever the code does today. It looks like evidence, it passes review, and it locks the bug in as expected behavior. An agent that has already seen the implementation will write an assertion that agrees with it almost every time.
The other thing reproduction buys you is a decision you didn't know you had. Once you're down to the smallest failing case, a decent share of "bugs" turn out to be nobody's fault, the code does exactly what it was asked to do and the ask was wrong. That's not a fix, that's a product conversation, and Error to Fix to Hope skips straight past it. You only see it because the small case is small enough to argue about.
Where I don't do this: anything I can eyeball in ten seconds. Reproduce first is a real tax, and paying it on a typo or an off by one just teaches you to stop paying it on the ones that matter. Cheap and obvious goes straight to the fix, everything else earns the full loop.
I have started asking agents for evidence before solutions too. Reproduction helps seperate real root causes from guesses and makes the debugging process much more predictable.