Plan Mode vs. Auto-Accept: The Claude Code Workflow That Actually Works

Claude Code has two primary operating modes:

Plan Mode is toggled with Shift+Tab twice. In this state, Claude:

1. Analyzes your request
2. Proposes a detailed plan
3. Waits for your review and approval
4. Only touches files after you confirm

This is the difference between a careful architect reviewing blueprints and a contractor who starts demolishing walls before understanding the house.

Case Study: The Feature That Wasn't

A developer asked Claude to "add user authentication to the app." In auto-accept mode, Claude immediately:

1. Created a new auth directory
2. Added NextAuth.js dependencies
3. Created API routes
4. Modified the database schema
5. Updated 12 components

The problem? The app already had authentication via Supabase. Claude didn't check first. Now there were two competing auth systems, broken imports, and a corrupted database migration.

Time spent: 3 hours debugging and reverting.

With Plan Mode, Claude would have first asked: "I see you want authentication. I notice there's already a Supabase client configured. Should I extend the existing auth system or replace it?"

Why This Happens

Without explicit planning:

• Claude acts on assumptions, not understanding
• Complex tasks get fragmented across many small changes
• Each change builds on potentially flawed previous changes
• By the time you notice something's wrong, you're deep in a broken state

Plan Mode leverages Claude's reasoning capabilities before its editing capabilities.

Under the Hood

When you enter Plan Mode, Claude Code injects system reminders that:

1. Instruct Claude to analyze before acting
2. Request structured output (what files, what changes, what order)
3. Suppress file editing tools until approval
4. Encourage clarifying questions

The Plan Output Structure

A good plan includes:

