Reproduce Before Fix
Requires a failing case you can run on demand before a single line gets changed.
When to reach for it
The moment a bug is reported and the instinct is to start reading code looking for something that looks wrong.
What changes
- The agent produces a command or a sequence of steps that fails reliably, and shows you the failure, before proposing any fix.
- 'It happens sometimes' gets turned into the exact conditions that make it happen, or reported as not yet reproducible — never guessed at.
- The reproduction becomes the check that proves the fix, so you stop taking 'should be working now' on faith.
- A change that does not flip the failing case from red to green is caught immediately, instead of shipped as a hope.
- You stop paying for speculative fixes to bugs that were actually in the caller, the data, or the environment.
Pairs with
- Read the Actual ErrorReads what the error really says — the file, the values, the chain — before matching it to a bug you have seen before.
- Bisect the ChangeFinds what broke it by halving the search space instead of touring the suspects.
- It Worked YesterdayFinds what changed when, as far as you know, nothing changed.
Reproduce Before Fix
No changes to the code until the failure can be triggered on demand.
1. Get the failure to happen
Build the smallest thing that fails: a command, a test, a script, or a written sequence of steps with real values in it. Run it, and show the actual output — the error text, the wrong number, the element that is not there.
If it will not fail for you, say so plainly and ask for what is missing: the input, the account, the browser, the timing, the data. Reading the code is not a substitute for reproducing.
2. Shrink it
Cut everything not needed to make it fail. Remove steps, fields, records and dependencies one at a time, re-running after each. The version that still fails with the least left in it usually names the bug by itself.
3. Write down what makes it happen and what does not
Both halves matter. "Fails with two or more attachments, passes with one." "Fails only when the account has no display name." The boundary between those two is where the bug lives.
4. Turn it into a check you can rerun
An automated test if the code allows one, a saved command if it does not. Confirm it fails now and that it fails for the reason you think — read the message and make sure you are not looking at a setup mistake.
5. Now fix it, and prove the fix
Make the change and run the check: it passes. Undo the change and run it again: it fails. That second step is what separates a fix from a coincidence.
Rules
- Do not change code to see whether the bug goes away. That is a search, not a diagnosis, and it leaves edits behind that nobody can justify.
- Do not settle on "cannot reproduce" while the reporter still can. Ask what is different about their run.
- Do not fix more than the failure you reproduced. Other things that look wrong nearby get their own reproduction, or get reported — not silently changed.
- Do not weaken or delete the failing check to make it pass. If the check was wrong, say so explicitly and show why.