De plan-instantiate-learn loop: zo wordt elke AI-sessie beter

De meeste mensen gebruiken Claude Code als een los hulpmiddel. Ze starten een sessie, krijgen output, en beginnen de volgende keer weer vanaf nul. Dat werkt, maar het is alsof je elke dag opnieuw een stagiair inwerkt. Met de plan-instantiate-learn loop bouw je een AI workflow die zichzelf verbetert. Elke sessie wordt sneller, goedkoper en nauwkeuriger dan de vorige.

In ons CLAUDE.md systeemprompt artikel legden we uit hoe je CLAUDE.md opzet als levend document. Dit artikel gaat een stap verder. Hier leer je het concrete, stapsgewijze framework waarmee je dat document continu aanscherpt.

Wat is de plan-instantiate-learn loop precies?

De loop is een cyclus van drie fasen die je herhaalt bij elke feature, elk artikel of elke taak die je met Claude Code uitvoert.

1. Plan. Je beschrijft wat er moet gebeuren. Niet vaag ("maak dit beter"), maar concreet: welke feature, welke acceptatiecriteria, welke beperkingen. Je geeft Claude de context die het nodig heeft om goede beslissingen te nemen.

2. Instantiate. Claude voert het plan uit. Tijdens deze fase gaat er van alles goed en fout. Claude maakt keuzes die je niet verwachtte. Het loopt vast op edge cases. Het vindt oplossingen die slimmer zijn dan wat jij had bedacht. Al deze momenten zijn data.

3. Learn. Na de uitvoering compileer je alle learnings. Wat werkte? Wat niet? Welke instructie was onduidelijk? Welke fout kwam door ontbrekende context? Je destilleert die inzichten tot compacte, tokenefficiënte regels en werkt je CLAUDE.md bij.

Dan begin je weer bij stap 1. Maar nu met een slimmere systeemprompt.

Hoe ziet de planfase eruit in de praktijk?

De planfase bepaalt 80% van het resultaat. Toch besteden de meeste mensen er de minste tijd aan.

Een goede planning voor Claude Code bevat drie elementen:

1. Het doel. Wat moet er aan het einde bestaan? Niet "verbeter de homepage", maar "voeg een stats-sectie toe onder de hero met drie KPIs uit de Cloudinary API".
2. De randvoorwaarden. Welke technische keuzes liggen vast? Welke bestanden mag Claude niet aanpassen? Welke conventies gelden er?
3. Het succescriterium. Hoe weet je dat het klopt? "De build slaagt zonder fouten" of "de component rendert correct op mobiel en desktop".

Stel, een developer bij een marketingbureau bouwt een contentpipeline met Claude Code. In sessie 1 beschrijft die alleen "maak een script dat blogposts genereert". Claude levert iets op, maar de output matcht niet met het CMS-schema, de toon klopt niet, en de frontmatter mist verplichte velden. Frustrerend? Ja. Maar ook waardevol. Want nu weet je precies wat je in de planfase moet specificeren.

In sessie 2 staat in de CLAUDE.md:

## Content generatie
- Frontmatter moet bevatten: title, slug, publishedAt, description, author
- Toon: informeel, "je/jij", korte zinnen (max 30 woorden)
- Categorie moet matchen met bestaande categories in content/nl/categories/

Dat is het verschil tussen vaag plannen en plannen op basis van ervaring.

Wat leer je tijdens de instantiate-fase?

De instantiate-fase is waar de meeste learnings ontstaan. Claude voert je plan uit en laat daarbij precies zien waar je instructies tekortschieten.

Er zijn vier categorieën learnings:

Missende context. Claude maakt een aanname die niet klopt, omdat jij iets niet hebt vermeld. Bijvoorbeeld: het gebruikt queryContent() terwijl je project queryCollection() vereist. Die fout vertelt je dat je CLAUDE.md een regel mist over de content API.

Onverwachte oplossingen. Soms vindt Claude een betere aanpak dan wat jij in gedachten had. Een developer die een formuliervalidatie bouwt, ontdekt dat Claude Zod-schema's voorstelt in plaats van handmatige checks. Als dat patroon werkt, voeg je het toe aan je CLAUDE.md als voorkeursmethode.

Herhaalde fouten. Als Claude dezelfde fout twee keer maakt, is dat een signaal. Niet dat Claude slecht is, maar dat je systeemprompt een gat heeft. Documenteer het patroon en de correctie.

Performance-observaties. Sommige instructies kosten veel tokens maar leveren weinig op. Andere zijn compact maar hebben grote impact. Na een paar sessies krijg je gevoel voor de verhouding.

Stel dat een contentmanager bij een SaaS-bedrijf Claude gebruikt om wekelijkse nieuwsbrieven te genereren. In sessie 3 valt op dat Claude steeds een te formele aanhef gebruikt, ondanks de instructie "schrijf informeel". De learning: "informeel" is te vaag. De CLAUDE.md krijgt een concreet voorbeeld: "Begin met een directe zin over het onderwerp. Geen 'Beste lezer' of 'In deze editie'."

Hoe compileer je learnings zonder je tokenlimiet op te blazen?

Dit is de stap die de meeste mensen overslaan, en waar het meeste waarde zit.