[Claude's interpretation of the task]

[High-level strategy]

1. src/components/Header.tsx - Add navigation state
2. src/lib/auth.ts - Create auth helper functions
3. src/app/layout.tsx - Wrap with auth provider

1. src/contexts/AuthContext.tsx - Auth context provider
2. src/hooks/useAuth.ts - Auth hook

1. Create context and hook (no dependencies)
2. Update auth lib (depends on nothing)
3. Modify layout (depends on context)
4. Update Header (depends on hook)

• Should the auth state persist across page refreshes?
• What should happen when a session expires?

### Plan Mode Controls


| Command             | Action                        |
| ------------------- | ----------------------------- |
| `Shift+Tab` (twice) | Toggle Plan Mode              |
| `Enter`             | Approve plan, begin execution |
| Type response       | Provide feedback, refine plan |
| `/clear`            | Abandon and start fresh       |

Boris Cherny, creator of Claude Code, describes his workflow:

"Most sessions start in Plan mode. I go back and forth with Claude until I like its plan. From there, I switch into auto-accept edits mode and Claude can usually 1-shot it."

Step-by-Step Workflow

┌───────────────────────────────────────┐
│  1. ENTER PLAN MODE                     │
│     Shift+Tab twice                     │
└───────────────────┬───────────────────┘
                    │
                    ▼
┌───────────────────────────────────────┐
│  2. DESCRIBE THE TASK                   │
│     Be specific about goals             │
└───────────────────┬───────────────────┘
                    │
                    ▼
┌───────────────────────────────────────┐
│  3. REVIEW CLAUDE'S PLAN                │
│     Check understanding & approach      │
└─────────┬───────────────────┬─────────┘
          │                   │
    Plan OK?            Plan needs work?
          │                   │
          ▼                   ▼
┌───────────────┐   ┌───────────────┐
│ 4a. APPROVE   │   │ 4b. REFINE    │
│ Press Enter   │   │ Type feedback │
└───────┬───────┘   └───────┬───────┘
        │                   │
        ▼                   └───► Back to step 3
┌───────────────────────────────────────┐
│  5. EXECUTION                           │
│     Claude implements the approved plan │
└───────────────────┬───────────────────┘
                    │
                    ▼
┌───────────────────────────────────────┐
│  6. VERIFY                              │
│     Test, typecheck, review             │
└───────────────────────────────────────┘

Practical Example

[Plan Mode ON]

> Build a contact form with validation

Claude's Plan:

You want a contact form component with client-side validation.

I'll create a form using react-hook-form with Zod validation,
following the existing form patterns in your codebase.

1. src/components/forms/ContactForm.tsx
2. src/lib/validations/contact.ts

1. src/app/contact/page.tsx - Import and render form

• Fields: name, email, message
• Validation: Required fields, email format, min length
• Submit handler: POST to /api/contact
• Success/error states with toast notifications

• Should the form include a phone number field?
• What happens after successful submission? (redirect, message, reset)

No phone field. After success, show a thank you message and reset.

Claude's Revised Plan:

[Incorporates feedback...]

Looks good, proceed.

[Claude begins execution with clear direction]
```

Use Plan Mode For:

• New features - Anything touching multiple files
• Refactors - Structural changes to existing code
• Unfamiliar codebases - When you or Claude don't know the patterns yet
• Complex logic - Business logic that needs careful thought
• Database changes - Schema modifications, migrations
• API design - Endpoint structure, request/response shapes

Use Auto-Accept For:

• Typo fixes - Simple text changes
• Style tweaks - CSS adjustments you can visually verify
• Adding comments - Documentation without logic changes
• Repetitive tasks - After pattern is established
• Test additions - When structure is clear

The 90/10 Rule

Experienced users report using Plan Mode for approximately 90% of sessions. The 10% auto-accept cases are typically:

• Quick follow-up changes to approved work
• Simple, isolated tasks
• Situations where you're actively watching output

Technique 1: Spec-Based Planning

Thariq's popular workflow:

> I want to build a feature. Interview me about requirements 
> using clarifying questions. Don't write any code yet.

[Claude asks 5-10 questions]

> Now write a detailed spec based on our discussion.
> Save it to docs/specs/
feature-name.md


[Claude creates spec document]

> /clear
> Read docs/specs/
feature-name.md
 and implement it.

[Fresh context, clear spec, focused execution]

This separates requirements gathering from implementation, preventing mid-build scope changes.

Technique 2: Throw-Away First Draft

For complex features:

1. Create a throwaway branch
2. Let Claude implement end-to-end in auto-accept
3. Observe what it produces
4. Identify where it diverged from expectations
5. Use learnings to write a precise plan
6. Implement properly on main branch

The first draft is research, not deliverable code.

Technique 3: Parallel Planning

For architectural decisions:

> Plan two approaches to this feature:
>
> Approach A: Server Components with server actions
> Approach B: Client Components with API routes
>
> For each, outline: files needed, pros, cons, 
> and estimated complexity.

[Claude produces comparison]

> Let's go with Approach A. Now detail the implementation plan.

A scratchpad file makes plans persistent and auditable.

Setup

> Before making any changes, write your plan to 
SCRATCHPAD.md
.
> Update it as you progress. Check off completed items.

Benefits

1. Persistence - Plan survives context compaction
2. Auditability - You can review what was planned vs. executed
3. Resumability - Easy to pick up where you left off
4. Attention anchoring - Repeated reading keeps Claude focused

Example SCRATCHPAD.md

# Feature: User Dashboard

• Create dashboard layout component
• Add sidebar navigation
• Implement stats cards
• Add recent activity feed
• Connect to API endpoints

• Using CSS Grid for layout (better for this use case than Flexbox)
• Stats refresh every 30 seconds via SWR
• Activity feed uses infinite scroll

• Should we cache dashboard data? If so, for how long?

• src/app/dashboard/layout.tsx (created)
• src/components/DashboardSidebar.tsx (created)
• src/components/ui/StatCard.tsx (in progress)

Example 1: E-commerce Checkout Flow

Bad approach (auto-accept):

> Add checkout to the store

Claude starts building immediately, makes assumptions about payment provider, cart structure, and user flow.

Good approach (plan mode):

> I need to add checkout functionality. Before we start:
> 1. Review the existing cart implementation in src/lib/cart
> 2. Check what payment providers are already configured
> 3. Understand the current user authentication flow
> Then propose a checkout implementation plan.

Claude's Plan:

• Cart: Uses Zustand store, items stored locally
• Payments: Stripe SDK installed but not configured
• Auth: NextAuth with email magic links

1. Cart review page (existing, minor updates needed)
2. Shipping information form (new)
3. Payment form with Stripe Elements (new)
4. Order confirmation page (new)

• src/app/checkout/page.tsx
• src/app/checkout/shipping/page.tsx
• src/app/checkout/payment/page.tsx
• src/app/checkout/confirmation/page.tsx
• src/components/checkout/ShippingForm.tsx
• src/components/checkout/PaymentForm.tsx
• src/lib/stripe.ts
• src/app/api/checkout/route.ts

• Guest checkout allowed, or require account?
• Ship to billing address option?
• Save payment method for future?

### Example 2: Database Migration


```javascript
[Plan Mode]

> We need to add a 'teams' feature. Users can belong to 
> multiple teams, and resources can be owned by teams.

Claude's Plan:

New Tables

• teams (id, name, slug, created_at)
• team_members (team_id, user_id, role, joined_at)
• team_invitations (id, team_id, email, token, expires_at)

Modified Tables

• resources: Add team_id column (nullable for personal resources)

1. Create new tables first (non-breaking)
2. Add nullable team_id to resources
3. Deploy code that supports both personal and team resources
4. Migrate existing resources to personal "default team" if desired

• Existing queries assume resources are user-owned
• Authorization logic needs updating
• API responses need team context

1. Schema migration
2. Backend models and relations
3. API routes for team CRUD
4. Update resource authorization
5. Frontend team management UI
6. Update resource creation to support teams

Good analysis. Let's start with just the schema migration.
I want to review each step before continuing.
```

Mistake 1: Approving Vague Plans

# Bad plan (too vague)
"I'll update the component to handle the new requirements."

# Good plan (specific)
"I'll modify UserProfile.tsx to:
- Add an edit mode toggle
- Create form fields for name, email, bio
- Add validation for email format
- Include save/cancel buttons
- Show loading state during API call"

If the plan isn't specific enough, ask for details before approving.

Mistake 2: Not Asking Clarifying Questions

If Claude's plan doesn't include questions, it might be making assumptions. Ask:

> Before I approve: What assumptions are you making?
> Are there any ambiguities in my request?

Mistake 3: Planning Too Far Ahead

Don't plan an entire application at once. Plan one feature, implement it, then plan the next.

# Too much
"Plan the entire authentication system, dashboard, 
team management, billing, and admin panel."

# Right size
"Plan the user authentication flow. Just login and signup."

Mistake 4: Skipping Verification

A plan is only as good as its execution. After Claude finishes:

1. Run your test suite
2. Manually test the feature
3. Check for type errors
4. Review the diff

Official Resources

• Claude Code Documentation
• What is Plan Mode? - Armin Ronacher's analysis

Workflow Examples

• Boris Cherny's Workflow - Creator of Claude Code
• Thariq's Spec-Based Workflow

Community Discussions

• Claude Code Tips Repository
• r/ClaudeAI - Community discussions