Debugging becomes expensive when every theory produces a new edit. AI can make that pattern worse by generating plausible fixes faster than you can evaluate them. An evidence-first workflow reverses the order: reproduce the failure, narrow its location, test one theory, and only then change production code.
Write a precise reproduction
Record the starting state, exact actions, expected result, actual result, environment, and frequency. Replace ‘the form does not work’ with ‘after a valid submission on mobile Safari, the button remains disabled and no request appears in the network panel.’ Precision eliminates whole categories of causes and gives the assistant something falsifiable.
Collect the earliest useful evidence
Start with the first console error, failed network request, unexpected variable, or server log entry—not the last visible symptom. Capture status codes, response bodies that are safe to share, stack locations, and the smallest relevant code. Avoid sending secrets, personal data, or an entire log when a focused excerpt answers the question.
Ask for ranked hypotheses
Ask the assistant to rank likely causes and identify the evidence that would distinguish them. A strong response says, for example, ‘If the click handler is not attached, this log will be absent; if validation returns early, this value will be false.’ This is more useful than a patch because it turns uncertainty into a sequence of checks.
Create a minimal experiment
Change one observation point at a time: add a temporary log, call a function with a fixed input, replace a remote response with a known fixture, or isolate the component in a small page. The experiment should prove or reject one hypothesis. Remove diagnostic code after the result is understood.
Fix the cause and protect the boundary
A useful fix addresses why the invalid state became possible. If a request can return missing data, validate the response where it enters the system rather than scattering optional checks throughout the interface. Add an error state that helps the user recover and a test that recreates the original failure.
Build a debugging journal
For difficult problems, keep the symptom, evidence, rejected hypotheses, root cause, fix, and prevention. Patterns quickly emerge: timing assumptions, inconsistent field names, duplicated listeners, stale caches, or server permissions. The journal becomes project-specific context you can reuse with an AI assistant and a training resource for future work.