diagnosing-bugs

Non-deterministic bugs require raising the reproduction rate rather than finding a clean repro. Loop the trigger 100 times, parallelize, add stress, narrow timing windows, or inject sleeps until the failure rate is high enough to debug against.

Build a tight feedback loop first: a failing test, curl script, CLI invocation, or headless browser script that goes red on the exact reported symptom. Then minimize the repro by removing inputs and steps one at a time until every remaining element is load-bearing.

A good debugging hypothesis is falsifiable and states a concrete prediction, such as: if X is the cause, then changing Y will make the bug disappear. Generate 3-5 ranked hypotheses before testing any of them to avoid anchoring on the first plausible idea.

No. Without a red-capable feedback loop, hypothesizing is guessing. Stop, list what you tried, and ask the user for environment access, a redacted captured artifact like a HAR file or log dump, or permission to add temporary production instrumentation.

For performance regressions, logs are usually the wrong tool. Establish a baseline measurement with a timing harness, profiler, or query plan, then bisect between known states. Measure first, fix second.

Write the regression test before the fix, but only if a correct seam exists where the test exercises the real bug pattern as it occurs at the call site. If no correct seam exists, document that architectural gap as a finding itself.