Waarom Anthropic 80% van Claude Code's prompt schrapte

TL;DR

  • Wat: Boris Cherny, hoofd van Claude Code bij Anthropic, vertelde bij Y Combinator dat zijn team 80% van de systeemprompt schrapte bij de lancering van Opus 5 — en dat het model daarna beter presteerde.
  • Waarom relevant: als je AI-tools inzet met uitgebreide instructies of configuratiebestanden, werk je mogelijk tegen het model in plaats van ermee.
  • Wat je ermee kunt: plan elk halfjaar een opschoonmoment voor je AI-instructies. Schrap alles, kijk wat het model zelf kan, en voeg alleen toe wat écht nodig blijkt.

Ik stuitte deze week op een samenvatting van een gesprek bij Y Combinator's Startup School. Boris Cherny, de maker van Claude Code bij Anthropic, deelde daar iets dat me aan het denken zette: zijn team had ruim 80% van de systeemprompt van Claude Code verwijderd toen hun nieuwste model Opus 5 uitkwam. Het resultaat? Het model presteerde beter zonder al die extra sturing.

Wat er precies is gebeurd

Laat ik even uitleggen wat een systeemprompt is, voor wie daar niet dagelijks mee werkt. Een systeemprompt is een set instructies die een AI-model meekrijgt vóórdat jij er iets aan vraagt. Denk aan het als een briefing die je een nieuwe medewerker geeft op dag één: "Zo werken wij hier, dit zijn de regels, hier let je op."

Bij Claude Code — een tool waarmee ontwikkelaars met AI programmeren — was die briefing in de loop van de tijd flink uitgegroeid. Regels over hoe het model code moest schrijven, wanneer het commentaar moest toevoegen, hoe het bestanden moest lezen. Allemaal logisch op het moment dat ze werden geschreven.

Maar toen Opus 5 in juli 2026 uitkwam, deed het team van Cherny iets opvallends. Ze verwijderden alles en keken via zogeheten ablation tests — systematische verwijderingstesten — wat er daadwerkelijk nodig was. Het resultaat: het model was volgens Cherny "een beetje intelligenter" zonder al die instructies. Meer dan 80% bleek overbodig.

Waarom minder instructies beter werkten

Dit klinkt misschien tegenstrijdig. Meer uitleg zou toch tot een beter resultaat moeten leiden? Niet per se — en de reden is eigenlijk vrij logisch als je er even over nadenkt.

Elke instructie in een systeemprompt wordt bij élke interactie gelezen door het model. Stel je voor dat je een ervaren medewerker elke ochtend een checklist van 200 punten geeft, terwijl die persoon inmiddels 190 van die punten allang uit zichzelf goed doet. Die checklist kost tijd, leidt af, en kan zelfs verwarring veroorzaken als er tegenstrijdigheden in staan.

Dat is precies wat er gebeurde. De instructies waren geschreven voor een minder slim model. Dingen als "voeg geen onnodige commentaren toe" of "lees eerst het bestand voordat je wijzigingen maakt" — dat waren correcties voor gedrag dat het nieuwere model uit zichzelf al had geleerd. Cherny noemt het treffend: "De hulpmiddelen van gisteren worden het dode gewicht van vandaag."

Wat ze wél behielden waren feitelijke zaken: welke commando's voor deployment nodig zijn, waar de testbestanden staan, welke interne bibliotheken het project gebruikt. Dat zijn dingen die een model niet kan weten, ongeacht hoe slim het is.

Het halfjaarlijkse opschoonprincipe

Het advies van Cherny is concreet: verwijder elke zes maanden je CLAUDE.md (het configuratiebestand waarin je instructies voor Claude Code opslaat), je skills en je hooks. Begin opnieuw. Kijk wat het model uit zichzelf kan. Voeg dan één voor één alleen terug wat aantoonbaar nodig is.

