Say "Explain What You Just Did" to Understand Claude's Reasoning Behind Its Changes
Claude doesn't just write code — it makes dozens of design decisions along the way. When you don't understand why it chose a particular approach, ask it to explain. The explanation is often more valuable than the code itself.
> [Claude just refactored your auth middleware]
> explain what you just changed and why you made those specific choices
Claude walks you through each decision — why it extracted a method, why it chose this validation approach over another, why it moved the authorization check to this layer instead of that one. You learn the reasoning, not just the result.
This is especially useful when Claude does something unexpected:
> why did you add that index on the created_at column?
> why did you use a service class here instead of putting the
> logic in the controller?
> I noticed you used a different approach than what I expected —
> why reduce instead of a foreach loop?
> why did you move the validation out of the controller and into
> a form request?
Claude explains the tradeoff — "I used a form request because it keeps the controller thin and the validation rules are reusable across the create and update endpoints" — giving you context you can apply to future decisions.
This works as a teaching tool for unfamiliar patterns:
> I've never seen this pattern before — explain the closure
> you used in the query scope and when this is useful
> why did you use a DTO here? I usually just pass arrays around
Over time, asking Claude to explain its reasoning builds your own intuition. You start recognizing when to extract a service, when an index matters, and why certain patterns exist — all through your own code, not textbook examples.
Every explanation from Claude is a micro-lesson. Ask "why" often enough and the patterns become your own.
via Claude Code
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.
Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.
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.