context verslaat de prompt

De agents waar ik dagelijks mee werk, die staan niet op speeltjesdata. Nee. Die draaien op een live monday-bord van een installatiebedrijf, op de systemen die ik voor dat bedrijf beheer, op mijn eigen administratie. Echt werk dus. En juist daar zie ik bij teams die net beginnen elke keer weer hetzelfde gebeuren. Ze gaan schaven aan hun prompts. De één vindt een zinnetje dat net even betere antwoorden geeft, de ander bouwt er een hele bibliotheek met sjablonen bij, en na een paar weken ligt er een indrukwekkende stapel instructies.

En het antwoord? Nog steeds generiek.

Logisch ook. Het model weet nog steeds niks van dat bedrijf. Het weet niet hoe het offerteproces echt loopt. Weet niet welke klant al jaren een uitzondering heeft. Weet niet welke beslissing vorige maand is teruggedraaid, en waarom ook alweer. Elke sessie begint-ie weer bij nul. Kijk, je kunt een stagiair op zijn eerste werkdag de perfecte opdracht meegeven, tot in de puntjes, en toch blijft-ie een stagiair op zijn eerste werkdag.

Waar ik op uitkwam is dit: stop met slimmer vragen, begin met beter vertellen. Prompt engineering heeft een plafond, context engineering niet. Klinkt als een woordspelletje, hè. Is het niet. Het is gewoon het verschil tussen een gereedschap dat je élke sessie opnieuw moet uitleggen waar je mee bezig bent, en een collega die het allang weet.

Een use-case, hoe waardevol die context is. Als ik op een project voor een klant werk en met een implementatie bezig ben, dan vraag ik aan het LLM-model gewoon: “kun je de tenant even vullen met demodata?” Puur dat. Dan heeft hij alle context van die klant, alle context van het project, hij weet precies wat ik wil demoen, want dat staat al omschreven. Ik kan aangeven wat de planning is, welke training als eerste. Dus in plaats van dat ik een hele prompt moet schrijven van “oké, vul deze demodata, het gaat over deze klant, het gaat hierover en het moet voor deze training zijn”, vult hij het systeem gewoon helemaal in met alle data die ik nodig heb.

documentatie voor machines

De kern van hoe ik werk? Documentatie die vooral voor de machine bedoeld is. Die leest het als eerste, nog voordat een mens het openslaat. Concreet: een CLAUDE.md of AGENTS.md in de root van elk project. En daaronder een levende wiki van markdown-bestanden die het hele project beschrijft.

Dat eerste bestand wordt langzaam een soort standaard. Ruim 60.000 repositories hebben er inmiddels eentje, en meer dan twintig tools lezen het automatisch in voordat ze ook maar iets doen. Het is gewoon een tekstbestandje, hoor. Geen schema, geen verplichte velden. En toch bepaalt wat erin staat hoe elke AI-agent zich in jouw project gedraagt. Welke commando’s-ie draait, waar-ie vanaf blijft. En welke conventies er gelden.

En dan de CLAUDE.md zelf. Dat is een instructiebestand dat je in je kennisdatabank of je Claude Code-project neerzet, waarin je je belangrijkste instructies aan het model omschrijft. Dat kan een persoonlijk project zijn, maar ook organisatiebreed. Zo heb je de CLAUDE.md die in het project leeft, en ook eentje die bovenop de hele organisatie leeft. Het is een bestandje dat het model altijd leest: bij elke prompt leest hij dat even snel door en neemt hij die instructies mee. Het zijn een soort gouden instructies. Denk aan: “ik wil dat je teksten altijd humaniseert, geen em-dashes, geen pijltjes.” Dat is een voorbeeldregel die ik heb, omdat ik wil dat mijn teksten menselijk zijn, en niet dat je diezelfde AI-patronen ziet die bij negen van de tien anderen ook langskomen. Of: “ik wil dat je feiten heel goed controleert en geen aannames doet”, waar je de creativiteit van het model binnen de perken houdt.

Die wiki eronder is wat Andrej Karpathy in april 2026 de LLM Wiki ging noemen. En denk daarbij even niet aan een zoekmachine die bij elke vraag opnieuw door je ruwe documenten ploegt. Nee, denk aan een vaste verzameling markdown-pagina’s die tussen jou en je bronnen in hangt. Komt er een nieuwe bron binnen, dan leest de AI die, haalt de kern eruit en verwerkt die in de pagina’s die er al zijn. Tegenstellingen worden gemarkeerd, samenvattingen aangescherpt, verbanden gelegd. Zo wordt de kennis één keer gecompileerd en daarna gewoon bijgehouden. En niet bij elke vraag opnieuw afgeleid.

drie lagen, strikt gescheiden

Hoe ik die kennis opdeel? Dat is elke keer hetzelfde, welk project het ook is. Drie lagen. En de scheiding daartussen, dáár zit het echte werk.

Onderaan liggen de ruwe bronnen. Notities, transcripts, exports, artikelen, dat werk. Die laag is heilig. De AI leest eruit en verandert er nóóit iets aan. Dit is je bron van waarheid, en zodra een agent daar zelf in gaat lopen schrijven, ben je ‘m kwijt.

Daarboven zit de wiki. Een map vol markdown-pagina’s die de AI zelf schrijft en bijhoudt. Een pagina per klant, eentje per concept, een index die elke pagina in één regeltje samenvat, en een log van alles wat al verwerkt is. Die laag is helemaal van de AI. Ik lees, hij schrijft. Zo simpel.

