Most developers use Claude Code like a magic 8-ball. They throw a vague request at it, hope for the best, and then spend 20 minutes fixing the output. I used to do the same thing. Then I noticed that my best sessions — the ones where Claude nailed it on the first try — all followed the same three-phase structure.

I call it Think-Plan-Execute. It’s not a Claude Code feature. It’s a mental framework for how you interact with it. And once you see it, you can’t unsee it.


The Problem: Jumping Straight to Execute

Here’s what most sessions look like:

You: "Refactor the auth module to use JWT"
Claude: *starts writing code immediately*
Claude: *picks the wrong library*
You: "No, use jose, not jsonwebtoken"
Claude: *rewrites half the code*
Claude: *puts the middleware in the wrong place*
You: "That should go in src/middleware/, not src/auth/"
Claude: *moves everything, breaks imports*

Five messages in, you’ve spent $3, and you’re only at the starting point of what should have been message one. The problem isn’t Claude Code — it’s that you asked it to execute before it understood the problem.


The Three Phases

Phase 1: Think (Understand the Problem)

Before you ask Claude Code to change anything, ask it to think about the current state. This is where you build shared context.

"I need to add JWT authentication to our Express API. Before making
any changes, analyze the current auth implementation:
- Read src/auth/ and summarize the current approach
- Read src/middleware/auth.ts and explain how requests are validated
- Check package.json for existing auth-related dependencies
- List all routes that currently require authentication
Don't change anything yet. Just help me understand what we're working with."

This phase is cheap (reading files costs very little) and incredibly valuable. Claude Code builds a mental model of your system. You verify that model is correct. No wasted tokens on wrong implementations.

Key phrases for the Think phase:

  • “Before making changes, analyze…”
  • “Don’t change anything yet”
  • “Help me understand the current state”
  • “Read and summarize…”

Phase 2: Plan (Design the Solution)

Now that Claude Code understands the current state, ask it to plan the changes before writing any code.

