Plan Mode in Claude Code: stapsgewijze handleiding en 4 fasen in 2026

Meer instructies vind je in de Ailoot-documentatie.

Wat is Plan Mode en waarom is het op zichzelf niet genoeg?#

In de normale modus schrijft Claude Code meteen code, en als je niet oplet, kun je onverwacht een diff over veel bestanden krijgen. Plan Mode draait de volgorde om: eerst onderzoeken en plannen, dan goedkeuring, daarna wijzigingen.

Anthropic beschrijft Plan Mode in de officiële documentatie als volgt:

Dat klinkt eenvoudig, maar verbergt de belangrijkste verandering. Plan Mode verandert het werkritme: eerst overeenstemming, dan actie. Het is een andere modus, geen cosmetische aanpassing. Het probleem voor vibe-coders is dat AI-agenten de neiging hebben zich te haasten. Vraag je in de normale modus om “Google-authenticatie toe te voegen”, dan schrijft Claude binnen een minuut code, maar de helft van de bestanden is verkeerd. In Plan Mode wordt hetzelfde verzoek een tekstueel plan dat je in twee minuten kunt lezen en corrigeren voordat er code wordt aangeraakt.

Er is een valkuil waar internationale gidsen niet over schrijven. Plan Mode op zichzelf is een zwak hulpmiddel: het plan bestaat alleen in het huidige gesprek. Sluit je het venster, dan is het plan weg. Je kunt het niet overdragen aan een andere agent. Er zijn geen versies of geschiedenis. Bij een grote taak (een module met 30 bestanden refactoren, migreren naar een nieuwe database) bereikt het plan al snel de limiet van het contextvenster en gaat de kwaliteit achteruit.

Daarom werkt Plan Mode goed samen met een map plans/ in de repository. Het plan wordt opgeslagen als plans/2026-05-21-google-oauth.md, opgedeeld in fasen met selectievakjes, zodat iedere volgende agent ermee verder kan. Zo werkt context engineering: context beheren voordat je de prompt geeft, niet tijdens het gesprek.

Hoe schakel je Plan Mode in Claude Code in?#

De snelste manier tijdens een sessie is via het toetsenbord:

Shift+Tab           # wisselt tussen modi: default → acceptEdits → plan

Na twee keer drukken verschijnt onderaan de terminal de indicator ⏸ plan mode on. Druk een derde keer om terug te keren naar de normale modus. Dit is de handigste methode: je schakelt de modus onderweg in zodra je merkt dat de taak groter wordt.

De tweede methode is een voorvoegsel voor één prompt:

/plan write a plan to migrate the database from MySQL to Postgres

Dit is handig als je de modus voor automatisch accepteren gebruikt en die niet voor de hele sessie wilt veranderen. Eén verzoek in Plan Mode, daarna gaat het werk verder zoals voorheen.

De derde methode is bij het starten van een sessie:

claude --permission-mode plan

Gebruik dit als je vooraf weet dat een taak planning nodig heeft, bijvoorbeeld vóór een grote refactor of migratie.

De vierde methode is de standaardmodus instellen in .claude/settings.json van het project:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Wanneer is dit nuttig? Als een team werkt aan een complex systeem waarin elke wijziging invloed kan hebben op aangrenzende modules. De standaardmodus Plan Mode beschermt iedereen dan tegen onbedoelde wijzigingen.

Een vijfde truc die vaak over het hoofd wordt gezien: Ctrl+G opent het plan in een teksteditor. Gebruik dit als het plan bijna goed is, maar je 2-3 punten anders wilt formuleren of een beperking wilt toevoegen. Bewerk het handmatig en sla het op; Claude gaat dan verder met jouw versie.

Wat zijn de canonieke 4 fasen van Anthropic voor Plan Mode: Explore, Plan, Implement, Commit?#

