Claude Code plan mode: beslissen voordat de agent schrijft

Er is één moment in een agentsessie waarop stoppen je niets kost.

Dat is het scherm waarin je een plan goedkeurt. Een document in beeld, vier keuzes eronder, en op schijf is er nog geen byte veranderd. Alles daarna kost je iets om terug te draaien: een diff die je moet lezen, een branch die je moet resetten, een migratie die de andere kant op moet.

Plan mode is er om dat moment bewust in te bouwen, in plaats van erop te hopen.

Code genereren werd goedkoop. Bepalen wát je bouwt bleef duur, en dat verandert niet, want juist dat deel vraagt kennis van je eigen systeem. In plan mode doe je dat dure deel op het moment dat je het nog kunt weggooien.

Plan mode aanzetten in Claude Code ​

Vier manieren, elk met een eigen moment:

• Met Shift+Tab schakel je door default → acceptEdits → plan. In de statusbalk verschijnt ⏸ plan mode on.
• Zet /plan vóór een losse prompt als je het bij die ene beurt wilt houden.
• claude --permission-mode plan om een sessie meteen in plan mode te starten.
• "permissions": { "defaultMode": "plan" } in .claude/settings.json als een project hier altijd in hoort te beginnen.

Nog een keer Shift+Tab en je bent eruit, zonder iets goed te keuren.

Eén ding moet je in je mentale model bijstellen: het plan is tegenwoordig een bestand. Claude schrijft het naar ~/.claude/plans/ onder een gegenereerde naam van drie woorden, of naar de map die je met plansDirectory aanwijst. Zonder dat bestand werkt ExitPlanMode niet eens. Probeer het maar, dan antwoordt de tool met No plan found. Please write your plan to the plan file first.

Dat verschil is groter dan het klinkt. Een plan dat je goedkeurt in een chatvenster ben je morgen kwijt. Een plan op schijf is een document dat je kunt openen, aanpassen, vergelijken en doorgeven aan een sessie die nog nooit van dit gesprek heeft gehoord. Het is de spec die je toch nooit ging schrijven, opgesteld door het ding dat hem zo gaat uitvoeren.

Wat plan mode echt tegenhoudt ​

Dit is de instructie die Claude krijgt, letterlijk zoals hij in de 2.1.220-binary staat:

Plan mode is active. The user indicated that they do not want you to execute yet -- you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received.

Met daarachter de uitzondering:

You should build your plan incrementally by writing to or editing this file. NOTE that this is the only file you are allowed to edit - other than this you are only allowed to take READ-ONLY actions.

De gangbare omschrijving van plan mode, een afgedwongen read-only-stand waarin elke schrijftool uit staat, klopt op drie punten niet meer.

Hij schrijft. Eén bestand, met opzet, maar het schrijfpad staat open.

Hij draait shell-commando's. Verkennen vraagt nu eenmaal om git log, om grep, om de help-output van je testrunner. Sinds 2.1.218 staat useAutoModeDuringPlan standaard aan, waardoor die commando's langs de auto mode-classifier gaan in plaats van langs jou. Wat die goedkeurt, draait gewoon tijdens het plannen.

En in een sessie waar bypass permissions beschikbaar is, worden de blokkades van plan mode helemaal niet afgedwongen. De documentatie is daar helder over: Claude krijgt nog steeds te horen dat hij moet plannen zonder te bewerken, maar een bewerking die hij toch probeert, gebeurt gewoon. Ben je gestart met --dangerously-skip-permissions en schakel je daarna voor de zekerheid naar plan mode, dan houd je een stevig geformuleerd advies over. In welke stand je zit, hangt dus af van hoe de sessie begon, en daarom wil je het permissiemodel paraat hebben voordat je hierop vertrouwt.

Plan mode blijft de moeite waard. In een gewone sessie wordt hij wel degelijk afgedwongen en houdt hij stand. Weet alleen welke garantie je precies hebt, want waar het je om te doen is, is de pauze, en die heb je in beide gevallen.

De vijf fases die je nooit ziet ​

Een plan goedkeuren voelt als het lezen van één document. Het maken ervan volgt een workflow die Claude Code in de sessie injecteert en die je nooit te zien krijgt:

1. Eerst begrijpen. Een handvol Explore-subagents parallel, één per open vraag, met de opdracht eerst te zoeken naar bestaande functies en patronen om te hergebruiken, voordat er ook maar iets nieuws wordt voorgesteld.
2. Ontwerpen. Plan-agents, opnieuw parallel, elk met een bewust andere invalshoek. De prompt noemt de assen per soort taak: eenvoud tegenover performance tegenover onderhoudbaarheid bij een nieuwe feature, oorzaak tegenover workaround tegenover preventie bij een bug, minimale ingreep tegenover schone architectuur bij een refactor.
3. Nalopen. De kritieke bestanden uit de verkenning lezen en de ontwerpen naast je oorspronkelijke vraag leggen.
4. Doorvragen. Echte vragen aan jou via AskUserQuestion, met een expliciet verbod om die tool te gebruiken voor "is dit plan goed zo?".
5. ExitPlanMode aanroepen.

