I use Claude Code for almost everything now. But there are specific situations where I've learned to close the session and think the problem through myself before involving Claude.
When you don't understand the problem yet
If you can't state the problem clearly in a sentence, you're not ready to ask Claude for a solution. You'll get a confident answer to the wrong question.
Spend five minutes writing down exactly what you're trying to do and why. If you can't do that, the problem is still at the understanding stage, not the implementation stage. Claude isn't helpful at the understanding stage — it will fill in the gaps with plausible assumptions that may be wrong.
When the answer matters more than the speed
Claude gives you the fast path. The fast path isn't always the right path.
For irreversible decisions — data model choices, API contracts you'll live with for years, security architecture — take the time to reason through it yourself first. Use Claude as a check on your thinking, not as a replacement for it.
The ratio I've settled on: think for 20 minutes on important decisions, then use Claude to stress-test the result.
When you keep getting the wrong answer in a loop
If you've iterated on a problem with Claude three or four times and you're not converging on something that works, stop. Claude is pattern-matching on your prompts, and if your framing of the problem is wrong, more iterations make it worse.
Take the problem back to first principles. Write down what you actually know vs what you're assuming. Often the loop happens because you've been asking the wrong question from the start.
When you need to learn something
Claude will implement things you don't understand. Over time, this erodes your ability to evaluate what Claude produces.
When you're in a domain you don't know well — new language, unfamiliar library, architecture pattern you haven't worked with — slow down. Read the docs. Understand what Claude is doing before letting it proceed.
Prompt: "Before you implement this, explain the approach to me like I've never worked with [X]. I want to understand it before seeing the code." This slows you down but keeps you competent.
When you're tired
Claude doesn't get tired. You do. When you're running on fumes, you lose the ability to evaluate what Claude produces. You start approving things that you'd catch immediately when fresh.
Tired + Claude = fast path to subtle bugs. The productivity gain evaporates if you spend twice as long debugging tomorrow.
What I actually do
Before starting a session I now ask: do I understand this problem well enough to evaluate Claude's answer? If no, I write in a notebook for 10 minutes first. Not in Claude — in a notebook, where I can't outsource the thinking.
It sounds slow. It's actually faster because Claude's answers are immediately useful instead of requiring three rounds of correction.
The Agent Prompt Playbook has prompts for the cases where you do want Claude's help thinking — tradeoff analysis, sanity checks, stress-testing your own assumptions. $29.