Ik vind dit eerlijk gezegd een verfrissend perspectief. We zijn als mensen geneigd om regels en processen op te stapelen. Dat geldt in bedrijven, in software, en blijkbaar ook in hoe we AI-modellen aansturen. Maar waar een ervaren ondernemer af en toe processen doorlicht en versimpelt, doen we dat bij AI-configuraties zelden.

Kun je je voorstellen dat je dit toepast op je eigen werkwijze met AI-tools? Stel dat je als ondernemer een prompt hebt gebouwd voor het genereren van offertes, klantenservice-antwoorden of rapportages. Die prompt werkte drie maanden geleden goed. Maar het model dat je nu gebruikt is waarschijnlijk een of twee generaties verder. Misschien doet het uit zichzelf al wat jij expliciet moet vragen — en hinderen je oude instructies meer dan ze helpen.

Wat dit voor ondernemers betekent

Je hoeft geen ontwikkelaar te zijn om hier iets aan te hebben. De kern van Cherny's boodschap is breder dan Claude Code alleen.

Behandel AI als een nieuwe collega, niet als een machine

Cherny adviseert om elk nieuw model te benaderen als een ander persoon met eigen sterke kanten. Niet als dezelfde machine met een software-update. Dat betekent: niet blind je oude instructies kopiëren, maar kijken wat dit model kan en waar het vastloopt.

Verificatie boven instructie

Een ander punt dat me opviel: Cherny's team gaf bij een complexe taak van elf dagen slechts één alinea aan instructies mee, plus een verificatiemechanisme — een pixel-voor-pixel vergelijking van screenshots. Het model kon zelf controleren of het goed zat. Dat bleek effectiever dan pagina's aan gedetailleerde instructies.

Voor een ondernemer vertaalt dit zich naar: besteed minder tijd aan het perfectioneren van je prompt en meer tijd aan het opzetten van een manier om te checken of het resultaat klopt. Dat kan zo simpel zijn als een checklist waartegen je de AI-output vergelijkt.

Het product-gat

Cherny noemde ook iets wat hij "product overhang" noemt: het verschil tussen wat een model kán en wat producten het model laten doen. Hij gaf als voorbeeld dat eerdere modellen al complete bestanden konden schrijven, terwijl veel tools nog steeds regel-voor-regel suggesties gaven. De modellen waren klaar; de producten niet.

Ik denk dat dit herkenbaar is voor ondernemers die AI inzetten. Vaak benutten we maar een fractie van wat de tools kunnen, simpelweg omdat we werken met aannames van zes maanden geleden.

Over "coderen is opgelost"

Cherny doet in het gesprek ook de uitspraak dat coderen — voor het type werk dat hij doet — "opgelost" is. Hij zegt in 2026 zelf geen regel code meer te hebben geschreven en tientallen pull requests per dag te versturen vanaf zijn telefoon.

Ik vind het belangrijk om hier een nuance bij te plaatsen. "Opgelost" klinkt definitief, maar Cherny spreekt specifiek over routinematig programmeerwerk, niet over architectuurkeuzes of complexe systeemontwerpen. En zelfs in zijn eigen team is verificatie — het controleren van wat de AI maakt — nog steeds mensenwerk. De rol verschuift, maar verdwijnt niet.

Een signaal, geen eindpunt

Wat mij betreft is dit vooral een signaal dat AI-tools sneller verbeteren dan de manier waarop we ze gebruiken. We bouwen gewoontes, processen en configuraties op, en houden daar aan vast terwijl de technologie eronder verandert. Het advies om regelmatig op te schonen en opnieuw te beginnen klinkt simpel, maar vraagt iets dat ondernemers goed kennen: het lef om werkende dingen los te laten als ze niet meer de beste aanpak zijn.

Voor mij is de kernles niet technisch. Het is organisatorisch. Wie AI inzet, doet er goed aan om periodiek de vraag te stellen: stuur ik dit model aan op basis van wat het vandaag kan, of op basis van wat het vorig jaar nodig had?

80% van de AI-projecten haalt productie nooit.

Ik bouw de 20% — van prototype naar draaiend systeem, binnen weken.