Waarom Claude het verkeerde doet: 3 prompts
MarkdownClaude maakt het verkeerde omdat het meteen code gaat schrijven zonder je bedoeling te begrijpen. Ik leg uit waarom en geef je 3 kant-en-klare prompts waarmee je het eerst vragen laat stellen.
Lees het volledige artikel
Belangrijkste punt
Claude maakt het verkeerde omdat het meteen code gaat schrijven en zelf invult wat het denkt dat je bedoelt. Vaak heeft het dat mis. Het probleem ligt bijna nooit aan het model — zelfs het sterkste model mist zijn doel bij een vage opdracht. Ik los dit in één stap op: ik laat Claude me eerst interviewen, mijn bedoeling achterhalen en pas daarna schrijven. Hieronder staan drie kant-en-klare prompts die je kunt kopiëren en plakken.
Lees voor meer informatie over het gebruik van de dienst de Ailoot-documentatie.
Waarom doet Claude het verkeerde?
Belangrijkste punt
Claude krijgt een kort verzoek, vult meteen de ontbrekende onderdelen in en begint code te schrijven op basis van zijn eigen interpretatie van de taak. Die interpretatie verschilt van de jouwe. Zo eindig je met een diff die 14 bestanden raakt, terwijl je een wijziging van één regel verwachtte. De oorzaak is het verschil tussen wat je zei en wat je bedoelde. Het model heeft er bijna niets mee te maken.
Je schrijft: “Voeg filters toe aan de productpagina.” In je hoofd betekent dat een paar selectievakjes en een bijgewerkte lijst. Claude hoort hetzelfde en besluit een compleet filtersysteem te bouwen: een eigen state store, aparte logica voor invoervertraging, synchronisatie met de URL en een dozijn hulpfuncties. Honderden regels waar een paar URL-parameters genoeg waren geweest.
In zo’n geval is de conclusie duidelijk: de agent maakte geen fout; hij loste gewoon een veel groter probleem op dan nodig was. De fout zat erin dat de gewenste uitkomst niet kort en precies genoeg was beschreven.
Het sleutelwoord is ‘bedoeling’. Jij hebt die in je hoofd; Claude niet. Het ziet de tekst van je verzoek en alles in de context tot aan dat verzoek. Daarna vult het de gaten met aannames. Hoe korter het verzoek, hoe meer aannames het doet — en hoe verder het resultaat af komt te staan van wat je wilde.
Anthropic zegt dit duidelijk in de Claude Code-documentatie:
Als je Claude meteen code laat schrijven, kan het het verkeerde probleem oplossen.
Ik liep hier zelf tegenaan in mijn project. Ik vroeg om een reparatie op één autorisatiescherm en kreeg een diff die de helft van een aangrenzende module raakte. Claude was niet de schuldige: ik gaf het één regel en het vulde de rest zelf in. Sindsdien begin ik elke taak die groter is dan een typefout met vragen — die Claude mij stelt.
Ligt het echt aan het model — en waarom missen zelfs de sterkste modellen hun doel?
Belangrijkste punt
Het model is minder belangrijk dan mensen vaak denken. Bij een vage taak mist zelfs het sterkste model zijn doel: het krijgt dezelfde onvolledige instructies en vult de gaten met eigen aannames. Ontwikkelaars die hun agent onder controle houden, krijgen dezelfde resultaten met een topmodel als met een middenklasser. Het draait allemaal om hoe duidelijk je beschrijft wat je wilt. De kracht van het model is hier van ondergeschikt belang.
Elke week verschijnt er een model dat ‘slimmer’ is dan het vorige, en telkens voelt het alsof dit het moment is waarop AI ons eindelijk met een paar woorden zal begrijpen. Dat gebeurt niet. Een sterker model schrijft sneller code en kan beter overweg met complexe logica, maar kan nog steeds je gedachten niet lezen. Als de taak slecht is geformuleerd, krijg je iets dat prachtig is geschreven maar toch verkeerd is.
De conclusie voor jou is eenvoudig. Het nieuwste model najagen zodat het beter kan raden, is een doodlopende weg. Het is goedkoper en betrouwbaarder om te leren hoe je taken geeft zodat het niet hoeft te raden. Daar gaan we nu op in.
Wat is grilling en hoe lost het een misverstand met AI op?
Belangrijkste punt
Grilling is wanneer je AI je laat interviewen voordat het aan het werk gaat: het stelt gedetailleerde vragen over de taak totdat jullie tot een gedeeld begrip komen. Het doel is de communicatiekloof te dichten voordat de eerste regel code wordt geschreven.
Het klinkt tegenstrijdig. We gebruiken AI om dingen sneller gedaan te krijgen, en nu krijgen we te horen dat we het moeten afremmen en eerst vragen moeten laten stellen. Maar vijf minuten vragen vóór het coderen kunnen een uur aan reparaties achteraf besparen.
Het probleem is niet alleen dat je dingen slecht aan Claude hebt uitgelegd. Vaak heb je zelf nog niet goed over de taak nagedacht: met welke gevallen moet je rekening houden, waar liggen de grenzen, wat is het belangrijkst? Grilling haalt dit met vragen naar boven. Aan het einde van het gesprek heb je niet alleen een taak die de AI begrijpt, maar ook je eigen taak, eindelijk tot in detail uitgewerkt.
Zo werkt context engineering: het belangrijkste werk gebeurt vóór de prompt, niet tijdens het schrijven ervan. Je zoekt niet naar magische promptformuleringen; je legt vooraf uit wat Claude nodig heeft, totdat het het zonder extra uitleg begrijpt.
Hoe laat je Claude je eerst vragen stellen?
Belangrijkste punt
Geef Claude een korte beschrijving van de taak en vraag expliciet of het je wil interviewen voordat het begint: laat het vragen stellen over details, randgevallen en beperkingen, en alles daarna in een specificatiebestand zetten. Dit is de officiële aanbeveling van Anthropic — de Claude Code-documentatie bevat hiervoor een kant-en-klare prompttemplate. Kopieer die, pas de beschrijving aan en plak hem aan het begin van een sessie.
Anthropic staat deze aanpak niet alleen toe, maar raadt hem ook aan. De documentatie bevat een sectie met de titel “Laat Claude je interviewen”, inclusief een kant-en-klare prompt. Hier is een praktische versie:
Prompt
Prompt voor grilling — laat Claude je interviewen
Ik wil [korte beschrijving van de taak] bouwen.
Interview me uitgebreid voordat je code schrijft. Stel vragen over de implementatie, de interface, randgevallen, risico’s en afwegingen. Stel geen voor de hand liggende vragen — ga in op de lastige punten waar ik misschien nog niet over heb nagedacht.
Stel één vraag tegelijk en wacht op mijn antwoord. Stel bij elke vraag meteen je aanbevolen antwoord voor.
Ga door totdat we alles hebben behandeld. Stel daarna een volledige specificatie op in een bestand met de naam SPEC.md.
Drie details maken deze prompt nuttig in plaats van decoratief. Ten eerste: ‘één vraag tegelijk’. Als AI tien vragen tegelijk op je afvuurt, raak je overweldigd en antwoord je oppervlakkig. Ten tweede: ‘stel je antwoord voor’: je hoeft niet alles vanaf nul te bedenken; je kunt het ermee eens zijn of het corrigeren. Ten derde: ‘stel een specificatie op in een bestand’: de bedoeling die naar boven is gehaald, wordt een document dat niet verloren gaat.
Anthropic beschrijft de opbrengst in termen van inspanning:
De tijd die je besteedt aan het goed opstellen van de specificatie is waardevoller dan de tijd die je besteedt aan het volgen van de implementatie.
Open na het interview een nieuwe sessie en geef die de voltooide specificatie. Een schone context plus een duidelijk geformuleerde bedoeling — en Claude raakt bij de eerste poging het doel.
De techniek ‘bewijs me dat dit het beste plan is’
Belangrijkste punt
Laat AI niet alleen vragen stellen, maar ook zijn beslissing verdedigen. Ik voeg een eis toe aan de taak: bewijs dat het voorgestelde plan het beste is, en niet alleen het eerste dat in je opkomt, en dat er meerdere stappen vooruit is gedacht. Daardoor schakelt Claude van de modus ‘ik doe wel iets vergelijkbaars’ naar de rol van criticus, waarin het zijn eigen werk controleert voordat jij tijd in de implementatie steekt.
Grilling haalt je bedoeling naar boven. Maar AI heeft nog een tweede gewoonte: het grijpt naar de eerste oplossing die aannemelijk lijkt. Anthropic noemt dit de kloof van ‘vertrouwen maar verifiëren’: Claude levert een aannemelijke implementatie die in randgevallen niet standhoudt. De oplossing is om vóór de code om bewijs te vragen.
Als je het resultaat niet kunt controleren, dien het dan niet in.
Ik voeg bijna altijd een sectie ‘bewijs het’ toe aan mijn prompt. Dit is de exacte formulering:
Prompt
Prompt — laat AI zijn plan verdedigen
Analyseer de taak als een criticus voordat je code schrijft.
Bedenk 2-3 manieren om de taak op te lossen. Bewijs voor elke manier dat die mijn taak echt oplost, in plaats van alleen maar complexiteit toe te voegen. Schrijf geen code alleen om code te schrijven.
Kies daarna één manier en bewijs dat dit de beste oplossing is, waarbij je meerdere stappen vooruit hebt gedacht. Wat gaat er stuk als het project groeit? Wat zien we nu over het hoofd?
Stel pas daarna een implementatie voor.
Zonder deze sectie geeft Claude je de eerste werkbare optie. Met deze sectie schrapt Claude zelf de doodlopende wegen, legt het zijn keuze uit en kun je zijn redenering bekijken voordat er ook maar één bestand wordt aangepast. Je leest een korte tekst die twee minuten kost, in plaats van een uur te besteden aan uitzoeken waarom de voltooide code niet werkt zoals verwacht.
Premortem: laat AI vóór de start 10 redenen voor mislukking vinden
Belangrijkste punt
Een premortem is een techniek waarbij je AI vraagt zich voor te stellen dat het project al is mislukt en de redenen te noemen. Claude schakelt van de optimistische modus ‘dit krijg ik voor elkaar’ naar het zoeken naar zwakke plekken die anders pas na een week werk aan het licht zouden komen. Je krijgt een lijst met risico’s voordat je tijd in het project hebt gestoken en kunt ze vooraf aanpakken.
Dit is mijn favoriete techniek, en het effect is psychologisch. Als je AI vraagt om ‘goed werk te leveren’, is het ingesteld op succes en ziet het de gaten over het hoofd. Vraag het zich een mislukking voor te stellen en het begint te zien wat het eerder negeerde. De prompt is kort:
Prompt
Premortemprompt — vind de hiaten voordat je begint
Stel je voor dat het over een jaar is. Het project dat we plannen is mislukt.
Schrijf 10 redenen op waarom dat is gebeurd. Waar hebben we in het begin geen rekening mee gehouden, wat hebben we onderschat, waar hebben we concessies gedaan en welke aannames bleken onjuist?
Vertel me vervolgens voor elke reden wat we nu kunnen aanpassen om het probleem aan te pakken.
Ik gebruik deze prompt voordat ik het plan goedkeur. De helft van de redenen blijkt onzin, maar de andere helft bestaat uit echte valkuilen waar ik een week later tegenaan zou zijn gelopen. Ze tijdens de planning aanpakken kost tien minuten. Ze in een afgerond project tegenkomen kost meerdere dagen onderzoek.
De combinatie is eenvoudig: grilling haalt de bedoeling naar boven, ‘bewijs het’ verdedigt de beslissing en de premortem vindt de hiaten. Drie korte teksten die je plakt voordat je code schrijft. Ze maken van Claude een medewerker die niet overhaast uitvoert, maar eerst nadenkt.
Waarom maakt een overvolle context Claude dommer?
Belangrijkste punt
Claude heeft een beperkt contextvenster — de hoeveelheid informatie die het tegelijk kan onthouden. Als het venster meer dan halfvol is, begint Claude belangrijke details te verliezen, eerdere afspraken door elkaar te halen en gaten in te vullen in plaats van zich dingen te herinneren. Een lange sessie over van alles en nog wat is een veelvoorkomende reden waarom AI aan het einde van de dag iets heel anders doet dan wat je die ochtend hebt afgesproken.
Zelfs een perfect geformuleerde taak loopt mis als je eraan werkt in een rommelige context. Zo werkt het: elk nieuw verzoek dat je doet, brengt de volledige chatgeschiedenis in Claudes werkcontext. Hoe langer de sessie, hoe sneller het venster volloopt. Houd het maximaal halfvol; daarboven begint AI dom te doen en belangrijke dingen te verliezen die je aan het begin hebt besproken.
Dit is de regel die me de meeste frustratie bespaart: één taak, één chat. Functie af? Sluit de chat en open een nieuwe voor de volgende taak. Ja, soms is het handiger om alles in één venster te doen, maar dat kost je context en levert antwoorden op die niet ter zake doen.
Anthropic noemt deze foutmodus een ‘rommelladessessie’. De oplossing is eenvoudig: gebruik /clear tussen niet-gerelateerde taken om het venster leeg te maken en te voorkomen dat rommel van de vorige taak wordt meegenomen naar de nieuwe.
Als je lange sessies houdt en niet begrijpt waar het geld en de aandacht van AI naartoe gaan, bespreek ik dat apart in de gids over waar Claude Code-tokens naartoe gaan. De basis van persistente context, die Claude bij elke start leest, heb ik uitgewerkt in de gids over CLAUDE.md instellen.
Grilling of Plan Mode — wat is het verschil en hoe vullen ze elkaar aan?
Belangrijkste punt
Grilling en Plan Mode lossen elk een andere helft van hetzelfde probleem op. Grilling haalt je bedoeling met vragen naar boven voordat er een plan is. Plan Mode neemt een taak die al begrepen is en laat je een wijzigingsplan zien, zonder iets aan te passen voordat je het goedkeurt. Samen werken ze het best: eerst verduidelijkt grilling wat we bouwen, daarna laat Plan Mode precies zien hoe.
Mensen halen deze twee technieken vaak door elkaar of denken dat er maar één nodig is. In de praktijk horen ze op verschillende momenten in het proces thuis.
| Kenmerk | Grilling | Plan Mode |
|---|---|---|
| Wanneer het gebeurt | Vóór het plan — verduidelijkt de bedoeling | Daarna — maakt een wijzigingsplan |
| Wie wie ondervraagt | AI interviewt jou | Jij leest het plan en keurt het goed |
| Wat je krijgt | Een taakspecificatie | Een wijzigingsplan per bestand |
| Belangrijkste voordeel | Voorkomt ‘dat bedoelde ik niet’ | Voorkomt ‘raak verder niets aan’ |
Anthropic beschrijft een standaardworkflow in vier fasen: eerst Explore (Claude bestudeert en stelt vragen), dan Plan (maakt een plan zonder wijzigingen aan te brengen), vervolgens Implement (schrijft code volgens het plan) en tot slot Commit (legt het resultaat vast). Grilling hoort bij de eerste fase; Plan Mode bij de tweede. Bekijk voor een volledige uitleg van de tweede fase de gids over Plan Mode in Claude Code.
Een belangrijke kanttekening van Anthropic zelf: maak kleine taken hiermee niet onnodig ingewikkeld.
Als je een wijziging in één zin kunt beschrijven, sla het plan dan over.
Voor een typefout, een hernoeming of een wijziging van één regel kun je gewoon direct aangeven wat je wilt, zonder interviews of plannen. Grilling loont bij taken met onduidelijkheid en hoge kosten van fouten. Bij triviale taken vertraagt het je alleen maar.
5 fouten bij het formuleren van taken waardoor AI het verkeerde doet
Belangrijkste punt
Bij bijna elke misser van AI gaat het om een van vijf fouten bij het formuleren van taken: een vage opdracht van één regel, geen beperkingen, ‘schrijf code’ zonder eerst te begrijpen, geen definitie van ‘klaar’ en één eindeloze sessie voor alles. Door elk van deze fouten vult Claude de taak aan met aannames. Hieronder zie je hoe elke fout eruitziet en wat je ervoor in de plaats kunt doen.
Ik heb veelvoorkomende valkuilen in een tabel samengevat. Links staat wat mensen meestal doen en verkeerd aanpakken; rechts wat ze in plaats daarvan moeten doen.
| Fout | Hoe het klinkt | Wat je in plaats daarvan doet |
|---|---|---|
| Vage opdracht van één regel | ‘Maak het dashboard beter’ | Beschrijf de taak en start een grillsessie — laat AI met vragen de details boven water halen |
| Geen beperkingen | ‘Voeg autorisatie toe’ | Zeg wat niet kapot mag gaan, welke bibliotheken je niet wilt toevoegen en wat buiten de scope valt |
| Meteen ‘schrijf code’ | Prompt — en meteen beginnen met coderen | Eerst ‘begrijpen en vragen stellen’, daarna code schrijven |
| Geen definitie van ‘klaar’ | Je verwacht dat AI het resultaat raadt | Geef een voorbeeld, een referentiescreenshot of een test die laat zien wat ‘werkend’ betekent |
| Eén sessie voor alles | De hele dag in één chat blijven | Eén taak, één nieuwe chat, zodat de context niet rommelig wordt |
Bekijk de laatste prompt waarop AI het verkeerde antwoord gaf. Bijna zeker speelde een van deze vijf fouten een rol. Meestal is het de eerste: je gaf het een korte zin en verwachtte dat Claude de rest goed zou invullen. Het vulde de rest in — alleen niet zoals jij het bedoelde.
Wat nu: bouw een systeem zodat AI je met een paar woorden begrijpt
Belangrijkste punt
Losse prompts lossen losse taken op. Om ervoor te zorgen dat AI je elke keer zonder lange uitleg begrijpt, heb je een systeem nodig: grilling haalt de bedoeling voor elke taak naar boven, een Second Brain slaat projectkennis op en context engineering verbindt alles wat Claude vóór de prompt leest. Dan verdwijnt de reden waarom het verkeerde werk doet: het heeft altijd genoeg context om niet te hoeven raden.
De drie prompts in deze gids — grilling, ‘bewijs het’ en de premortem — helpen bij de taak zelf. Dat is al veel: je krijgt geen diff van 14 bestanden meer als je alleen een wijziging van één regel wilde.
Maar grilling kent grenzen. Elke keer opnieuw je bedoeling achterhalen kost veel tijd. De echte omslag komt wanneer een deel van de context er altijd is: in een map met kennis over je project, in een CLAUDE.md-bestand dat Claude bij elke start leest en in je werkwijze die in skills is vastgelegd. Dan begint AI aan de taak met kennis van je bedrijf, doelen en stijl — en begrijpt het je met een paar woorden, omdat je de helft van de context vooraf hebt uitgelegd.
Uit een recente analyse van Anthropic blijkt hoeveel werk dit is: ontwikkelaars gebruiken AI bij ongeveer 60% van hun werk, maar kunnen er slechts bij 0-20% van de taken volledig op vertrouwen. Voor de rest zijn jouw inzicht, toezicht en vermogen om uit te leggen wat er gebouwd moet worden nodig. Dat is de vaardigheid die het waard is om te ontwikkelen, niet het najagen van het slimste model.
Bronnen
Maak kennis met Ailoot.
Meer details
Vragen en antwoorden
Wanneer gebruik ik de interviewprompt in plaats van meteen code te vragen?
Gebruik die wanneer uitkomst, randgevallen of grenzen onduidelijk zijn en fouten duur zouden zijn. Stel één vraag tegelijk en bewaar het afgesproken resultaat in SPEC.md; een tikfout of duidelijk beschreven wijziging van één regel kun je rechtstreeks vragen.
Wat controleer ik voordat ik het voorgestelde plan accepteer?
Vraag twee of drie aanpakken en vergelijk hoe elke aanpak aan de specificatie en grenzen voldoet. Voer daarna de pre-mortemprompt uit, beoordeel de mogelijke oorzaken van falen en pak relevante risico’s vóór de uitvoering aan.