Na elke sessie heb je een chatgeschiedenis vol fouten, correcties en doorbraken. Die hele geschiedenis meenemen naar de volgende sessie is onbetaalbaar (letterlijk, in tokens). Je moet die learnings comprimeren tot de essentie. Meer over hoe je tokenkosten bespaart met kenniscompressie.

Drie principes voor goede compilatie:

1. Eén regel per learning. Niet een heel verhaal over waarom iets fout ging. Alleen de instructie die het voorkomt.

Slecht:

We ontdekten dat Claude de neiging heeft om style blocks te gebruiken
in Vue componenten, terwijl we Tailwind utility classes willen.
Na drie pogingen hebben we dit opgelost door...

Goed:

Geen <style> blocks in Vue componenten. Alleen Tailwind CSS utility classes.

2. Groepeer per domein. Zet TypeScript-regels bij TypeScript. Content-regels bij content. Dat maakt je CLAUDE.md scanbaar, zowel voor jou als voor Claude.

3. Verwijder wat overbodig is. Als een learning na vijf sessies nooit meer relevant was, haal het weg. Je CLAUDE.md moet lean blijven. Elke regel kost tokens bij elke sessie.

Hieronder een voorbeeld van hoe een leansectie eruitziet na tien sessies:

## Vue componenten
- Altijd <script setup lang="ts">
- Props met TypeScript interfaces en withDefaults
- Geen <style> blocks, alleen Tailwind
- Gebruik Nuxt UI v4 components voor standaard UI-elementen

Vier regels. Compact. Maar ze voorkomen tientallen fouten per sessie.

Wat is het verschil tussen sessie 1 en sessie 10?

Het verschil is dramatisch, en meetbaar.

Sessie 1: Claude kent je project niet. Het maakt generieke keuzes. Je corrigeert meer dan je accepteert. De output is 60% bruikbaar. Je besteedt net zoveel tijd aan correcties als aan het reviewen van werkende code.

Sessie 5: Je CLAUDE.md bevat 20-30 compacte regels. Claude volgt je conventies, kent je stack, en maakt minder foutieve aannames. De output is 80-85% bruikbaar. Correcties zijn klein: een variabelenaam hier, een edge case daar.

Sessie 10: Je CLAUDE.md is een compact maar krachtig document. Claude voelt als een teamlid dat je project kent. De output is 90-95% bruikbaar. Je review gaat sneller dan zelf schrijven. De kosten per feature zijn gehalveerd ten opzichte van sessie 1.

Dit is geen theorie. Wij gebruiken deze loop dagelijks voor deze website. Onze CLAUDE.md is gegroeid van een handvol regels naar een gestructureerd document met secties voor TypeScript, Vue, content, SEO en deployment. Elke sectie is het resultaat van een concreet probleem dat we tegenkwamen en oplosten.

De investering zit in de eerste vijf sessies. Daarna versnelt alles.

Welke fouten maken mensen bij het iteratief verbeteren?

Er zijn drie veelvoorkomende fouten die de loop saboteren.

1. Nooit updaten. De meest voorkomende fout. Je runt sessie na sessie met dezelfde CLAUDE.md en verwacht dat Claude beter wordt. Dat gebeurt niet. Claude heeft geen geheugen tussen sessies. De enige manier om learnings mee te nemen is via je systeemprompt.

2. Te agressief updaten. Het tegenovergestelde: na elke sessie twintig nieuwe regels toevoegen. Je CLAUDE.md groeit naar duizenden woorden. Het kost steeds meer tokens om te lezen. En Claude raakt in de war door tegenstrijdige of overlappende instructies. Minder is meer. Houd je regels scherp en verwijder wat niet bijdraagt.

3. Symptomen documenteren in plaats van patronen. "Gebruik geen komma na het woord 'maar' in regel 47 van bestand X" is een symptoom. "Volg de Nederlandse spelling- en schrijfregels" is een patroon. Zoek altijd het onderliggende principe. Eén goede regel vervangt tien specifieke correcties.

Een bonus-fout: learnings niet testen. Als je een regel toevoegt aan je CLAUDE.md, verifieer dan in de volgende sessie of Claude hem ook daadwerkelijk opvolgt. Soms is de formulering te vaag, of staat de regel op een plek die Claude weinig gewicht geeft.

Hoe begin je vandaag met de loop?

Je hebt geen uitgebreide setup nodig. Begin met drie stappen.

Stap 1: Start je volgende sessie met een plan. Schrijf voordat je Claude opent drie zinnen op: wat moet er gebeuren, wat zijn de randvoorwaarden, en wanneer is het klaar.

Stap 2: Houd een notitie bij tijdens de sessie. Elke keer dat je iets corrigeert of iets onverwachts ziet, noteer je het. Eén zin per observatie is genoeg.

Stap 3: Compileer na de sessie. Neem vijf minuten om je notities te vertalen naar compacte regels. Voeg ze toe aan je CLAUDE.md op de juiste plek.

Dat is alles. Na vijf sessies heb je een CLAUDE.md die daadwerkelijk waarde toevoegt. Na tien sessies werk je sneller dan je ooit zonder de loop deed.

Wil je dieper duiken in hoe je CLAUDE.md opbouwt? Lees dan ons artikel over CLAUDE.md systeemprompt voor de complete structuur. En als je benieuwd bent hoe claude skills in dit plaatje passen: skills zijn de herbruikbare bouwstenen die je CLAUDE.md aanroept.