// blog / prompt patterns
A senior-engineer debugging prompt: the minimal-blast-radius pattern
The default failure mode of AI debugging isn't a wrong fix. It's a correct fix wrapped in a rewrite you didn't ask for.
The over-rewrite problem
Hand a model a bug and a file, and it often returns the file reorganized: the bug fixed, plus renamed variables, restructured branches, and three "improvements" — each an unreviewed behavior change. Junior-engineer energy: eager, fast, and expensive to review. The prompt fix mirrors how senior engineers actually work, and it's two structural moves, not a personality instruction.
The two moves
Move 1: split diagnosis from repair, and gate the second on the first. The prompt demands a named root cause — one sentence: what happens, under which input or state, and why — before any fix is proposed. If the evidence can't support certainty, the model must say which single observation (a log line, a breakpoint) would confirm it, instead of guessing silently. This kills the "shotgun fix" that patches five suspects at once.
Move 2: cap the blast radius explicitly."Propose the smallest safe change that fixes the root cause. Preserve every current behavior except the bug. State what your fix does NOT change." That last sentence is the sleeper — forcing the model to enumerate what stays untouched makes drive-by refactors visible before they happen. Anything bigger gets noted as a separate follow-up, not bundled.
ple get root-cause-analysis \
--var error_and_logs="$(tail -n 80 app.log)" \
--var code="$(cat src/worker.ts)" | claude -pThe full prompt is public and versioned: root-cause-analysis. Its sibling error-handling-audit hunts the opposite problem — the places where errors disappear silently — with a checklist and a 1-10 score, because numeric judgments beat adjectives at forcing honest output.
One session habit that compounds it
Anthropic's Claude Code guidance pairs naturally with this pattern: after two failed corrections, stop pushing the session and restart with a better prompt — a clean session with a better prompt almost always wins over a long session of accumulated corrections. "Better prompt" is doing the real work in that sentence. When your debugging prompt is versioned, every frustrating session has a productive exit: encode what you learned as v(n+1), restart sharp, and the history remembers it forever.