The first explanation of a bug is often only a story that fits the visible symptom. An assistant can help generate alternatives, but you need observations that distinguish them. Preserve the failing case before changing the code that produces it.
Describe the observation
Capture the input, expected output, actual output, and relevant environment. Note whether the failure is repeatable. “The page is broken” invites speculation; “the second save returns a conflict after the first succeeds” gives the investigation a boundary.
Keep competing hypotheses
| Hypothesis | A distinguishing observation |
|---|---|
| The client sends stale state | Compare the versions in consecutive requests. |
| The server increments twice | Trace writes for one request identifier. |
| The retry repeats a successful write | Check whether two attempts share an operation key. |
Ask for the next useful check
Have the assistant suggest the smallest observation that separates the leading explanations. Inspect the proposed command before running it. Prefer read-only traces or a disposable reproduction while the cause is uncertain, and avoid including credentials in diagnostic output.
Fix the cause you can demonstrate
Once the evidence supports a cause, make a bounded change and replay the original failure. Check a nearby successful case as well. End with a brief explanation of why the symptom occurred and what evidence rules out the most plausible alternative.
