Je AI-agent configuratiebestand verspilt tokens — dit moet je in plaats daarvan doen
Ik had een CLAUDE.md-bestand van 1.247 regels. Ik was er trots op. Elke codeconventie, elke architectonische voorkeur, elk edge case dat ik ooit was tegengekomen — gedocumenteerd, georganiseerd en bij elk bericht dat ik naar Claude Code stuurde in de context geladen.
Toen deed ik het rekenwerk.
Met ongeveer 3 tokens per regel kostte dat bestand me ~3.700 tokens per beurt. Niet per sessie — per beurt. In een typische sessie van 40 beurten betekent dat 148.000 tokens die opgaan aan instructies die het model 90% van de tijd niet eens gebruikte. Ik betaalde een context-belasting die groter was dan de meeste volledige gesprekken van anderen, en de outputkwaliteit van mijn agent werd zelfs slechter naarmate het bestand groeide.
Ross Mike legde de oplossing uit in een recente discussie die mijn kijk op de productiviteit van AI-agents volledig opnieuw inkaderde. Zijn redenering is simpel, onderbouwd met data en — zodra je het hoort — pijnlijk voor de hand liggend: de kwaliteit van de output van je AI-agent hangt veel meer af van hoe je context beheert dan van welk model je gebruikt. Opus 4.6, GPT 5.4, Gemini 3 — ze zijn allemaal opmerkelijk capabel. Het knelpunt is niet intelligentie. Het is het informatiedieet dat je ze voert.
Ik heb de afgelopen twee weken mijn volledige agent-workflow rond dit principe herbouwd. De resultaten waren zo opvallend dat ik dit stuk schrijf in plaats van de drie andere dingen op mijn lijstje van vandaag te doen. Dit is wat er veranderde, wat er brak, en wat ik iedereen zou vertellen die nog steeds een configuratiebestand van 500 regels koestert.
De ongemakkelijke waarheid over je agent.md-bestand
De meeste developers waarmee ik praat hebben een variant van dezelfde setup. Een groot markdown-bestand — CLAUDE.md, .cursorrules, agents.md, hoe de tool het ook noemt — volgepropt met instructies over hun stack, hun voorkeuren, hun conventies. Het bestand groeit over maanden. Elke frustrerende interactie voegt een regel toe: "Gebruik altijd named exports." "Geef de voorkeur aan Tailwind boven CSS modules." "Stel nooit class components voor."
Ross noemt dit de "context dump"-aanpak, en zijn kritiek raakte me op een gevoelige plek: deze bestanden voelen productief omdat ze schrijven als werk voelt. Je legt kennis vast! Je traint je agent! Alleen doe je dat niet. Je creëert een statische klomp tekst die ongeacht relevantie in elke interactie wordt geïnjecteerd — en het model behandelt alles erin als even belangrijk.
Dit is wat recent onderzoek van InfoQ daadwerkelijk laat zien over deze bestanden: door LLM gegenereerde contextbestanden verslechteren de prestaties, met een gemiddelde daling van 3% in het slagingspercentage van taken vergeleken met helemaal geen contextbestand. Ze verhogen ook consistent het aantal stappen dat de agent zet, waardoor de inference-kosten met meer dan 20% stijgen. Zelfs door mensen geschreven bestanden leverden slechts een marginale verbetering van 4% op in slagingspercentage — terwijl tegelijkertijd het aantal stappen en de kosten tot 19% toenamen.
Lees dat nog eens. Het bestand waar je uren aan hebt zitten schaven, maakt je agent mogelijk trager en duurder terwijl de nauwkeurigheid nauwelijks verbetert.
Het mechanisme wordt duidelijk zodra je begrijpt hoe deze modellen werken. Ze "begrijpen" je configuratiebestand niet zoals een menselijke developer een stijlgids zou lezen en internaliseren. Ze voorspellen tokens op basis van patronen in het context window. Wanneer je dat venster overspoelt met 1.200 regels instructies, geef je het model geen naslagwerk — je verdunt de signaal-ruisverhouding van elke prompt die je verstuurt. Het model besteedt aandacht aan het verwerken van je TypeScript-voorkeuren terwijl je het vraagt om een CSS-layout te debuggen.
Dat betekent niet dat contextbestanden nutteloos zijn. Het betekent dat de standaardaanpak — één groot bestand, overal geladen, voor altijd groeiend — vrijwel zeker verkeerd is.
Wat Ross goed ziet over hoe modellen echt werken
Er is een misvatting die de meeste bouwers van AI-agents doet struikelen, en Ross pakte die direct aan: deze modellen denken niet. Ze begrijpen niets. Ze voorspellen het volgende token op basis van patronen in hun trainingsdata en de context die je aanlevert.
Dit klinkt als een beperking. Het is eigenlijk een ontwerpbeperking die je precies vertelt hoe je betere output krijgt.
Als het model een pattern-matching engine is, dan zijn de patronen in je context window de grootste hefboom die je hebt op de outputkwaliteit. Voer het een rommelige context vol irrelevante instructies en de pattern matching wordt ruizig. Voer het een gefocuste context met precies de informatie die nodig is voor de huidige taak en de pattern matching wordt scherp.
Ross gebruikte een analogie die is blijven hangen: stel je voor dat je een nieuwe medewerker voor elke taak briefeert. Als je ze een handleiding van 50 pagina's geeft die elk scenario dekt dat het bedrijf ooit is tegengekomen, zijn ze overweldigd en traag. Geef je ze een gefocuste one-pager specifiek voor de taak in kwestie, dan presteren ze meteen goed. Modellen werken hetzelfde — niet omdat ze de briefing "begrijpen", maar omdat een gefocuste context schonere tokenvoorspellingspatronen oplevert.
Dit heeft een praktische implicatie die de meeste mensen missen. Het context window is niet zomaar een emmer die je vult met nuttige informatie. Het is meer als een spotlight — het heeft een beperkt verlichtingsgebied, en alles binnen dat gebied concurreert om de aandacht van het model. Het onderzoek bevestigt dit: het context window tussen vers en ongeveer 70% capaciteit houden levert de meest betrouwbare output op. Ga je daaroverheen, dan zie je prestatieverlies optreden — gemiste instructies, herhaalde suggesties, inconsistente codepatronen.
Ik heb dit zelf getest. Zelfde prompt, zelfde model (Opus 4.6), zelfde taak: bouw een gebruikersauthenticatieflow met JWT tokens en refresh rotation. Met mijn volledige CLAUDE.md van 1.247 regels geladen, had de agent 14 beurten nodig en produceerde code met twee bugs. Nadat ik de CLAUDE.md had teruggebracht tot 47 regels oprecht essentiële conventies, was dezelfde taak in 8 beurten klaar met nul bugs. Minder instructies, betere output. De uitgeklede versie liet het model focussen op wat telde.
Maar hier wordt het interessant — want het antwoord is niet gewoon "maak je configuratiebestand kleiner". Dat is symptoombestrijding. Ross's echte inzicht gaat over de architectuur van hoe context moet stromen.
Progressive disclosure: het patroon dat alles verandert
Het concept dat mijn workflow transformeerde is niet nieuw — het komt uit UX-design. Progressive disclosure betekent dat je gebruikers alleen de informatie toont die ze in elke fase nodig hebben, waarbij complexiteit geleidelijk wordt onthuld naarmate ze dieper gaan. Microsoft's agent-skills framework formaliseerde dit als een drielaagse laadarchitectuur voor AI-agents, en het is nu de basis van hoe skills werken in Claude Code, Cursor en andere grote tools.
Dit is het concrete verschil tussen de oude aanpak en de nieuwe:
De oude manier (agent.md / CLAUDE.md): Elke interactie laadt je volledige configuratiebestand. Als je 1.000 tokens aan instructies hebt, dan worden die 1.000 tokens aan elk bericht toegevoegd — of de agent die instructies nu nodig heeft of niet.
De nieuwe manier (skills met progressive disclosure): Bij het opstarten laadt de agent alleen de namen en beschrijvingen van skills — ongeveer 50 tokens per skill. Pas wanneer een taak matcht met de beschrijving van een skill wordt de volledige instructieset in de context geladen. Als de taak klaar is, blijven de gedetailleerde instructies van de skill niet hangen in de volgende taak.
De tokenwiskunde is dramatisch. Stel dat je 20 verschillende workflows als instructies hebt gecodeerd. Onder de oude aanpak is dat misschien 15.000-20.000 tokens die elke beurt worden geladen. Onder progressive disclosure laad je bij het opstarten ~1.000 tokens metadata, plus misschien 500-800 tokens van de ene relevante skill wanneer die nodig is. Dat is volgens real-world benchmarks ongeveer een reductie van 82% in context-overhead.
Ik behandelde de technische implementatie van skills in mijn gids voor het bouwen van agent skills, maar het raamwerk van Ross voegt iets toe dat de technische docs missen: een filosofie voor wanneer en hoe je skills maakt die daadwerkelijk werken.
Ross's raamwerk: hoe je skills bouwt die niet waardeloos zijn
Het eerste instinct van de meeste mensen wanneer ze over skills horen is om te gaan zitten en er eentje vanaf nul te schrijven. Open een leeg markdown-bestand, denk na over een workflow, documenteer de stappen, opslaan. Klaar.
Ross betoogt dat dit precies verkeerd om is — en nadat ik beide benaderingen heb geprobeerd, ben ik het volledig met hem eens.
Zijn raamwerk heeft vijf stappen, en de volgorde is belangrijker dan welke individuele stap dan ook:
Stap 1: identificeer een echte workflow (geen hypothetische)
Bouw geen skills voor workflows waarvan je denkt dat je ze nodig zult hebben. Bouw ze voor workflows die je al minstens drie keer handmatig hebt uitgevoerd. Heb je het geen drie keer gedaan, dan begrijp je de edge cases niet goed genoeg om een agent op te leiden.
Dit filter alleen al heeft me behoed voor het aanmaken van een dozijn nutteloze skills. Ik had grootse plannen voor een "deploy to production"-skill, een "database migration"-skill, een "write unit tests"-skill. Maar toen ik Ross's filter toepaste — heb ik dit recent daadwerkelijk handmatig van begin tot eind, minstens drie keer, gedaan? — kromp de lijst snel. De workflows die ik echt herhaalde waren banaler: inkomende e-mails doorlichten, metadata voor blogposts opmaken, nieuwe project scaffolding opzetten met mijn specifieke conventies.
Banaal is goed. Banaal betekent repetitief. Repetitief betekent hoge ROI voor automatisering.
Stap 2: leer de agent via een gesprek, niet via configuratie
Hier wijkt Ross's aanpak af van wat ik de meeste developers zie doen. In plaats van een skillbestand te schrijven en te hopen dat het werkt, leer je de agent de workflow interactief — op dezelfde manier waarop je een nieuwe collega zou inwerken.
Stuur de agent een echte taak door. Neem hem in realtime mee door je beslissingsproces. Als hij een fout maakt, corrigeer die en leg uit waarom. Als hij iets goed doet, bevestig dat. Dit is ervaringsleren, en Ross beweert dat het de enige betrouwbare manier is om de edge cases en impliciete kennis naar boven te brengen waar je nooit aan zou denken om ze in een statisch instructiebestand op te schrijven.
Zijn voorbeeld was overtuigend: hij leerde een agent om sponsor-e-mails door te lichten door letterlijk echte e-mails door te sturen en hem door het onderzoeksproces te begeleiden. "Controleer hun aanwezigheid op Twitter. Zoek ze op op Trustpilot. Verifieer hun funding-status. Als het bedrijf minder dan 6 maanden geleden is opgericht, markeer het dan." Elke correctie verfijnde het begrip van de agent. Na drie of vier iteraties doorliep de agent e-mails sneller en grondiger dan Ross het handmatig deed.
Ik probeerde dit met mijn metadata-workflow voor blogposts. In plaats van een skill vanaf nul te schrijven, nam ik Claude op een echte post mee door het proces: "Dit is de titel, dit zijn de tags die ik zou kiezen, dit is waarom ik deze secundaire keywords boven die verkies, dit is het meta description-patroon dat ik gebruik." Daarna deed ik het nogmaals met een andere post. Bij de derde keer genereerde Claude metadata die bijna exact bij mijn stijl paste — nuances oppikkend die ik nooit had bedacht om te documenteren, zoals mijn voorkeur voor actiewerkwoorden in meta descriptions of mijn gewoonte om de merknaam als laatste in tag-lijsten te zetten.
Stap 3: itereer totdat de faalmodi verdwijnen
De eerste run zal fouten bevatten. De tweede zal er minder hebben. Tegen de vierde of vijfde begin je consistente, betrouwbare output te zien. Ross is daar expliciet over: sla de iteratiefase niet over. De agent "leert" niet op een blijvende manier — jij leert welke context hij nodig heeft, en elke iteratie onthult gaten die je niet had voorzien.
Dit geduld betaalt samengestelde rente. Elke edge case die je tijdens de training boven tafel haalt en oplost, is een edge case die je niet zal bijten tijdens productiegebruik. Ik merkte dat de meeste skills 4-6 interactieve trainingsruns nodig hadden voordat ze solide genoeg waren om te formaliseren.
Stap 4: zet de verfijnde workflow om in een skillbestand
Pas nadat de interactieve training consistente resultaten oplevert, maak je het skill.md-bestand aan. Op dat punt verzin je geen instructies — je documenteert wat al werkt. Het skillbestand wordt een codificatie van bewezen patronen, geen speculatieve gok over wat de agent zou kunnen nodig hebben.
De structuur die Ross aanbeveelt is strak:
# Skill: [Name]
## Description
[One sentence — what this skill does and when to use it]
## Workflow
[Numbered steps, each specific and actionable]
## Known Edge Cases
[Things that went wrong during training and how to handle them]
## Success Criteria
[How to verify the output is correct]
Dat "Known Edge Cases"-gedeelte is waar de echte waarde zit. Het is de institutionele kennis die je hebt opgebouwd tijdens stap 2 en 3 — de valkuilen die een skill-auteur met een blanco blad nooit zou voorzien.
Stap 5: blijf recursief verfijnen
Een skillbestand is geen afgerond product. Het is een levend document. Elke keer dat de skill faalt in productie, debug je het, los je de hoofdoorzaak op en werk je het bestand bij. Ross noemt dit "recursieve skillopbouw", en het is het mechanisme dat skills in de loop van de tijd cumulatief in waarde laat toenemen.
Ik heb mijn metadata-generatie-skill zeven keer bijgewerkt sinds ik hem drie weken geleden heb gemaakt. Elke update werd getriggerd door een echte fout — een post waarvan de meta description te lang was, een tagcombinatie die niet bij de clusterstructuur paste, een slug die stopwoorden bevatte. De skill is nu dramatisch beter dan toen ik hem voor het eerst schreef, en elke verbetering werd gedreven door echt gebruik, niet door speculatie.
Waarom je nooit skills van een marketplace moet downloaden
Ross's standpunt hierover is ondubbelzinnig, en ik ben het na aanvankelijke tegenwerping met hem eens gaan worden.
Skill-marketplaces — plekken waar je vooraf gebouwde skills van andere developers kunt bekijken en installeren — lijken aan de oppervlakte een geweldig idee. Waarom een skill voor het genereren van React-componenten vanaf nul bouwen als iemand anders er al een heeft gemaakt?
Twee redenen.
Ten eerste: context mismatch. Een skill die voor de workflow van iemand anders is gebouwd, codeert hun conventies, hun stackbeslissingen, hun edge cases. Tenzij hun ontwikkelomgeving identiek is aan die van jou (dat is hij niet), produceert de skill output die niet helemaal past. Je zult net zoveel tijd besteden aan het repareren van de output als je zou hebben besteed aan het zelf bouwen van de skill. Ik schreef hierover in mijn workflowgids voor agent skills — de skills die het beste werken zijn de skills die zijn gebouwd vanuit jouw daadwerkelijke workflow, niet iemand anders' abstractie van een soortgelijke workflow.
Ten tweede: beveiliging. Een skill.md-bestand is in wezen een set instructies die je AI-agent zal volgen. Een skill uit een onbetrouwbare bron installeren is als een npm-pakket uitvoeren zonder de code te lezen — behalve dat het aanvalsoppervlak je volledige ontwikkelomgeving is. Een kwaadaardige skill zou de agent kunnen opdragen om code te exfiltreren, afhankelijkheden te injecteren of bestanden op manieren aan te passen die kwetsbaarheden creëren. Het risico is niet theoretisch; naarmate agents meer autonome mogelijkheden krijgen, worden de instructies die ze volgen een steeds aantrekkelijker aanvalsvector.
Bouw je eigen. Het kost vooraf meer tijd. Het samengestelde rendement is het waard.
Het "één agent, veel skills"-principe
Hier sluit het raamwerk van Ross aan bij een bredere architectonische beslissing waar ik developers constant de mist in zie gaan.
De verleiding, zodra je agents en skills begrijpt, is om een vloot te bouwen. Een coding-agent. Een research-agent. Een writing-agent. Een deployment-agent. Elk met zijn eigen system prompt, zijn eigen toolconfiguratie, zijn eigen persoonlijkheid. Het ziet er indrukwekkend uit. Het voelt geavanceerd. En voor de meeste use cases is het enorme overkill.
Ross's aanbeveling: begin met één agent. Bouw er 10 skills voor. Zorg dat die skills betrouwbaar werken. Overweeg pas dan of een tweede agent je productiviteit echt zou verbeteren — en alleen als je precies kunt uitleggen wat de tweede agent zou doen dat de eerste niet kan.
De redenering is praktisch. Meerdere agents introduceren coördinatie-overhead — ze moeten communiceren, context delen, taken overdragen en conflicten oplossen. Die overhead is alleen gerechtvaardigd wanneer de agents echt parallel werk doen dat niet geserialiseerd kan worden. Voor een solo-developer of een klein team handelt één goed geskilde agent de meeste workflows efficiënter af dan drie gespecialiseerde die orchestratie nodig hebben.
Ik heb mijn eigen setup vorige maand rond dit principe geherstructureerd. Ik ging van drie geconfigureerde agents (één voor coding, één voor content, één voor DevOps) terug naar één agent met een bibliotheek van 14 skills die alle drie domeinen bestrijken. De single-agent-setup is sneller te onderhouden, voorspelbaarder in gedrag en — tegen de intuïtie in — produceert betere output omdat de volledige context van mijn project altijd beschikbaar is, niet gefragmenteerd over agents die elkaars werk niet kunnen zien.
Als je liever hebt dat iemand dit soort agent-architectuur vanaf nul voor je opzet: ik neem AI workflow- en automatiseringsopdrachten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.
De uitzondering op de regel van één agent is echte parallelliteit — taken die werkelijk onafhankelijk en tijdkritisch genoeg zijn om gelijktijdig uit te voeren. Deployen naar staging terwijl je een testsuite draait en tegelijkertijd documentatie genereert? Dat zijn drie onafhankelijke taken. Drie agents zijn logisch. Maar code schrijven, reviewen en daarna deployen? Dat is een seriële workflow. Eén agent, drie skills.
Praktische migratie: van opgeblazen config naar slanke skills
Als je op dit moment op een grote CLAUDE.md of agents.md zit, zo heb ik de mijne gemigreerd zonder de kennis te verliezen die ik had opgebouwd:
1. Audit je configuratiebestand op daadwerkelijke gebruikspatronen.
Ga door elke instructie in je bestand en vraag: "Wanneer heeft deze instructie de laatste keer de output van de agent daadwerkelijk veranderd?" Wees eerlijk. Ik kwam erachter dat ongeveer 60% van mijn instructies ofwel overbodig waren (het model doet dit standaard al), verouderd (verwijzend naar patronen die ik niet meer gebruikte), of zo zeldzaam dat ze in maanden gebruik misschien twee keer waren getriggerd.
2. Scheid het universele van het taakspecifieke.
Sommige instructies horen echt in elke interactie thuis: "Gebruik TypeScript, geen JavaScript." "Volg de bestaande projectstructuur." "Draai tests voordat je een PR voorstelt." Deze blijven in je slanke CLAUDE.md. Al het andere — specifieke API-patronen, deployment-procedures, regels voor contentopmaak — wordt een kandidaat voor een skill.
3. Pas op elke skill-kandidaat de "drie keer"-test toe.
Heb je deze workflow daadwerkelijk minstens drie keer handmatig uitgevoerd? Zo ja, dan is het de moeite waard om een skill te bouwen. Zo nee, doe het dan nog een paar keer handmatig om de edge cases te begrijpen, of sla het helemaal over.
4. Bouw skills via een gesprek, niet via configuratie.
Voor elke skill die je maakt, loop je de workflow 3-5 keer interactief met de agent door voordat je het skillbestand schrijft. Dit brengt edge cases naar boven die je vanaf een blanco blad zou missen.
5. Houd je CLAUDE.md onder de 200 regels.
Dit is de drempel die current best practices voorstellen om de kosten-batenbalans te behouden. Voorbij 200 regels begint de persistente kostprijs van input-tokens op te wegen tegen de verbeteringen in outputkwaliteit. De mijne telt momenteel 47 regels, en de outputkwaliteit is de beste die hij ooit is geweest.
Na deze migratie daalde mijn tokenverbruik per sessie met ongeveer 60%. Ik krijg hetzelfde werk gedaan — vaak meer — terwijl ik dramatisch minder tokens verbruik. De sessies voelen ook anders. De agent reageert sneller, blijft gefocuster en produceert minder off-target suggesties. Ik schreef hier in detail over de tokenoptimalisatie-kant in mijn Claude Code token-optimalisatiegids, maar de migratie van monolithische config naar skills is waar de grootste individuele verbetering vandaan kwam.
De echte paradigmaverschuiving: context is het product
Ross zei tegen het einde van de discussie iets waar ik sindsdien over zit na te denken: de modellen zijn een commodity. Opus 4.6, GPT 5.4, wat volgend kwartaal ook maar verschijnt — ze convergeren allemaal naar vergelijkbare capaciteitsniveaus. Het concurrentievoordeel ligt niet in welk model je gebruikt. Het ligt in hoe goed je context, workflows en skills bouwt rond welk model je ook kiest.
Dit herkadert wat het betekent om in 2026 productief te zijn met AI. De developers die gedijen zullen niet degenen zijn die elke nieuwe modelrelease najagen of de langste configuratiebestanden verzamelen. Het zullen degenen zijn die een persoonlijke bibliotheek van battle-tested skills hebben gebouwd — elk verfijnd door echt gebruik, elk coderend workflowkennis die een verse agent niet zou kunnen repliceren zonder weken training.
Zie het als het bouwen van een kennisgracht. Elke skill die je maakt, elk edge case dat je documenteert, elke workflow die je verfijnt — het is samengestelde expertise die je AI-setup in de loop van de tijd waardevoller en efficiënter maakt. Iemand die morgen vanaf nul begint, kan dat proces niet overslaan. Ze kunnen hetzelfde model gebruiken. Ze kunnen jouw skills niet gebruiken.
Ross waarschuwt — en ik denk dat hij gelijk heeft — dat de kloof tussen mensen die dit begrijpen en mensen die dat niet doen snel groter zal worden. De modellen zullen blijven verbeteren. De mensen die weten hoe ze die modellen door goed gebouwde context moeten sturen, zullen dramatisch meer waarde uit elke verbetering halen. De mensen die AI-agents behandelen als magische dozen die "gewoon moeten werken", zullen tegen dezelfde muren blijven aanlopen en het model de schuld geven voor fouten die eigenlijk context-fouten zijn.
Wat ik deze week heb veranderd en wat er gebeurde
Ik wil specifiek zijn over de resultaten, want vage claims zijn waardeloos.
Nadat ik mijn workflow had herbouwd rond het raamwerk van Ross, zag mijn maandag er als volgt uit vergeleken met de maandag ervoor:
Vorige maandag (monolithische CLAUDE.md, geen skills):
- Tokenlimiet twee keer geraakt tijdens een werksessie van 5 uur
- Ongeveer 25 minuten besteed aan het opnieuw uitleggen van context na elke
/clear - 3 afgeronde componenten geproduceerd, waarvan 2 handmatige correcties nodig hadden
- Geschat tokenverbruik: ~850.000 tokens
Deze maandag (CLAUDE.md van 47 regels, 14 actieve skills):
- Tokenlimiet nul keer geraakt tijdens hetzelfde venster van 5 uur
- Context herstellen na
/clearduurde minder dan 2 minuten (skill laadde automatisch de relevante context) - 5 afgeronde componenten geproduceerd, 1 had een kleine fix nodig
- Geschat tokenverbruik: ~340.000 tokens
Zelfde developer. Zelfde model. Zelfde project. De enige variabele was hoe de context was gestructureerd.
De meest verrassende verbetering waren niet de tokenbesparingen — het was de kwaliteitsconsistentie. Met de monolithische config ging de outputkwaliteit merkbaar achteruit naarmate de sessie vorderde en het context window volliep. Met skills begint elke taak met een relatief verse context plus alleen de relevante skill-instructies. De vijfde taak van de dag krijgt dezelfde kwaliteit als de eerste.
De vijf-minuten-versie
Als je niets anders uit dit stuk meeneemt, hier is het uitgedestilleerde raamwerk:
Stop met het laten groeien van je configuratiebestand. Cap het op maximaal 200 regels. Reduceer het tot alleen de instructies die echt op elke interactie van toepassing moeten zijn.
Bouw skills door iteratie, niet door verbeelding. Loop 3-5 keer met de agent door echte taken voordat je een skillbestand schrijft. De edge cases die je tijdens de training ontdekt zijn het meest waardevolle deel van de skill.
Eén agent, veel skills. Weersta de drang om een vloot van gespecialiseerde agents te bouwen. Eén goed geskilde agent presteert beter dan drie slecht gecoördineerde voor de meeste workflows.
Installeer nooit de skills van iemand anders. Bouw je eigen. De context mismatch en beveiligingsrisico's zijn de tijdsbesparing niet waard.
Behandel context als een budget, niet als een container. Elk token in het context window concurreert om de aandacht van het model. Besteed tokens bewust aan informatie die de huidige taak nodig heeft. Verhonger al het andere.
Ross noemt dit een paradigmaverschuiving, en ik denk niet dat dat overdreven is. De developers die context engineering beheersen — die het informatiedieet van hun AI-agents behandelen als een eerste-klas engineering-zorg — gaan beter presteren dan degenen die alles in een configuratiebestand blijven dumpen en hopen dat het model het wel uitvogelt.
De modellen zijn slim genoeg. De vraag is of wij slim genoeg zijn om ze goed te voeden.
Veelgestelde vragen
Heb ik überhaupt een CLAUDE.md of agents.md nodig?
Alleen als je universele conventies hebt die echt op elke interactie van toepassing zijn — taalvoorkeuren, regels voor projectstructuur of propriëtaire patronen die het model niet zou kennen. Houd het onder de 200 regels. Voor de meeste solo-developers zit de sweet spot op 50-100 regels waar je consistente conventies krijgt zonder overdreven token-overhead te betalen.
Hoeveel skills moet ik bouwen voordat ik echte productiviteitswinst zie?
De meeste developers zien een betekenisvolle verbetering na 3-5 goed opgebouwde skills die hun meest herhaalde workflows dekken. Mik niet vooraf op een grote bibliotheek — focus op de taken die je dagelijks doet en bouw van daaruit verder. Ik raakte een merkbaar omslagpunt bij 8 skills.
Kan ik mijn bestaande CLAUDE.md omzetten in skills?
Ja, en dat zou je moeten doen. Groepeer gerelateerde instructies in workflow-specifieke clusters, pas op elke cluster de "drie keer"-test toe en bouw vervolgens skills voor degene die slagen. De instructies die in geen enkele specifieke workflow passen, blijven in je slanke configuratiebestand.
Wat is het verschil tussen skills en MCP tools?
Skills zijn kennispakketten — ze vertellen de agent hoe hij een taak moet aanpakken. MCP tools zijn capaciteiten — ze stellen de agent in staat om acties te ondernemen zoals het lezen van bestanden, het uitvoeren van commando's of het aanroepen van API's. Skills sturen de redenering van de agent; tools breiden uit wat hij kan doen. Ze zijn complementair, niet concurrerend.
Hoe weet ik of mijn context window te vol is?
Let op drie signalen: de agent begint suggesties te herhalen die hij al heeft gedaan, reactietijden worden merkbaar trager, of de agent mist instructies die je duidelijk hebt gegeven. Dit geeft aan dat de context verzadigd is en het model de focus verliest. Gebruik /compact of /clear om ruimte terug te winnen.
Laten we samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.
- Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