Veel gidsen beschrijven 3 fasen (Explore-Plan-Execute) of slechts 2 (Plan-Implement). Dat zijn vereenvoudigingen. In de officiële gids met best practices beschrijft Anthropic precies 4 fasen. Dat verschil is belangrijk: door Commit als aparte fase op te nemen, leg je het resultaat vast in plaats van het te laten bij “ik heb nog een paar dingen aangepast, ik commit later wel” — de meest voorkomende oorzaak van verloren werk.

Hoe nauwkeuriger het plan, hoe minder iteraties de implementatie nodig heeft. Besteed je 10 minuten aan het plan, dan kost de implementatie één prompt. Schets je het plan in een minuut, dan ben je een uur bezig met verbeteringen.

Zo zien de 4 fasen eruit voor het toevoegen van Google OAuth (een voorbeeld uit Anthropic Docs):

De prompts verschillen ook per fase. In Explore: “Lees /src/auth en begrijp hoe we sessies en inloggen afhandelen.” In Plan: “Ik wil Google OAuth toevoegen. Welke bestanden moeten veranderen? Maak een plan.” In Implement: “Implementeer de OAuth-flow uit je plan, schrijf tests, voer de suite uit en los fouten op.” In Commit: “Maak een commit met een beschrijvende melding en open een PR.”

Een belangrijk detail: Plan Mode voorkomt niet dat Claude opdrachten uitvoert voor onderzoek. Read, LS, Glob, Grep, web fetch en shellopdrachten voor verkenning zijn toegestaan. Alleen Edit, Write en alle bewerkingen die het bestandssysteem wijzigen, zijn verboden. Claude kan dus de projectstructuur lezen, git log uitvoeren en tests bekijken, maar kan niet per ongeluk iets veranderen.

Hoe lees je Claude’s plan en beslis je of je het goedkeurt?#

Wanneer Claude klaar is met het maken van een plan, toont het opties voor wat je hierna kunt doen:

• Goedkeuren en starten in de automatische modus
• Goedkeuren en wijzigingen accepteren
• Goedkeuren en elke wijziging handmatig beoordelen
• Verder plannen met feedback
• Verfijnen met Ultraplan (beoordeling in de browser)

Weten of je een plan moet goedkeuren is de belangrijkste vaardigheid in Plan Mode. Het is makkelijk om automatisch op “Approve” te drukken en daarna commits te moeten terugdraaien. De AI-vleier wil snel antwoord geven, en jij wilt sneller naar de code. Jullie hebben allebei ongelijk.

Een goed plan voldoet aan 7 criteria:

1. Specifieke bestandsnamen. Niet “ik werk auth bij”, maar “ik wijzig src/auth/login.ts:42-58, maak src/auth/oauth-callback.ts aan en werk src/auth/session.ts:103 bij.”
2. De volgorde is vastgelegd. Het plan is verdeeld in fasen of stappen, niet “ik doe dit allemaal ergens”.
3. Externe afhankelijkheden worden genoemd. Als de taak een nieuwe bibliotheek vereist, staat die vermeld. Als er omgevingsvariabelen nodig zijn, worden die genoemd.
4. Risico’s staan vermeld. Een goed plan zegt: “De migratie kan bestaande sessies breken; X moet worden gecontroleerd.” Een slecht plan zwijgt over neveneffecten.
5. Er zijn succescriteria. “De tests in test/auth slagen, de linter geeft geen fouten en de ontwikkelserver start zonder fouten.”
6. Er zijn geen aannames die uit de lucht zijn gegrepen. Als Claude zegt “ik gebruik bibliotheek Z”, controleer dan: heb je die wel in het project geïnstalleerd? Als de AI het heeft verzonnen, zie je dat het niet in package.json staat.
7. Het plan past op het scherm. Als een eenvoudig onderdeel een plan van 200 regels oplevert, is de taak waarschijnlijk te groot voor één plan. Verdeel die in delen.

Als een plan de controle niet doorstaat, zijn er drie opties:

