Mijn twee instructiebestanden voor Claude Code zijn samen 413 regels en ruim 5.100 woorden. Het ene staat in deze repo en beschrijft hoe sparkone.nl in elkaar zit, het andere staat in mijn thuismap en beschrijft hoe ik werk. Het projectbestand heeft negentien commits achter de rug. Elke regel daarin is ooit toegevoegd omdat het model iets deed wat ik niet wilde, of iets niet deed wat ik wel wilde. Ik heb ze nooit meer weggehaald.
Boris Cherny, de maker van Claude Code, zat eind juli bij Y Combinator op het podium en zei precies het omgekeerde. Zijn team heeft bij de komst van Opus 5 ruim tachtig procent van de systeem-prompt van Claude Code geschrapt. Niet omdat er iets stuk was, maar omdat het model die aanwijzingen niet meer nodig had. Zijn advies aan iedereen in de zaal: verwijder elke zes maanden je CLAUDE.md, je skills en je hooks, en kijk wat er gebeurt.
Ik heb eerder geschreven dat je het model minder moet vertellen. Dat ging over hoeveel je in één opdracht stopt. Dit gaat over iets anders: wat je permanent hebt opgeschreven, en of dat nog waar is.
Wat ablatie is
Ablatie komt uit onderzoek. Je haalt een onderdeel uit een systeem weg en meet wat er verandert. Als er niets verandert, deed dat onderdeel niets.
Cherny beschrijft het als een vaste ronde bij elk nieuw model:
| Stap | Wat je doet | Waar het misgaat |
|---|---|---|
| 1. Schrappen | Hele systeem-prompt eruit, in één keer | Je bewaart “voor de zekerheid” een kwart, en meet daarna niets |
| 2. Gebruiken | Het product echt draaien op echt werk | Je gaat gokken welke instructie het model mist |
| 3. Kijken | Noteren waar het model struikelt | Eén incident telt als patroon |
| 4. Terugzetten | Regel voor regel, alleen bij herhaling | Je zet de hele oude prompt terug omdat het sneller voelt |
De derde stap is waar het om draait. Je zet een regel pas terug als het model er herhaaldelijk over struikelt, niet één keer. Cherny’s reden daarvoor is nuchter: het model leest die regel bij elke sessie opnieuw, dus hij moet zijn plek verdienen.
Claude Code heeft hiervoor een niet-gedocumenteerde schakelaar. Zet de omgevingsvariabele CLAUDE_CODE_SIMPLE=1 en alle systeem-prompts verdwijnen, ook die van de tools. Anthropic gebruikt hem intern als ablatie-instrument. Cherny’s observatie daarbij vind ik de interessantste zin uit het hele gesprek: zonder die prompts is het model een beetje intelligenter. De prompts zitten er niet voor de intelligentie, ze zitten er zodat het product zich gedraagt zoals jij als gebruiker verwacht.
De cijfers, en wat eronder ontbreekt
Er hangen drie getallen aan dit verhaal, en ze zijn niet allemaal even hard.
Tachtig procent. Dat is de omvang van de schrapping in de systeem-prompt van Claude Code bij de overgang naar Opus 5. Het is een mededeling van Anthropic over Anthropic, gedaan in een podiuminterview. Er is geen gepubliceerde ablatietabel bij, geen voor-en-na-eval, geen aantal regels. Het is dus een richting, geen meting die ik kan narekenen.
30,2 procent op ARC-AGI-3. Opus 5 verscheen op 24 juli 2026 en zette die score neer in de High-instelling, gemeten door ARC Prize zelf. Het vorige record stond op 7,8 procent. Dat is bijna een verviervoudiging op een benchmark die expliciet is gebouwd om te weerstaan wat modellen goed kunnen. Belangrijk detail: dertig procent betekent ook dat zeventig procent niet lukt.
Elf dagen voor Bun. Het voorbeeld dat Cherny op het podium gebruikt is de herschrijving van de JavaScript-runtime Bun van Zig naar Rust. In het gesprek klinkt dat als “één prompt, één dynamic workflow, elf dagen”. De blogpost van Jarred Sumner zelf, de maker van Bun, is preciezer en minder magisch: ongeveer vijftig workflows die continu draaiden, tot 64 Claude-instanties tegelijk in aparte worktrees, 6.502 commits, een testsuite met meer dan 1,38 miljoen assertions als vangnet, en ongeveer 165.000 dollar aan API-kosten. En vooral: Sumner schrijft dat hij die elf dagen lang zelf output zat te lezen, foute patronen eruit haalde en de workflows bijstuurde.
Dat verschil is niet triviaal. Op het podium wordt het een prompt. In de post van degene die het deed is het elf dagen fulltime toezicht met een conformance-suite eronder. Als je één cijfer uit dit stuk onthoudt, neem dan die tweede versie.
Waarom dit tegen je intuïtie in gaat
Cherny noemt de meest voorkomende fout bij ervaren engineers: overspecificeren. Je beschrijft niet alleen wat er moet gebeuren, maar ook stap één, twee, drie en vier, in de volgorde waarop jij het zou doen. Dat is precies hoe je vroeger software bouwde, en het is precies wat modern gedrag van het model in de weg zit.
Zijn alternatief is korter dan je zou willen. Beschrijf de taak, beschrijf de grenzen, beschrijf waaraan je afleest dat het klaar is, en laat het lopen. De vaardigheid die daarvoor in de plaats komt is niet prompten maar verificatie: hoe kan dit ding zelf controleren of het goed zit. Daar schreef ik eerder over in verificatie is niet je unit-test, en Cherny zegt onomwonden dat dit het onderdeel is dat de meeste mensen niet goed doen.
Zijn eigen voorbeeld is bijna gênant simpel. Hij wilde weten hoe de Claude-desktopapp zou voelen als hij native was, gaf Claude toegang tot een macOS-runner en een lege repo, en vroeg: herschrijf de Electron-app in Swift, draai de Electron-versie in de virtuele machine, maak er een screenshot van, vergelijk pixel voor pixel met de Swift-versie, en stop niet tot je klaar bent. Op het moment van het interview liep die taak al ruim twee weken. Er zit geen truc in die opdracht. Er zit een meetlat in.
Wat ik zelf doe
Ik ga mijn instructiebestanden niet in één keer leeggooien, en ik denk dat dat advies voor een blog met tweetalige contentgates ook niet klopt. Wat ik wel doe, in september:
- Ik splits mijn CLAUDE.md in twee soorten regels. Feiten over dit project (poorten, paden, welke gate wat blokkeert) blijven staan, want die kan het model niet raden. Correcties op modelgedrag (“niet te veel uitleggen”, “geen em-dashes”) gaan op de schopstoel.
- Die tweede categorie gaat er in één keer uit, en ik werk een week met het projectbestand zonder gedragsregels. Wat het model dan structureel fout doet, schrijf ik op. Wat het spontaan goed doet, komt niet terug.
- Skills behandel ik apart. Ik heb er 48 in mijn thuismap staan. Een deel is een gestold werkproces met scripts eronder, dat blijft. Een deel is een lange uitleg over hoe je moet schrijven, en dat is precies het soort instructie dat een nieuw model niet meer nodig heeft.
- Ik zet het in een routine, niet in mijn hoofd. Een halfjaarlijkse herinnering op 1 maart en 1 september, die simpelweg zegt: schrap en meet. Over het inzetten van terugkerend werk in loops schreef ik eerder; dit is er een voor mezelf.
Wat ik niet ga doen is de contentgates in deze repo weghalen. Die zijn geen prompt-scaffolding maar hard beleid met tests eronder, en een slimmer model is geen argument om je publicatiedrempel te verlagen.
De kanttekening
De schrapadviezen komen van de partij die aan de andere kant zit. “Verwijder je instructies en vertrouw het model” is inhoudelijk waarschijnlijk goed advies, en het is tegelijk advies dat je afhankelijker maakt van standaardgedrag dat je niet kunt inzien en dat bij de volgende modelversie kan verschuiven. Wat je opschrijft is je enige controle die niet meebeweegt. Weggooien is dus niet gratis, en het is geen toeval dat de instructie die verdwijnt vervangen wordt door vertrouwen in het model.
De verantwoordelijkheid landt bij degene die het niet gebouwd heeft. Bij Bun ging het om ruim een miljoen regels nieuwe Rust-code die niemand regel voor regel heeft gelezen. Andrew Kelley, de maker van Zig, noemde het resultaat publiekelijk ongereviewde slop en richtte zijn kritiek vooral op de werkwijze eromheen. Zijn punt staat los van hoe goed het model is: als er over drie jaar een lek in die code zit, is er geen mens die kan uitleggen waarom die regel er zo staat. Die last verschuift naar de onderhouder, en die is meestal niet degene die de workflow startte.
Er stroomt kennis weg die je niet terugkrijgt. Een CLAUDE.md is niet alleen een prompt, het is ook documentatie voor mensen. Elke regel is een keer geleerd van iets dat misging. Als je die elk halfjaar weggooit omdat het model het inmiddels zelf weet, houd je een team over dat het antwoord heeft zonder de reden te kennen. Ik haal daarom nooit een regel weg zonder de reden ergens anders te bewaren, ook al leest het model hem niet meer.
Zo’n schoonmaakronde doe je makkelijker met iemand die meekijkt dan alleen. Ik denk erover een dag te organiseren waarop we dat werk echt doen in plaats van erover te lezen. Of dat doorgaat hangt af van hoeveel mensen zich melden, en dat kan op de praktijk.
Veelgestelde vragen
Moet ik echt alles in één keer weggooien?
Nee, en de methode werkt alleen als je twee soorten regels uit elkaar houdt. Feiten die het model niet kan afleiden (poorten, mappen, welke gate wat blokkeert) hebben niets met modelintelligentie te maken en horen te blijven staan. Gedragscorrecties horen op de schopstoel, want die zijn geschreven voor een model dat er niet meer is.
Wat is CLAUDE_CODE_SIMPLE=1 precies?
Een niet-gedocumenteerde omgevingsvariabele die alle systeem-prompts uitzet, ook die van de tools. Anthropic gebruikt hem intern om te meten of een prompt nog iets bijdraagt. Niet-gedocumenteerd betekent hier ook: geen belofte dat hij morgen nog bestaat, dus bouw er geen werkproces op.
Hoe weet ik of een instructie nog nodig is?
Door hem eruit te halen en het model op echt werk te draaien, niet door erover na te denken. Eén misser is geen bewijs; een patroon over meerdere sessies wel. Zet een regel pas terug als je kunt benoemen welk gedrag hij precies repareert.
Geldt dit ook voor evals en tests?
Deels. Cherny zegt dat evals langer meegaan dan de harness, maar ook niet eeuwig: een eval leeft ongeveer één tot drie modelgeneraties en wordt daarna verzadigd en weggegooid. Tests die beleid afdwingen, zoals de publicatiegates in deze repo, vallen buiten dit hele verhaal. Die gaan niet over modelgedrag maar over wat ik wel en niet publiceer.
Bronnen
- Y Combinator, video Boris Cherny: We Cut 80% of Claude Code’s Prompt, 27 juli 2026 (transcript zelf uitgelezen)
- Anthropic, Introducing Claude Opus 5, 24 juli 2026
- ARC Prize, Claude Opus 5 resultaten op ARC-AGI, juli 2026
- Jarred Sumner, Rewriting Bun in Rust, 8 juli 2026
- Simon Willison, Rewriting Bun in Rust, 8 juli 2026
- Andrew Kelley, My Thoughts on the Bun Rust Rewrite, juli 2026
- The Register, Zig creator calls Bun’s Claude Rust rewrite ‘unreviewed slop’, 14 juli 2026
Gecontroleerd op 11 augustus 2026. De uitspraken van Cherny komen uit het transcript van de video zelf, niet uit een samenvatting van derden. Het percentage van tachtig procent is een mededeling van Anthropic zonder gepubliceerde onderbouwing; ik heb geen ablatiedata gevonden om het na te rekenen. De cijfers rond Bun komen uit de blogpost van Jarred Sumner en wijken af van hoe het op het podium klonk: daar was het één prompt, in de post zijn het ongeveer vijftig workflows met elf dagen toezicht. Ik houd de post aan. De werking van CLAUDE_CODE_SIMPLE=1 heb ik niet zelf getest en staat niet in de officiële documentatie.