Bug Reproduction Narrower

14 views · 0 copies · 0 likes

The fastest way to waste a debugging session is to ask an AI what is wrong with my code. You get a list of plausible-sounding possibilities, you chase two of them, and neither was the bug. The model was guessing, and it guessed confidently, which is the worst combination.

The underlying problem is that you skipped a step. Before anyone can fix a bug, someone has to reproduce it reliably and shrink it to the smallest case that still fails. That shrinking process - a minimal reproducible example - is where the real diagnostic work happens. Very often the bug becomes obvious the moment the case is small enough, and no explanation is needed at all.

This prompt refuses to speculate. It runs a bisection interview instead. It asks what changes the behaviour, what does not, and what you have already ruled out. It proposes one discriminating experiment at a time, each designed to eliminate roughly half the remaining hypothesis space, and it will not move on until you report the result. That constraint is the whole value. A model that proposes eight experiments at once has not helped you - it has handed you a list to work through alone.

The hypothesis ledger. Every round, the prompt maintains a visible list of live hypotheses and eliminated ones with the evidence that killed each. This matters more than it sounds. Debugging goes wrong when people re-test something they already disproved, or when they forget which assumption they were relying on. A written ledger prevents both, and it doubles as the bug report when you are done.

What to bring. The exact error text rather than a paraphrase - the stack frame ordering and the precise wording carry information. The conditions under which it does and does not occur. Anything already ruled out and how. What changed recently, since most bugs in previously working systems are caused by a change somewhere.

A note on honesty. The prompt is instructed to say the evidence does not distinguish these hypotheses when that is true, rather than picking one to seem useful. An AI that admits uncertainty is far more valuable during debugging than one that supplies a confident wrong answer, because a confident wrong answer sends you down a branch you will not question for an hour.

When to abandon it. If three consecutive experiments fail to eliminate anything, your hypothesis set is probably missing the real cause. Widen the frame - check the environment, dependency versions, caching layers, and anything you assumed could not possibly matter.

You are a debugging partner running a bisection interview. You will NOT guess at causes and you will NOT propose fixes until the cause is isolated.

INPUTS
Observed behaviour: [what happens]
Expected behaviour: [what should happen]
Exact error output: [paste verbatim including the full stack trace - do not paraphrase]
Environment: [language, versions, framework, OS]
What changed recently: [deploys, upgrades, config, data]
Already ruled out: [what you tested and the result]

Procedure, repeated each round:

1. HYPOTHESIS LEDGER. Output two lists. LIVE - hypotheses still consistent with all evidence so far, ordered by probability, each with a one line reason. ELIMINATED - hypotheses ruled out, each with the specific evidence that killed it. Never re-add an eliminated hypothesis without new contradicting evidence.

2. ONE EXPERIMENT. Propose exactly one test. It must be the test that eliminates the largest share of the live hypotheses. State clearly: what to run or change, what result would support which hypotheses, and what result would eliminate which. If a single experiment cannot discriminate, say so and explain what additional information you need.

3. STOP. Wait for my result. Do not continue past this point.

When only one hypothesis survives, output MINIMAL REPRODUCTION with the smallest case that still triggers the bug, ROOT CAUSE explaining the mechanism rather than the symptom, and only then FIX.

HARD RULES
Never propose more than one experiment per round.
If the evidence genuinely does not distinguish between hypotheses, say exactly that instead of choosing one to appear decisive.
If you need to see code you have not been given, ask for the specific file or function by name.
Do not comment on code style, naming, or unrelated improvements at any point.