• Verder plannen met feedback — geef Claude een specifieke opmerking over wat je niet bevalt, zodat het plan wordt herschreven.
• Ctrl+G — open het plan in een editor, bewerk het handmatig en sla het op. Claude gaat verder met jouw versie.
• Verfijnen met Ultraplan — het plan gaat naar de browsermodus van Claude Code op het web. Daar beoordeel je onderdelen en geef je opmerkingen, waarna je het lokaal of in de cloud uitvoert.

Als er tijdens de implementatie iets misgaat, forceer het dan niet. Ga terug naar Plan Mode en herschrijf het plan. Dat is 10 keer goedkoper dan later 40 commits terugdraaien.

Plan Mode + een map plans/: een combinatie voor lange context#

Plan Mode is een modus van Claude Code. De map plans/ is een methode die erop voortbouwt. Als je Plan Mode zonder map gebruikt, bereik je na een uur werken de limiet.

Zo zit het. Claude’s contextvenster is het geheugen van de sessie. In Opus 4.7 past er 1 miljoen tokens in, maar dat is de omvang van je volledige gesprek. Plan je een complexe taak in één gesprek, vraag je daarna om de implementatie, bespreek je vervolgens een bug en ga je dan nog ergens anders op in, dan raakt het venster “opgeblazen”. Claude begint eerdere beslissingen te vergeten, contexten door elkaar te halen en vragen opnieuw te stellen.

De oplossing is de gouden regel: één taak — één gesprek.

Zo doe je dat:

1. Gesprek 1 — het plan opstellen. Schakel Plan Mode in, beschrijf de taak en Claude maakt een plan. Sla het op in plans/2026-05-21-feature-name.md. Sluit het venster.
2. Gesprek 2 — het in fasen verdelen. Open een nieuwe chat. Vraag: “neem plans/2026-05-21-feature-name.md en verdeel het in fasen.” Sla het bijgewerkte bestand op.
3. Gesprek 3 — fase 1 uitvoeren. Open een nieuwe chat. Vraag: “voer fase 1 uit plans/2026-05-21-feature-name.md uit en vink punten af zodra je ze hebt afgerond.” Sluit het venster.
4. Gesprek 4 — fase 2 uitvoeren. Doe hetzelfde.

Wat levert dit op? Het contextvenster van elk gesprek blijft fris. Claude in fase 3 kent de details van fase 1 niet, maar kent het plan omdat het bestand plans/ in de repository staat. Elke volgende agent (een subagent, een nieuwe sessie of een run via /goal) kan het plan oppakken en verdergaan.

Vergelijking van de aanpakken:

Elke functie heeft een eigen planningsbestand. Als je drie maanden later wilt weten waarom je de ene betalingsprovider boven een alternatief hebt gekozen, kun je het relevante plan openen en de beslissingsgeschiedenis lezen: wat is besproken, welke opties zijn overwogen en waarom juist deze aanpak is gekozen.

Dit zijn levende werkplannen; statische documentatie veroudert binnen enkele maanden.

Hoe kun je Claude met Plan Mode en /goal laten werken terwijl jij slaapt?#

De belangrijkste beperking van lange AI-sessies is niet het model zelf, maar de persoon die op Enter drukt. Telkens als Claude het einde van een beurt bereikt, wacht het op jouw antwoord. /goal haalt dat wachten weg.

De syntaxis is eenvoudig:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

De voorwaarde mag maximaal 4000 tekens lang zijn. Eén doel per sessie. Na elke beurt bekijkt het Haiku-mini-model het transcript en beslist: “voorwaarde bereikt — afronden” of “niet bereikt — volgende beurt”. De evaluator roept geen hulpmiddelen aan; het leest alleen.

Aliassen om het doel te wissen: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

De combinatie met Plan Mode ziet er zo uit:

