8.3 When the model suggests nonsense: how to recover fast
Overview and links for this section of the guide.
On this page
How to recognize “nonsense” quickly
“Nonsense” doesn’t mean the model is stupid. It means its suggestion is disconnected from your reality or constraints. Red flags:
- Wrong ecosystem: suggests libraries/frameworks you don’t use.
- Ignores constraints: adds dependencies after you said “no new deps.”
- Hand-wavy fixes: “just upgrade everything,” “reinstall,” “clear cache” without evidence.
- Huge rewrites: replaces multiple files to fix a small bug.
- Confident claims without support: states behavior that isn’t in the pasted code/output.
- Debugging by vibe: proposes changes without a hypothesis and a test.
Nonsense suggestions waste time and create regressions. The fastest developers learn to stop the loop immediately and reset.
Why it happens (predictable causes)
Nonsense usually has one of these causes:
- Missing context: you didn’t paste the relevant file, version, or error output.
- No constraints: the model defaults to “rewrite and improve.”
- Conflicting instructions: long conversations accumulate drift.
- Ambiguous problem statement: “it doesn’t work” invites guessing.
- Model mismatch: a fast model may be less reliable for complex debugging (see Part IV later).
The good news: all of these are fixable with process.
The reset protocol (fast recovery)
When you see nonsense, do this instead of arguing:
- Stop the current thread: “Pause. Don’t propose fixes yet.”
- Re-anchor constraints: language/runtime, deps allowed, files in scope, diff-only.
- Re-state the evidence: exact command + exact output + expected behavior.
- Force hypotheses + tests: “3 ranked hypotheses + confirming/denying tests.”
- Proceed one step: only after one hypothesis is confirmed.
Many people respond to nonsense by pasting more. Often the better move is to paste a smaller, cleaner repro + constraints.
Prompts that prevent guessing
Template: “no guessing” rule
Do not guess or propose fixes yet.
1) Summarize the problem only from the evidence I provided (no assumptions).
2) List unknowns and ask up to 5 clarifying questions.
3) Stop and wait.
Template: “show me where in the code”
Before suggesting a fix, point to the exact line(s) in the pasted code that support your hypothesis.
If you can’t, say what additional code/output you need.
Models default to confidence. Your prompts should enforce uncertainty where evidence is missing.
How to constrain scope and stop rewrites
When the model proposes a rewrite, constrain it aggressively:
- “Only edit this function in this file.”
- “Keep the diff under 50 lines.”
- “No refactors. Fix the bug only.”
- “Output diff-only changes.”
- “Implement step 1 only.”
If it still doesn’t comply, narrow further: “Change only these 5 lines.”
Most bugs don’t require a redesign. If the proposed fix is large, you either have the wrong hypothesis or the wrong scope.
How to force evidence-based debugging
Use “differential diagnosis”:
- ask for 3 hypotheses,
- for each, ask: “what would we observe if this were true?”
- run the cheapest observation first,
- discard hypotheses quickly.
This prevents spending time on plausible stories.
“How could we prove this hypothesis wrong quickly?” is often a better question than “what should we try?”