Escape an AI debugging loop

A debugging loop is not simply “many prompts”. Several attempts can be rational when each one tests a new explanation. The loop begins when code keeps changing but the team is not accumulating evidence: the same failure returns, the latest patch is based on a rewritten guess, and nobody can say what the previous change was supposed to prove.

The way out is to reduce output and restore the scientific shape of debugging. Establish a reproducible failure. Name one explanation. Run a test that distinguishes that explanation from an alternative. Record the observation. Then decide whether to continue, revert, gather new context, or involve another person.

The strongest signal is explanatory drift. The assistant offers a different cause after each failure without reconciling it with earlier observations. Changes accumulate in unrelated files. A previously passing path is modified because it is nearby. The current code no longer has a known baseline, so a new error cannot be tied to a specific attempt.

Another signal is loss of the testable failure. The conversation says “still broken”, but the exact input, environment, expected output, and actual output are missing. Screenshots and summaries replace a command or fixture that another developer can run. Without a stable reproduction, the model is optimizing against a moving verbal description.

A third signal is that you cannot answer three questions: what hypothesis did the last change test; what result did you observe; why does the next change follow from it? If the answer is “the model said this should work”, pause. That is a proposal, not evidence.

None of these signs imply a universal limit such as three prompts or 30 minutes. Complexity, model behavior, test quality, and domain knowledge vary. Use the quality of the evidence, not a magic attempt count, to decide when the approach has stalled.

Revert or isolate speculative changes until you have a state you understand. Preserve useful work in a safe branch or patch according to your team process, but do not keep stacking generated modifications onto an unknown baseline. Record the revision and environment in which the failure occurs.

Describe the failure as an observation: given this input and state, the system produced this output, while the requirement says it should produce that output. Add the smallest automated test you can trust, or a repeatable manual sequence when automation is not yet practical. Include negative and control cases so a fix cannot satisfy the test by disabling the whole feature.

If the failure cannot be reproduced, that becomes the investigation. Compare environment, data, timing, permissions, flags, and revisions. Do not ask for a production fix to a condition you cannot yet describe. The completed outcome for this session may be a reproduction recipe rather than corrected code.

A hypothesis should explain the observation and predict what another check will show. “The filter is broken” is a restatement. “The empty query is treated as a missing value and returns an empty collection” predicts that the filtering function will fail only for the empty-string case while non-empty matches still work.

Choose a test that could disprove the hypothesis. Inspecting the same log again or asking the model whether it agrees adds little. A unit test with an empty query, a breakpoint before the early return, or a controlled call to the underlying function creates an observation. Decide in advance what result supports or rejects the explanation.

Change one causal variable when possible. Large generated patches often mix a fix, refactor, rename, and new abstraction. Even if the tests turn green, you do not know which part mattered or which unrelated behavior changed. Ask for the smallest patch consistent with the current hypothesis, then inspect it yourself.

The example is intentionally small and illustrative. It demonstrates the shape of the reasoning, not a claim about a real customer incident. The observation rejects broad theories about rendering or server data and narrows the next change to one branch.

If the UI still fails after the helper test passes, do not ask for a combined rewrite. Preserve the helper result and form a new hypothesis about integration state, normalization, or rendering. Each checkpoint should carry forward what the previous one established.

Continue when the observation supports a clear next test or a small fix. Revert when a speculative change did not test the hypothesis, introduced new failures, or made the baseline less understandable. Gather context when the requirement, environment, or system boundary is unknown. Escalate when risk or missing expertise exceeds what the current reviewer can responsibly decide.

Starting a new AI conversation can be appropriate when the existing context contains contradictory attempts or too much irrelevant output. First create a clean handoff: exact reproduction, expected and actual behavior, constraints, tested hypotheses, rejected explanations, and current revision. A blank chat without that package is not a reset of the engineering problem.

Taking a break can also be a technical decision. A developer in one saved Reddit discussion described hours spent without progress and a clearer approach after stepping away. That is a personal account, not proof of a universal effect. The transferable rule is narrower: if attention no longer distinguishes evidence from activity, stop opening new loops and leave a restartable record.

Select Debug mode. Write the current hypothesis as the goal and the required observation as “done when”. The example button uses 25 minutes to make the first checkpoint easy to start; choose a longer interval when reproducing a state-heavy or distributed failure genuinely requires it.

When the timer ends, finish the smallest operation already in flight and record the observation. The outcome can be “partly” or “no” without wasting the session. Rejecting a hypothesis, identifying a missing requirement, or creating a stable reproduction changes the next decision and therefore counts as useful debugging work.

Park the next action in language that begins the following session: “run the empty-query fixture through the UI adapter”, not “keep debugging”. The record is entered by you. NEDIO does not inspect the code or know whether the test result is accurate.

A bounded session does not improve a model's reasoning, expand its context window, repair missing training knowledge, or guarantee a correct patch. It cannot replace logs, tests, observability, version control, domain expertise, security review, or production safeguards. It only makes the human debugging contract and handoff easier to see.

Some failures need another person, a vendor, a minimal reproduction outside the application, or access to an environment you do not have. Do not turn focus discipline into a reason to keep working alone. Record what you established and ask for the missing capability with a concrete evidence package.

The aim is not fewer prompts as a vanity metric. The aim is for each change to follow from an observation and for each checkpoint to leave the next decision clearer than before. If another tool or a plain text file does that with less friction, use it.