1. Schakel Plan Mode in (druk twee keer op Shift+Tab).
2. Vraag: “maak een plan om de database van MySQL naar Postgres te migreren en sla het op in plans/2026-05-21-postgres-migration.md met fasen en criteria.”
3. Bekijk het plan, bewerk het en keur het goed.
4. Verlaat Plan Mode (druk nogmaals op Shift+Tab).
5. Stel een doel in: “voltooi alle fasen in plans/2026-05-21-postgres-migration.md, vink de vakjes af, alle tests slagen, of stop na 50 beurten.”
6. Sluit je laptop en ga slapen.

Controleer ’s ochtends het resultaat: “✓ doel voltooid” of “◎ gestopt na 50 beurten”, met een geschiedenis van wat er is gedaan.

Er zijn drie essentiële regels voor /goal, anders verspil je tokens:

Regel 1: Een meetbare eindtoestand. “Maak het mooi” is slecht. “npm test geeft 0 terug, npm run lint geeft 0 terug en er is een regel toegevoegd aan CHANGELOG.md” is goed.

Regel 2: Expliciete verificatie. De voorwaarde moet verwijzen naar iets dat te controleren is: een opdracht, bestand of endpoint. Niet “alles werkt”, maar “curl localhost:3000/api/users retourneert 200”.

Regel 3: Beperk het aantal beurten. Voeg altijd or stop after N turns toe. Anthropic beveelt dit expliciet aan in de documentatie:

Als je /goal zonder or stop after inschakelt, kan je budget ’s nachts verdwijnen.

Welke cyclus van 4 stappen maakt Plan Mode tot een engineeringproces?#

Een veelgemaakte fout is vragen “hoe los ik dit op?”: Claude geeft een oplossing, jij past die toe, maar niets werkt of het wordt erger. Dit is de “AI-vleier”: die is getraind om snel antwoord te geven en jij wilt sneller bij de code komen. Een cyclus van 4 stappen pakt dit aan.

De cyclus van 4 stappen blokkeert deze modus. Je doorloopt de stappen achtereenvolgens in één Plan Mode-sessie:

Stap 1. Stel feiten vast zonder een oplossing te geven.

Prompt: “Ik ervaar het volgende: [beschrijving van het symptoom]. Je taak is nu de feiten vast te stellen. Oplossingen, ideeën en adviezen zijn verboden. Alleen: wat ik waarneem, welke stappen reproduceerbaar zijn, welke gegevens beschikbaar zijn en welke gegevens ontbreken. Strikte stopvoorwaarde: stel GEEN oplossingen voor; leg alleen de diagnose vast.”

Dit blokkeert de eerste impuls van de AI: “hier is de oplossing”. Claude moet stoppen bij “wat bekend is en wat onbekend is”.

Stap 2. Ontwikkel opties met voorbeelden.

Prompt: “Nu de diagnose is vastgesteld, zoek online naar voorbeelden van oplossingen voor vergelijkbare problemen. Minstens 3 verschillende aanpakken. Vermeld bij elke aanpak: een link naar de primaire bron, een korte beschrijving en voor- en nadelen voor onze situatie.”

Dit blokkeert de tweede impuls van de AI: “zelf zomaar een oplossing verzinnen”. We laten de AI naar buiten gaan en terugkomen met aanpakken die we kunnen controleren.

Stap 3. Gedetailleerd plan met risico’s.

Prompt: “Neem de beste optie uit stap 2 en werk een gedetailleerd plan uit: welke specifieke bestanden moeten worden aangeraakt, wat moet worden toegevoegd, wat moet worden verwijderd, welke tests moeten worden geschreven, wat kan er kapotgaan en welke risico’s liggen 2-3 stappen verderop.”

Dit is de bekende Plan-fase, met één verschil: het plan is gebaseerd op de geverifieerde opties uit stap 2, niet op gissingen van Claude.

Stap 4. Controleer het plan zelf.

Prompt: “Voer nu verplicht een zelfcontrole uit. Controleer je plan eerlijk opnieuw: zijn er punten die uit de lucht zijn gegrepen en niet aan de hand van code, documentatie of een voorbeeld uit stap 2 zijn geverifieerd? Markeer ze dan en herzie het plan.”

