Ask "Why Did This Fail?" Instead of "Fix This Error"
When Claude gives you code that is close but not quite right, your instinct is to paste the error and say "fix this." Resist it.
Instead, paste the error message and ask:
Why did this fail?
The difference is subtle but powerful. When you ask Claude to fix something, it often guesses at a solution and patches over the symptom. When you ask it why something failed, it actually reads the error, traces the root cause, and explains what went wrong before proposing a fix.
This small shift in phrasing moves Claude from "reactive patch mode" into "diagnostic mode." You get a better explanation, a more targeted fix, and you learn something about the bug in the process.
It works even better when you add context:
This test was passing before I added the new middleware.
Why did this fail?
[paste error output]
The "why" framing also prevents the frustrating loop where Claude applies a fix, introduces a new error, fixes that, and so on. By understanding the root cause first, it usually gets the fix right in one shot.
Stop asking for band-aids. Ask for a diagnosis.
via @melonmuskovich
Log in to leave a comment.
Before jumping to implementation, describe the problem conversationally and let Claude be your thinking partner. It asks clarifying questions, surfaces tradeoffs you haven't considered, suggests approaches, and pokes holes in your plan — so by the time you say "ok, build it," both of you know exactly what to build and why.
When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.
After Claude makes changes to your code, ask it to explain what it did and why it made specific choices. This turns every coding task into a learning opportunity — you understand the reasoning behind the approach, learn patterns you can apply yourself, and catch any decisions you disagree with before moving on.