Make Claude Give Two Hypotheses and a Deciding Test
What it is
Why it works
The first plausible cause is often not the real one, and a model asked for 'the fix' commits to whichever theory it generated first. Forcing two hypotheses breaks that anchoring, and demanding a deciding observation means you run one cheap experiment that eliminates half the space instead of shotgunning changes. It's the scientific method applied to a stack trace.
When to use it
Ambiguous bugs with more than one credible cause — intermittent failures, works-locally-breaks-in-prod, wrong output with no error, anything involving caching, concurrency, or state.
When not to use it
Bugs with one obvious cause and a stack trace pointing straight at it. Don't manufacture a second hypothesis for a missing import.
Prompt
Bug: <symptom, including where it does and doesn't happen>.
Context: <relevant code / logs>.
Give me exactly two distinct hypotheses for the cause. For each, state what it predicts we'd observe. Then name the single cheapest observation (a log, a test, a value to print) that would confirm one and rule out the other. Don't propose a fix yet — tell me what to check.Example
A feature works for you but fails for a teammate. Claude proposes (A) an env-var difference and (B) a cached build, and says: print the resolved config on startup — if it matches yours, it's the cache. One log line settles it before any code changes.
Advanced version
When neither hypothesis survives the deciding test, feed the observed result back and ask for two fresh hypotheses consistent with it. You're doing binary search over the cause space, each round cutting it roughly in half.
Common mistakes
- Accepting a fix before running the deciding observation — you're back to guessing.
- Two hypotheses that aren't actually distinguishable, so no single test separates them.
- Not telling Claude where the bug does NOT occur, which is often the most information-rich fact.