Dit is het laatste filter. Claude moet zijn eigen redenering controleren en toegeven waar het heeft gehallucineerd. Meestal worden in deze stap minstens 2 punten van het plan aangepast.

Na de 4 stappen is het plan klaar voor goedkeuring. Je gaat met vertrouwen over naar de implementatie: de taak is begrepen, de opties zijn afgewogen en de risico’s zijn overwogen.

Deze methode is bedoeld om lastige bugs te diagnosticeren en architectuurbeslissingen te nemen, waarbij de kosten van een fout hoog zijn. Toegepast op Plan Mode neemt dit het belangrijkste probleem van vibe-coders weg: “de AI gaf me een oplossing, ik paste die toe en alles ging kapot”.

Welke 5 kant-en-klare prompts werken in Plan Mode voor veelvoorkomende taken?#

Sjabloon 1. Een module refactoren.

I'm enabling Plan Mode. Task: refactor the {module-name} module.

Step 1: Study the current structure of the {module-path} module. Describe:
- which files are part of the module
- which external dependencies it has
- which parts are duplicated
- which functions are overcomplicated

Step 2: Find 2-3 examples online of refactoring similar modules.
At least 1 source must be official Anthropic or related framework documentation.

Step 3: Create a refactoring plan in plans/YYYY-MM-DD-refactor-{module}.md:
- which files to rename
- which functions to extract into separate modules
- which tests to keep and which to rewrite
- risks: what could break for users

Step 4: Self-check. Are there any assumptions in the plan that are "pulled out of thin air"?
Rewrite or remove them.

Sjabloon 2. Een databasemigratie.

I'm enabling Plan Mode. Task: migrate the database from {old} to {new}.

Step 1: Study the current database schema using {schema-reading-command}. Describe:
- which tables exist and their size
- which relationships, indexes, and constraints there are
- where migrations are stored
- which data is critical

Step 2: Find precedents for {old → new} migrations in production projects.
At least 3 different approaches: pg_dump, dual-write, blue-green.
For each, list the pros and risks for our data size.

Step 3: Create a migration plan in plans/YYYY-MM-DD-db-migration.md:
- phases (backup, migration, verification, switchover)
- success criteria for each phase
- rollback plan if something goes wrong
- downtime or no downtime

Step 4: Self-check. Are all figures supported by documentation?
Have all steps been mentally checked against the dev environment?

Sjabloon 3. Een nieuwe functie toevoegen.

I'm enabling Plan Mode. Task: voeg de functie {description} toe aan het project.

Step 1: Study how similar features currently work in the project.
Specifically, look at:
- {file-1}
- {file-2}
- which architectural patterns are used
- which tests are written for similar features

Step 2: Find how this feature is implemented in open-source projects
with a similar architecture. At least 2 different approaches.

Step 3: Create a plan in plans/YYYY-MM-DD-feature-{name}.md:
- list of new files
- list of changed files with specific lines
- implementation sequence
- which tests to add
- what to add to CLAUDE.md as a rule for future sessions

Step 4: Self-check. Does the plan follow the project's architecture?
Does it assume libraries that haven't been installed yet?

Sjabloon 4. Tests schrijven.

I'm enabling Plan Mode. Task: cover the {name} module with tests.

Step 1: Study the {path} module. Identify:
- public functions and their signatures
- internal functions we will NOT test (implementation details)
- edge cases: empty input, errors, concurrent access

Step 2: Find test examples for a similar class of tasks
in popular open-source projects using the same framework.

Step 3: Create a test plan in plans/YYYY-MM-DD-tests-{module}.md:
- for each public function, a list of tests
- which mocks are needed
- which fixtures
- which verification approach (assertion style)

Step 4: Self-check. Do all tests check behavior rather than implementation?
Does the coverage include edge cases?

Sjabloon 5. Een complexe fout debuggen.

I'm enabling Plan Mode. Task: understand the cause of the error {symptom-description}.

