Lesson 30: Extended Thinking

Day 30 of 50 · ~7 min read · Phase 4: Integrations

The Opening Question

Most of Claude Code's work is fast. You ask a question, Claude thinks for a moment, and it acts. Read a file, edit it, run tests, iterate.

But some problems aren't quick. They're deep. They require stepping back and thinking through alternatives, considering edge cases, planning a strategy before committing to action.

Here's the question: What if you could give Claude more thinking time on really hard problems?

And more fundamentally: How much does extra thinking actually help when the stakes are high?

Discovery

Question 1: What is extended thinking?

Extended thinking is a mode where Claude allocates additional computation to internal reasoning before producing output or taking action.

Instead of thinking briefly and then writing/acting, Claude does something different:

Normal mode: Think → Act → Show result

Extended thinking mode: Think deeply → Analyze options → Plan approach → Then Act → Show result

The "thinking" phase is internal. You don't see it happen (though you see it took longer). But when Claude emerges from that deep thinking, it's made more careful decisions.

Pause and think: Why would deeper thinking help when writing code or debugging?

Here's the reason: the stakes are high. If Claude makes a careless decision and edits the wrong file, you've got a problem. If Claude misunderstands a bug and implements the wrong fix, you're blocked. When the cost of a mistake is high, extra thinking pays off.

Question 2: When should you use extended thinking?

Not every problem needs deep thinking. Some decisions are straightforward.

Use extended thinking when:

• You're tackling a complex architectural decision (how should I refactor this system?)
• You're debugging a subtle bug that involves multiple systems
• You're planning a multi-step feature that touches many files
• You're not sure what the right approach is and Claude needs to reason through alternatives
• The cost of getting it wrong is high (production code, security-sensitive work, complex logic)

Don't use extended thinking when:

• You're making a simple edit (add this line, remove that comment)
• The task is straightforward (write a test for this function)
• You're in a hurry and the problem is low-stakes
• You're doing exploratory work where fast iteration matters more than perfect reasoning

Question 3: How does extended thinking actually work in Claude Code?

In recent versions of Claude Code, extended thinking is adaptive. This means Claude decides how much to think based on the problem.

You can enable extended thinking in a few ways:

# Enable extended thinking for this session
claude --thinking=adaptive

# Or in a conversation:
# "Please use extended thinking for this problem..."

When extended thinking is enabled, Claude will:

1. Receive your request
2. Allocate thinking time based on how complex it seems
3. Reason through the problem internally
4. Then produce a solution and take action

The key insight: Claude decides how much thinking is needed. A simple problem gets quick thinking. A hard problem gets deep thinking.

Question 4: What's the tradeoff?

Extended thinking is powerful, but it has a cost:

Benefit: Better decisions on hard problems. Fewer false starts. More careful reasoning.

Cost: Slower. Extended thinking takes more computation and more time.

So the question is: Is the extra thinking time worth the cost?

For some tasks, absolutely. You'd rather wait 30 seconds for a careful decision than 5 seconds for a careless one that breaks your code.

For other tasks, no. A quick iteration loop is more valuable than perfect reasoning.

Here's the right way to think about it:

• Architecture and design decisions: Use extended thinking. You're making choices that affect everything else.
• Debugging complex bugs: Use extended thinking. The thinking helps Claude trace through multiple systems.
• Quick edits and incremental changes: Skip extended thinking. Fast iteration wins.

The Insight

Extended thinking is like giving Claude permission to pause and think carefully before acting. On complex, high-stakes problems — architectural decisions, subtle bugs, multi-system changes — that extra thinking often prevents mistakes that would cost far more time than the thinking took. On simple problems, it's overhead. The key is knowing which problems are complex enough to warrant it.

The mental model: Extended thinking is like the difference between snapping your fingers and making a decision versus going for a walk to think it through. For simple choices, snap your fingers. For big decisions, take the walk.

Try It

Let's experience extended thinking in Claude Code.

1. Pick a complex problem in your codebase. Something architectural or subtle. For example:

   • "We're using callbacks in three different modules. How should we refactor to use promises consistently?"
   • "Why are our tests intermittently failing? I don't see an obvious race condition."
   • "I need to add a feature, but it affects five different systems. Where should I start?"

2. Start a Claude Code session with extended thinking:

   claude --thinking=adaptive
   

3. Ask Claude the question:

   [Paste your complex problem or question]
   

4. Watch it think. Claude will take longer than usual. That's the extended thinking happening.

5. Compare to normal mode. Try the same question in a normal session without extended thinking:

   claude
   

   Notice the difference in reasoning depth and how quickly it reaches a conclusion.

6. Check the result. For complex problems, the extended thinking version should produce more careful, better-reasoned solutions.

Key Concepts Introduced

Bridge to Lesson 31

You've now learned how Claude can think deeper before acting. But there's another dimension to control: what if you want to go back?

What if you started down a path, Claude made changes, and then you realized "wait, let's try a different approach"?

Tomorrow's question: How do you rewind and fork conversations to try different approaches without losing your work?

We'll explore checkpointing and conversation forking — the ability to save your state and branch off to explore alternatives.

← Back to Curriculum · Lesson 31 →