Start Debugging with 'What Could Cause This?' Instead of 'Fix This'
When something breaks, the instinct is to paste the error and say "fix this." It works, but you'll get a better fix if you slow down by one prompt.
I'm getting a 419 CSRF token mismatch on form submission,
but only after the user has been idle for a while.
What could cause this?
Claude will generate a list of possible causes — expired session, misconfigured token lifetime, missing meta tag, caching a page with a stale token — ranked by likelihood for your stack. This is where the real value is: you see the landscape of possibilities before committing to a fix.
Once you've scanned the list, direct Claude to the most likely culprit:
It's probably the session lifetime. Show me the relevant config
and suggest a fix that handles idle users gracefully.
This two-step approach pays off in a few ways:
- You learn why it broke, not just how to silence the error.
- Claude considers edge cases it wouldn't surface in a "just fix it" response.
- You avoid the wrong fix — patching a symptom while the real issue lurks underneath.
- It builds your debugging intuition over time by exposing you to root causes you hadn't considered.
This works especially well for intermittent bugs, race conditions, or errors that only appear in production. The more mysterious the bug, the more you benefit from diagnosis before prescription.
"Fix this" gives you a patch. "What could cause this?" gives you understanding.
via Claude Code
Log in to leave a comment.
When a page takes five seconds to load or an API endpoint times out under load, tell Claude which route is slow and it traces the entire code path — controller, services, queries, loops — identifying N+1 queries, redundant computations, missing indexes, and cacheable operations, then fixes each bottleneck.
Flaky tests are maddening — they pass locally, fail in CI, pass again when you retry. Tell Claude to read the test, identify the source of non-determinism — timing issues, shared state, date dependencies, or order-dependent setup — and fix the root cause so the test is reliably green or reliably red.
When your app throws an error, don't just Google the message — paste the full stack trace into Claude Code. It reads the trace, opens the referenced files in your codebase, follows the call chain, and pinpoints the actual root cause instead of just explaining the symptom.