Step 1: ESTABLISH THE FACTS. Solutions and ideas are prohibited. Only:
- what I observe (exact wording of the error)
- reproducible steps
- what data is available (logs, traces, library versions)
- what data is missing (what needs to be collected additionally)

Step 2: Find precedents for this error.
At least 3 sources: GitHub issues, documentation, and another relevant source.
For each, provide a link and a brief summary of the solution.

Step 3: Create a diagnostic plan in plans/YYYY-MM-DD-bug-{name}.md:
- which hypotheses to check (sorted by likelihood)
- which commands/scripts to run to check each one
- the expected result of each check

Step 4: Self-check. Are there any hypotheses in the plan that are "pulled out of thin air"?
Are all hypotheses tied to facts from Step 1?

Kopieer elk sjabloon, vervang {parameters} door je eigen waarden en plak het in Claude Code in Plan Mode. Het resultaat is een bruikbaar plan in plans/ dat je kunt goedkeuren en gebruiken voor de implementatie.

Plan Mode versus de normale modus: welke kies je?#

Anthropic zegt dit rechtstreeks in de documentatie:

Sla een apart plan alleen over wanneer de echte diff klein, begrepen en laag in risico is. Plan wanneer je de aanpak moet ontdekken of riskante wijzigingen tussen componenten moet afstemmen. Bestandsnamen kennen of het doel in één zin samenvatten neemt migratie-, authenticatie- of gegevensintegriteitsrisico’s niet weg.

Beslissingstabel:

Vraag vóór de moduskeuze of aanpak, neveneffecten en controle duidelijk zijn. Werk direct aan een kleine lokale wijziging met laag risico en een voor de hand liggende controle. Plan eerst bij onzekerheid, onbekende code, migratie, authenticatie of afstemming tussen componenten, ook als je alle 3-5 betrokken bestanden al kunt noemen.

Hoe combineer je Plan Mode + CLAUDE.md + subagenten voor betrouwbaar werk?#

CLAUDE.md is een bestand dat Claude aan het begin van elke sessie leest, ook in Plan Mode. Staat er in CLAUDE.md “hardcode nooit datums; haal ze altijd uit de database”, dan zal het plan nooit voorstellen datums hard te coderen. Zonder zo’n regel kan het plan van alles voorstellen.

De combinatie werkt als volgt:

Laag 1. CLAUDE.md legt de regels vast.

Het bestand beschrijft de projectstack, architectuurprincipes, verboden (“gebruik geen verouderde API’s”) en vereisten (“alle e-mails gebruiken een gedeelde lay-out”). Uitgebreide gids: CLAUDE.md configureren.

Laag 2. Plan Mode past de regels toe op de taak.

Wanneer je Plan Mode inschakelt en “voeg OAuth toe” vraagt, leest Claude CLAUDE.md, ziet de regels (“bewaar tokens in Redis, niet in de database”) en neemt ze meteen mee in het plan. Het plan sluit aan op de architectuur van het project.

Laag 3. Subagenten verdelen het werk.

Als het plan in fasen is verdeeld, kan elke fase aan een aparte subagent worden toegewezen. Elke subagent werkt in een eigen contextvenster zonder het hoofdvenster te vullen. Het plan in plans/ blijft de centrale bron van waarheid: subagenten lezen het, voeren hun fase uit en werken de selectievakjes bij.

Welke 7 fouten maken Plan Mode onbruikbaar?#

Fout 1. Het plan bestaat alleen in de chat.

Symptoom: je schreef een plan, sloot het venster en wilt er de volgende dag op terugkomen, maar er is niets; de context is weg. Oplossing: sla het plan altijd op in plans/YYYY-MM-DD-feature-name.md in de repository. De chat is een bureau; het bestand is een archief.

Fout 2. Alle taken staan in één chat.