In sommige sessies krijg je een uitgeklede versie van de eerste twee fases, waarin Claude de bestanden zelf leest in plaats van dat werk uit te besteden. De vorm blijft verder hetzelfde.

Ook het planbestand heeft een vorm die vastligt. Beginnen met een Context-sectie die uitlegt waarom deze wijziging er komt. Alleen de aanbevolen aanpak opnemen, niet alle alternatieven. De kritieke bestanden benoemen. Verwijzen naar bestaande utilities die hergebruikt moeten worden, met pad. Afsluiten met een verificatiesectie die beschrijft hoe je de wijziging van begin tot eind test.

Twee gevolgen die het overdenken waard zijn.

Plannen kost veruit de meeste tokens van je hele sessie, en dat hoort zo. Meerdere subagents die tegelijk je codebase doorspitten, dat loopt nu eenmaal op. Het is wel de juiste plek om ze uit te geven, want dit is de enige uitgave die je kunt weggooien zonder iets te verliezen.

En subagents kunnen zelf niet plannen. EnterPlanMode wordt in agentcontexten botweg geweigerd. Plannen gebeurt in de hoofdsessie, en dus tussen jou en de agent, en daar draait het uiteindelijk om.

Zo haal je er meer uit ​

Druk op Ctrl+G. Daarmee open je het voorgestelde plan in je eigen editor, zodat je het kunt aanpassen voordat Claude verdergaat. Dit is de meest waardevolle sneltoets van de hele feature en bijna niemand gebruikt hem. Een plan lezen in een scrollende terminal nodigt uit tot scannen op gevoel. Datzelfde plan in je editor nodigt uit tot de vraag die ertoe doet, namelijk of stap vier aan die ene module komt waarvan jij weet dat hij broos is.

Wijs het plan af met commentaar in plaats van het goed te keuren en daarna bij te sturen. "No, keep planning" brengt je opmerkingen terug in dezelfde sessie, waar de verkenning nog in het geheugen zit. Goedkeuren en drie bewerkingen later bijsturen betekent discussiëren met een agent die al vastzit aan zijn keuze, en betalen voor de code die hij onderweg schreef.

Laat plansDirectory naar de repo wijzen voor werk waar een collega naar kijkt. Met ./docs/plans wordt het plan iets dat je kunt reviewen, en het ligt er vóór de pull request in plaats van erna.

Herschrijf de workflow als hij niet bij je past. --plan-mode-instructions, of planModeInstructions in de SDK, vervangt de fasebeschrijving door die van jou. De read-only-preambule en het ExitPlanMode-protocol blijven altijd staan, dus je kunt wel veranderen hóé hij plant, maar je krijgt hem niet ontwapend.

Sla het over bij klein werk. Claude Code adviseert zelf om niet te plannen bij typefouten, wijzigingen van één regel, één functie met heldere eisen, of puur uitzoekwerk. Een wijziging van twee regels plannen is toneel, en toneel is precies hoe een goede gewoonte verandert in iets waar mensen doorheen klikken. De vraag die daaraan voorafgaat, is of de taak überhaupt bij een agent hoort, en die stel je eerst.

Het goedkeuren ís de feature ​

Alles hierboven is machinerie. De feature zit in die vier seconden waarin jij beslist.

Ik heb mezelf een plan zien goedkeuren omdat het lang was, netjes opgemaakt, en binnenkwam terwijl ik met iets anders bezig was. Lengte oogt als grondigheid. Dat is het niet. Een plan kan elf bestanden noemen en er precies naast zitten bij dat ene dat telt, en ik had het niet gemerkt, want ik las de vorm en niet de inhoud.

Die fout heeft in elk ander deel van het vak allang een naam. Een plan goedkeuren dat je niet hebt gelezen is code mergen die je niet hebt gelezen, één stap eerder en een stuk goedkoper. Die lage prijs is het goede nieuws: hoe eerder je leest, hoe minder nee zeggen je kost. Het is dezelfde discipline als in de rest van de lus, alleen op het punt waar nee zeggen nog gratis is.

Plan mode levert je een document, een pauze, en een eerste versie van de redenering van iemand anders. De beslissing blijft waar hij altijd al lag. Wat je in die pauze doet, dat is het werk.