En dan het schema. Eén instructiebestand dat vastlegt hoe de wiki in elkaar steekt, welke conventies er gelden, en wat er moet gebeuren als er een nieuwe bron binnenkomt, of een vraag, of een opschoonbeurt. Dat ene bestandje maakt het verschil tussen een gedisciplineerde wiki-beheerder en zomaar een willekeurige chatbot.

En die scheiding is niet zomaar cosmetisch. Wie mag waar schrijven, wat je bron van waarheid is, hoe een agent zijn weg vindt door honderden pagina’s: dat zijn allemaal vragen over architectuur. Over schrijven gaat het niet. De index laat dat het scherpst zien. Bij elke vraag leest de AI eerst die index, en duikt dan gericht de juiste pagina’s in. En dat schaalt door tot in de honderden pagina’s. Zonder embeddings, zonder aparte zoekmachine eronder. Wat het laat werken is dat de structuur klopt. Mooi geschreven? Hoeft niet eens.

kort verslaat volledig

Is dit nou architectuur, of gewoon een handige schrijftruc? Architectuur. En dat blijkt uit een hoek waar de meeste mensen van opkijken. ETH Zürich zette AGENTS.md-bestanden aan het werk op 138 repositories en 5.694 pull requests. En wat kwam eruit? De meeste van die bestanden maakten de agent alleen maar trager en duurder. Beter werd-ie er niet van. Een automatisch gegenereerd bestand verlaagt het slagingspercentage met gemiddeld 3 procent, en het jaagt de kosten met ruim 20 procent omhoog. En een zelfgeschreven bestand? Dat levert 4 procent op. Meer niet.

De verklaring is best ontnuchterend. De agent volgt je instructies gewoon braaf op. Meer tests, meer checks, meer bestanden inlezen. Heel grondig allemaal, alleen niet altijd wat de taak echt nodig had. En dat codebase-overzicht dat zo veel mensen erin proppen? Dat helpt aantoonbaar niks. Die structuur haalt de agent zelf ook wel boven water, hoor.

Vandaar een paar regels waar ik mezelf streng aan hou. Blijf onder de 150 tot 300 regels, want alles wat erin staat reist elke sessie weer mee. Schrijf commando’s letterlijk op in plaats van ze te omschrijven. Eén goed voorbeeld is meer waard dan drie alinea’s uitleg. Zet keihard neer waar de agent vanaf moet blijven. En dan de regel die bijna iedereen overslaat: laat weg wat de agent zelf ook wel doorheeft.

Ik heb ook een keer de CLAUDE.md fout gemaakt. Ik had ‘m veel te groot gemaakt, met veel te veel context. Als je ‘m constant laat updaten, beschouw dat dan als een keuze. Werk je in een codeerproject en wil je je CLAUDE.md constant verrijken met nieuwe gotchas of kennis, dan raad ik dat af. Ik heb dat voorheen gedaan, en uiteindelijk werd hij 600 regels lang. Je kunt je voorstellen dat hij best veel context gebruikt, wat veel tokens betekent. Dus het is goed om je CLAUDE.md tot maximaal 200 regels te houden, het liefst lager. De richtlijn is onder de 200 regels.

Meer tekst is niet meer context. De helft van context engineering is beslissen wat je eruit laat. En precies daarom noem ik het architectuur. Schrijfwerk is het niet.

wat het oplevert, en wat nog niet

In de praktijk is het ritme heel simpel. Elke werksessie sluit ik af met precies dezelfde opdracht: werk de wiki even bij met wat we vandaag geleerd hebben. Vijf minuten, hooguit. Geen aparte documentatietijd. En de sessie erna begint elke agent, welke tool ik ook pak, met die kennis al binnen. De context overleeft de tool dus gewoon.

En het rendement? Dat zit ‘m in de herhaling. Kom ik bij een tweede klant eenzelfde soort proces tegen, dan hoef ik die hele geschiedenis niet opnieuw uit te leggen. Het patroon staat al in de wiki. De AI legt het naast de nieuwe situatie en ziet zo verschillen die ik zelf allang weer vergeten was.

Even eerlijk blijven, hoor: dit is voorlopig vooral een persoonlijk patroon, en Karpathy houdt het zelf ook nadrukkelijk daar. Met een heel team tegelijk in diezelfde wiki schrijven zonder dat het botst? Dat heb ik nog niet opgelost. Versiebeheer vangt een stuk op. Maar het echte antwoord? Dat heb ik gewoon nog niet.

Maar weet je wat me nog het meest bezighoudt? Hoe óud dit idee eigenlijk is. Vannevar Bush beschreef al in 1945 zijn Memex: een persoonlijke, gecureerde kennisstore waarin de verbanden tussen documenten net zo veel waard zijn als de documenten zelf. Alleen, wat Bush nooit opgelost kreeg, was wie al dat onderhoud dan doet. Want kennisbanken gaan dood zodra de onderhoudslast harder groeit dan wat ze opleveren. En een LLM? Die verveelt zich niet, die vergeet geen enkele kruisverwijzing en werkt zo vijftien pagina’s bij in één beweging. Tachtig jaar lang liet dat onderhoud elke kennisbank versloffen. En het is niet opgelost doordat wij ineens gedisciplineerder zijn geworden. Het is opgelost doordat het werk terechtkwam bij de enige medewerker die het nooit beu wordt.