Symptoom: in één sessie bespreek je auth, daarna een migratie, vervolgens UI-ontwerp en dan een bug. Het contextvenster raakt “opgeblazen” en Claude vergeet eerdere dingen. Oplossing: één taak — één gesprek. Klaar met het plan? Sluit het venster. Begin je aan de implementatie? Open een nieuw venster.

Fout 3. Eén plan van 3000 regels zonder fasen.

Symptoom: er is een plan, maar zonder selectievakjes of indeling. Je kunt onmogelijk zien wat af is en wat niet. Delegeren kan niet. Oplossing: verdeel elk plan in 3-7 fasen. Elke fase is een lijst met selectievakjes voor specifieke acties.

Fout 4. Geen diepgaand onderzoek voordat je het plan maakt.

Symptoom: Claude verzint zelf een oplossing omdat je niet hebt gevraagd naar voorbeelden. Een week later ontdek je dat er in open source al lange tijd een betere aanpak bestaat. Oplossing: stap 2 van de cyclus van 4 stappen — laat Claude online 2-3 voorbeelden zoeken voordat het een plan maakt.

Fout 5. De AI-vleier geeft een oplossing zonder diagnose.

Symptoom: je vraagt “hoe los ik fout X op?”, Claude geeft een oplossing, je past die toe en niets werkt of het wordt erger. Oplossing: begin altijd met “stel de feiten vast; oplossingen zijn verboden”. Ga pas na de diagnose verder met opties.

Fout 6. De zelfcontrole overslaan.

Symptoom: het plan lijkt aannemelijk, maar bevat 2-3 aannames die uit de lucht zijn gegrepen (een verzonnen bibliotheek, een niet-bestaande API of een verkeerde versie). De implementatie loopt daarop stuk. Oplossing: stap 4 van de cyclus van 4 stappen — laat Claude het plan eerlijk opnieuw controleren en aannames markeren.

Fout 7. Vage voorwaarden in /goal.

Symptoom: je stelt /goal make it look nice in, laat het ’s nachts draaien en wordt wakker met $200 minder quotum. Oplossing: gebruik alleen meetbare voorwaarden met een verificatieopdracht en een verplichte or stop after N turns. Geen “maak het goed” of “werk het bij”.

De achtste fout, die vibe-coders het vaakst maken, is het hele idee van een map plans/ negeren. Plan Mode zonder map plans/ is geen methode, maar speelgoed. Gebruik je Plan Mode maar maak je geen bestanden aan, dan benut je 10% van de mogelijkheden.

Wat moet je na je eerste ervaring met Plan Mode doen?#

Drie concrete stappen, oplopend in moeilijkheid:

Stap 1. Configureer CLAUDE.md als je die nog niet hebt.

Zonder CLAUDE.md werkt Plan Mode “in een vacuüm”: Claude kent de projectregels niet en stelt plannen voor die de architectuur breken. Volledige gids: CLAUDE.md configureren. Een minimale CLAUDE.md telt 50-80 regels en beschrijft de stack, regels en verboden. De lengte is ondergeschikt; specificiteit is wat telt.

Stap 2. Maak een map plans/ in de repository.

Voeg een map plans/ toe aan de hoofdmap van het project. Spreek een naamgevingsformaat af: YYYY-MM-DD-feature-name.md. Elk plan krijgt een eigen bestand. Na een maand heb je 20-30 bestanden; na zes maanden 100+. Dat is een levende geschiedenis van de beslissingen in het project.

Stap 3. Probeer /goal voor één taak.

Kies een taak die je normaal gesproken 30-40 minuten handmatig doet. Schakel Plan Mode in, maak een plan en sla het op in plans/. Verlaat Plan Mode. Stel in: /goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns. Sluit je laptop een uur en ga iets anders doen. Kom terug en controleer het resultaat.

Die drie stappen zijn het minimum. Dit bouw je geleidelijk op; probeer niet alles in één avond samen te brengen. Begin met CLAUDE.md, voeg na een week plans/ toe en probeer na een maand /goal ’s nachts.

Als je er klaar voor bent, maak kennis met Ailoot.