"Great analysis. Now let's plan the JWT migration. Using the jose library
(it's already in package.json):
1. What files need to change?
2. What's the order of changes to avoid breaking things?
3. What are the edge cases we need to handle?
4. Write a step-by-step implementation plan.
Don't write code yet — just the plan."

Claude Code produces a structured plan. You review it. Catch problems early. Redirect if needed. This costs a fraction of what rewriting code costs.

Key phrases for the Plan phase:

  • “Write a step-by-step plan”
  • “What’s the order of changes?”
  • “Don’t write code yet — just the plan”
  • “What edge cases should we handle?”

Claude Code actually has a built-in Plan Mode (/plan) that enforces this pattern. It prevents Claude from writing code until you approve the plan. But even without Plan Mode, you can get the same benefit by being explicit in your prompts.

Phase 3: Execute (Implement with Precision)

Now you execute, one step at a time, following the plan.

"Let's execute the plan. Start with step 1: Create the JWT utility
functions in src/auth/jwt.ts. Use the jose library's SignJWT and
jwtVerify. Include functions for:
- generateToken(userId, role)
- verifyToken(token) → returns payload or throws
- refreshToken(existingToken) → returns new token
Follow our existing patterns in src/auth/password.ts for error handling."

Notice how specific this is. Claude Code knows exactly what to create, where to put it, and what patterns to follow. The plan already resolved the ambiguity. Execution is just implementation.


Why This Works: The Token Economics

The Think-Plan-Execute pattern doesn’t just produce better code — it’s actually cheaper.

Without the pattern:

StepMessagesCost
Initial (vague) request1$0.30
Fixing wrong library choice2$0.80
Fixing file placement2$1.20
Fixing broken imports3$2.40
Getting the final version right2$1.80
Total10$6.50

With the pattern:

PhaseMessagesCost
Think (analysis)1$0.20
Plan (design)2$0.60
Execute (implementation)3$1.50
Total6$2.30

You spend a little more upfront on thinking and planning, but save dramatically on rework. The total is 65% cheaper.


Real Example: Database Migration

Here’s a real session from last week where I used this pattern to migrate a PostgreSQL schema.

Think Phase

"We need to add multi-tenancy to our database. Before any changes:
1. Read the current schema in prisma/schema.prisma
2. List all models that reference User
3. Check if we have any raw SQL queries in src/db/
4. Summarize the current data access patterns"

Claude Code reported back: 12 models, 4 with direct User relations, 2 raw SQL queries in /db/reports.ts, and all data access goes through Prisma.

Plan Phase

"Good. Plan the multi-tenancy migration using a 'tenantId' column
approach (not separate schemas). Requirements:
- Every table gets a tenantId column
- All Prisma queries must filter by tenantId
- The raw SQL in reports.ts needs manual updating
- Migration must be backwards-compatible (existing data gets a default tenant)
- Plan the order of changes to avoid foreign key issues"

Claude Code produced a 7-step plan. I caught one issue — it planned to add tenantId to the AuditLog table, which should be cross-tenant for admin visibility. We adjusted the plan before writing a single line of code.

Execute Phase

"Execute step 1: Add tenantId to the Prisma schema for these models:
User, Project, Task, Comment, File. Make it required with a default
value of 'default-tenant'. Add an index on tenantId for each table."

Each step was clean, focused, and correct on the first try. The entire migration took 12 messages instead of the 30+ it would have taken with the “just do it” approach.


Adapting the Pattern to Task Size

Not every task needs all three phases. Here’s my rule of thumb:

Task SizeExampleApproach
Tiny”Fix this typo”Execute directly
Small”Add a log statement”Execute directly
Medium”Add input validation to the form”Plan → Execute
Large”Refactor auth to use JWT”Think → Plan → Execute
Huge”Add multi-tenancy”Think → Plan → Execute (multiple rounds)

For medium tasks, you can skip the Think phase if you already understand the codebase well. For huge tasks, you might do multiple Think-Plan-Execute cycles, one for each major component.


Claude Code’s Built-in Tools for This Pattern

Claude Code has features that map directly to each phase:

Think phase:

  • Regular prompts with “analyze”, “read”, “summarize”
  • The AI reads files and builds understanding

Plan phase:

  • /plan — Activates Plan Mode, prevents code execution
  • Think mode with extended thinking for complex reasoning

Execute phase:

  • Regular interactive mode for step-by-step implementation
  • Full auto mode for trusted, well-planned execution

The key insight: you don’t need the built-in features to use the pattern. The pattern is about your prompting discipline, not about toggles and settings.


The Anti-Patterns to Avoid

1. Skipping Think for “simple” changes that aren’t simple. “Just rename the User model to Account” sounds simple. But it touches every file that references User. Think first.

2. Planning too broadly. “Plan the entire application architecture” is too vague. Plan one component at a time. Each Plan phase should produce a plan you can execute in 3-5 steps.

3. Deviating from the plan during Execute. You had a plan. Follow it. If you discover something unexpected during execution, stop. Go back to Plan. Adjust. Then resume execution.

4. Combining phases in one prompt. “Analyze the auth module and then rewrite it to use JWT” puts Think and Execute in the same prompt. Claude skims the analysis and rushes to implementation. Separate them.


Key Takeaways

  1. Think before you Plan, Plan before you Execute. Each phase reduces risk and cost for the next one.
  2. The Think phase is the cheapest insurance you can buy. Reading files costs pennies. Rewriting code costs dollars.
  3. Plans catch design errors before they become code errors. Review a plan in 30 seconds; review generated code in 30 minutes.
  4. Adapt the depth to the task size. Tiny tasks can skip straight to Execute. Large tasks need all three phases.
  5. Use “Don’t change anything yet” as your power phrase. It forces Claude into analysis mode and prevents premature execution.

This pattern has become so natural that I don’t even think about it anymore. It’s just how I work with Claude Code. And the results speak for themselves — higher quality, lower cost, less frustration.


The Think-Plan-Execute pattern is covered in depth in Phase 6: Thinking & Planning of the Claude Code Mastery course. Phases 1-3 are free.