The methodology chapter is the actual book. Unix/Python/Pytorch is just where it gets stress-tested.

The rule that has saved me most: never trust the layer you are reading. A generation bug read off the decoded string is a lie, you diff the raw input_ids. A clean agent transcript hides a truncated tool-call JSON one layer down.

Does the methodology chapter cover the case where the instrumentation itself is wrong, the probe ages or the log silently drops a field, so the bug lives exactly where you stopped looking?

That distinction is the whole point. Manual debugging, you are the probe, so nothing ages or drops silently. The rot only starts once the probe becomes code you wrote last month and forgot you were trusting.

So it may not need to be an AI-specific chapter at all. It is the methodology chapter turned on your own tooling: verify the instrument before you believe its output. Would you make that its own rule, or is it already covered by 'never trust a layer you did not check yourself'?

Fair, and that filter is why the book will hold up. You only wrote down what you actually hit.

My dull tool was never dull when I picked it up. It was a sharp one that went dull under me. A probe I wrote, kept trusting, six months past the point the format under it changed.

So maybe it is not a missing practice. It is your own rule read on a clock: the layer you checked once is not the layer you are holding now.

Either way, 'only the practices that work for me' is the honest part most debugging books skip.

That last paragraph is the cleanest answer my question could get. Throwaway tooling can't age. You never hold an instrument long enough for the format under it to move.

The aging probe is only a problem for standing instrumentation, the dashboards and assertions that outlive the bug they were written for. Your workflow sidesteps it by construction: new bug, new tool, discard.

So it was never a missing chapter. It was a failure mode you designed out. Thank you, Stas, genuinely enjoyed this one.