Claude Code Plan Mode: eerst denken, dan doen

De meeste AI coding fouten volgen hetzelfde patroon: Claude begint meteen te coderen, maakt aannames, en na drie iteraties zit je met een puinhoop die je handmatig moet opruimen.

Plan mode lost dit op. Het is een read-only modus waarin Claude eerst analyseert, een plan maakt, en pas na jouw goedkeuring begint met bouwen.

Het verschil: ready, fire, aim versus structured development.

Wat is plan mode?

Plan mode is een speciale modus waarin Claude:

• Wel kan: bestanden lezen, code analyseren, zoeken, vragen stellen
• Niet kan: bestanden bewerken, commands uitvoeren, code schrijven

Het dwingt een planning fase af voordat er iets verandert. Claude onderzoekt je codebase, begrijpt de requirements, en schrijft een plan. Pas als jij dat plan goedkeurt, gaat het verder.

Wanneer gebruiken?

Plan mode is niet voor elke taak. Gebruik het voor:

Multi-file changes

Wanneer je feature meerdere bestanden raakt. Routes, controllers, models, views, tests. Zonder plan mist Claude vaak onderdelen.

Complexe refactors

Code herstructureren waarbij je de bestaande architectuur moet begrijpen voordat je iets verandert.

Onbekende codebases

Nieuw project? Laat Claude eerst verkennen en een plan maken voordat het gaat bouwen.

Kritieke systemen

Auth, payments, data migrations. Hier wil je een plan reviewen voordat er code geschreven wordt.

Niet nodig voor:

• Simpele bug fixes
• Kleine tweaks
• Taken waar je al precies weet wat er moet gebeuren

Hoe activeren

Optie 1: Keyboard shortcut

Shift+Tab (twee keer)

In de Claude Code interface. Exit met dezelfde shortcut.

Optie 2: Command

/plan

Optie 3: CLI flag

claude --permission-mode plan

Optie 4: Headless

claude -p "Analyseer de auth implementatie en maak een plan voor 2FA"

De -p flag runt in plan mode direct vanuit je terminal.

De workflow

Wanneer je plan mode activeert:

1. Claude analyseert - Leest relevante bestanden, begrijpt de structuur
2. Claude vraagt - Gebruikt AskUserQuestion voor onduidelijkheden
3. Claude plant - Schrijft een gestructureerd plan naar een plan file
4. Jij reviewt - Je ziet het plan en keurt goed of geeft feedback
5. Claude bouwt - Na goedkeuring begint de implementatie

Het plan bevat typisch:

• Task breakdown
• Betrokken bestanden
• Volgorde van wijzigingen
• Dependencies tussen stappen
• Potentiële risico's

Plan file

Claude schrijft het plan naar een markdown file. Standaard in .claude/plans/. Dit is gewoon tekst, geen speciale structuur.

Voorbeeld:

# Plan: Add 2FA to authentication

## Overview
Implement TOTP-based 2FA for user login.

## Tasks
1. Add `two_factor_secret` column to users table
2. Create TwoFactorController with setup/verify actions
3. Add middleware for 2FA enforcement
4. Update login flow to check 2FA status
5. Create Blade views for setup and verification
6. Add tests for 2FA flow

## Files affected
- database/migrations/
- app/Http/Controllers/Auth/
- app/Http/Middleware/
- resources/views/auth/
- routes/web.php
- tests/Feature/Auth/

## Risks
- Existing sessions need handling during rollout
- Recovery codes needed for locked-out users

Feedback geven

Als je het plan niet goedkeurt, kun je feedback geven. Claude past het plan aan en vraagt opnieuw om goedkeuring.

Dit is iteratief:

1. Claude maakt plan v1
2. Jij: "Voeg ook rate limiting toe aan de verify endpoint"
3. Claude maakt plan v2
4. Jij: goedgekeurd
5. Claude begint bouwen

Veel beter dan achteraf ontdekken dat er iets mist.

Opusplan: het beste van twee werelden

Claude Code heeft een opusplan model alias:

• In plan mode: Opus 4.5 voor complexe reasoning
• In execution mode: Automatisch naar Sonnet voor implementatie

Je krijgt Opus's superieure planning capabilities, en Sonnet's snelheid en kosten-efficiëntie voor de daadwerkelijke code.

Mijn setup (James)

In James gebruik ik plan mode via de feature skill:

User: "ENG-123"
        ↓
Setup + Research (parallel)
        ↓
EnterPlanMode() → Write spec → ExitPlanMode()
        ↓
User approves
        ↓
Implement → Test → Document

De spec fase draait volledig in plan mode. Claude kan niet beginnen met bouwen tot ik het plan heb goedgekeurd. Dit voorkomt de klassieke fout van "ik dacht dat je X bedoelde".

De spec wordt opgeslagen in .docs/features/<slug>/spec.md. Als de sessie crasht of de context vol raakt, kan ik een nieuwe sessie starten met "lees de spec en ga verder".

Dit is spec-driven development: eerst de spec, dan de code.

Tips

1. Wees specifiek in je vraag
   "Bouw een auth systeem" geeft een vaag plan. "Bouw TOTP-based 2FA met recovery codes en rate limiting" geeft een concreet plan.
2. Review het plan echt
   Het is verleidelijk om snel goed te keuren. Maar een paar minuten reviewen bespaart uren debugging.
3. Geef feedback, niet alleen afkeuring
   "Niet goed" helpt Claude niet. "Voeg error handling toe voor edge case X" wel.
4. Combineer met subagents
   Laat een researcher subagent eerst context verzamelen, dan plan mode voor de spec.
5. Sla plans op
   Plans zijn waardevol. Bewaar ze in .docs/ of version control. Ze documenteren waarom code is zoals het is.

Wanneer NIET te gebruiken

Plan mode heeft overhead. Voor simpele taken is het overkill:

• "Fix de typo in de README" → gewoon doen
• "Voeg een log statement toe" → gewoon doen
• "Update de dependency versie" → gewoon doen

Gebruik plan mode voor taken waar een verkeerde aanpak je uren kost. Niet voor taken die 30 seconden duren.

Volgende stap

Plan mode is stap één. Spec-driven development bouwt hierop voort met een complete workflow van requirements naar werkende code.

Wanneer tekst niet genoeg is en je visueel wilt denken - architectuur, design, complexe flows - bekijk Interactive Playgrounds.

In mijn AI trainingen oefen je met plan mode op echte projecten. Of bekijk hoe ik dit toepas bij AI implementatie projecten.

Vragen? Neem contact op.