unrust

Skill guide

How do you debug code without AI?

Published

Quick answer

Debugging without AI starts by making the failure concrete: what happened, what should have happened, and what is the smallest input that shows the difference? From there, form one testable hypothesis at a time, inspect the relevant state, and change the smallest thing that can disprove or confirm it. You can use AI later for alternatives or explanation, but starting with a reproducible observation keeps you in charge of the diagnosis instead of accepting a plausible fix on faith.

Make the failure small enough to hold in your head

Saying that something is broken is not a debugging target. A useful report names the observed result, the expected result, the input, and the environment or branch that matters. Trim logs and code until the failure is still present but the noise is gone.

A small reproduction gives you a bounded system to reason about. It also makes every later suggestion, whether from a teammate, a search result, or an assistant, easier to verify.

Separate evidence from explanation

The failing test, error message, and state at a breakpoint are evidence. A stale cache is an explanation. Keep those categories separate until the explanation has earned the evidence.

This sounds fussy, but it prevents a common trap: finding a sentence that fits the symptoms and then changing code around that sentence. The code may become different without becoming correct.

Change one variable, then preserve the learning

When several possible causes exist, choose the smallest experiment that rules one out. Add one assertion, log one value at the boundary, or replace one dependency with a controlled value. A ten-file refactor is not an experiment.

After the fix, write down the signal that should have led you there earlier. That note becomes a future shortcut. The goal is not to solve the current bug heroically; it is to make the next one cheaper to understand.

A small practice loop

  1. 01Rewrite a recent bug report as observed result, expected result, smallest input, and relevant environment.
  2. 02List two hypotheses, then choose the cheapest check that could rule out one of them.
  3. 03After the fix, add or strengthen a test that would have made the faulty behavior obvious.

Common questions

Should I avoid using AI while debugging?

No. AI can be useful after you have a concrete failure and a hypothesis to test. The risk is treating a plausible explanation as evidence. Keep the reproduction and verification loop under your control.

What is the first step when a bug is hard to reproduce?

Capture the exact inputs, timing, environment, logs, and expected behavior while the evidence is available. Then remove variables until you know which part of the system still produces the failure.

Check your own starting point

Unrust uses short, timed, unassisted drills to give developers a per-skill snapshot. One session cannot explain the cause of a result, but it can show you what is worth practicing next.

Take the free diagnostic