Terug naar home

Architectuur & Integratie

context verslaat de prompt

Over documentatie die voor machines is geschreven, en waarom een betere prompt je AI niet slimmer maakt.

Ik zie bij vrijwel elk team dat met AI begint hetzelfde ritueel. Er wordt geschaafd aan prompts. Iemand ontdekt een formulering die betere antwoorden geeft, iemand anders bouwt een bibliotheek met sjablonen, en na een paar weken heeft het team een indrukwekkende verzameling instructies. En toch blijft elk antwoord generiek.

De reden is simpel. Het model weet nog steeds niets van het bedrijf. Niet hoe het offerteproces loopt, niet welke klant welke uitzondering heeft, niet welke beslissing vorige maand is teruggedraaid en waarom. Elke sessie begint bij nul. Je kunt een stagiair op zijn eerste werkdag de perfecte opdrachtomschrijving geven; hij blijft een stagiair op zijn eerste werkdag.

Mijn omkering: stop met slimmer vragen, begin met beter vertellen. Geen prompt engineering maar context engineering. Dat is geen woordspel. Het is het verschil tussen een gereedschap dat je elke keer opnieuw moet uitleggen wat je doet, en een collega die het al weet.

documentatie voor machines

De kern van mijn werkwijze is documentatie die niet voor mensen is geschreven maar voor machines. Concreet: een CLAUDE.md of AGENTS.md in de root van elk project, en daaronder een levende wiki van markdown-bestanden die het project beschrijft.

Dat eerste bestand is hard op weg een standaard te worden. Ruim 60.000 repositories hebben inmiddels een AGENTS.md en meer dan twintig tools lezen het automatisch voordat ze aan het werk gaan. Het is een gewoon tekstbestand, zonder schema en zonder verplichte velden. Wat erin staat bepaalt hoe elke AI-agent zich in jouw project gedraagt: welke commando’s hij draait, waar hij vanaf blijft, welke conventies gelden.

De wiki eronder is het patroon dat Andrej Karpathy in april 2026 de LLM Wiki noemde. Geen zoekmachine die bij elke vraag opnieuw door ruwe documenten ploegt, maar een persistente verzameling markdown-pagina’s die tussen jou en je bronnen in zit. Bij elke nieuwe bron leest de AI, haalt de kern eruit en verwerkt die in de bestaande pagina’s. Tegenstellingen worden gemarkeerd, samenvattingen aangescherpt, verbanden gelegd. Kennis wordt één keer gecompileerd en daarna actueel gehouden, niet bij elke vraag opnieuw afgeleid.

drie lagen, strikt gescheiden

Hoe ik projectkennis structureer is steeds hetzelfde, ongeacht het project.

Laag één: de ruwe bronnen. Notities, transcripts, exports, artikelen. Deze laag is heilig. De AI leest eruit maar wijzigt er nooit iets aan. Dit is de bron van waarheid.

Laag twee: de wiki. Een map met markdown-pagina’s die de AI zelf schrijft en onderhoudt. Een pagina per klant, een pagina per concept, een index die elke pagina in één regel samenvat, een chronologisch log van alles wat verwerkt is. Deze laag is volledig van de AI. Ik lees, de AI schrijft.

Laag drie: het schema. Eén instructiebestand dat vastlegt hoe de wiki is opgebouwd, welke conventies gelden en wat er moet gebeuren bij een nieuwe bron, een vraag of een opschoonbeurt. Dit ene bestand maakt het verschil tussen een gedisciplineerde wiki-beheerder en een willekeurige chatbot.

Die scheiding is niet cosmetisch. Wie mag waar schrijven, wat is de bron van waarheid, hoe vindt een agent zijn weg door honderden pagina’s. Dat zijn architectuurvragen, geen schrijfvragen. De index is daar het beste voorbeeld van: de AI leest bij elke vraag eerst de index en duikt dan gericht in de juiste pagina’s. Dat werkt tot in de honderden pagina’s, zonder embeddings en zonder aparte zoekinfrastructuur. Niet omdat de tekst zo mooi geschreven is, maar omdat de structuur klopt.

kort verslaat volledig

Het bewijs dat dit een architectuurdiscipline is en geen schrijftruc komt uit een hoek die veel mensen verrast. ETH Zürich testte AGENTS.md-bestanden op 138 repositories en 5.694 pull requests. De uitkomst: de meeste van die bestanden maken de agent trager en duurder, niet beter. Een automatisch gegenereerd bestand verlaagt het slagingspercentage met gemiddeld 3 procent en verhoogt de kosten met ruim 20 procent. Zelfs een zelf geschreven bestand levert maar 4 procent op.

De verklaring is ontnuchterend: de agent volgt de instructies trouw op. Meer tests, meer checks, meer bestanden lezen. Grondig, maar niet per se wat de taak nodig had. En een codebase-overzicht helpt aantoonbaar niet; die structuur vindt de agent zelf.

Daarom gelden er harde regels. Onder de 150 tot 300 regels blijven, want elke regel reist mee in elke sessie. Commando’s letterlijk opschrijven in plaats van omschrijven. Eén goed voorbeeld boven drie alinea’s uitleg. Expliciete grenzen: wat de agent nooit aanraakt. En vooral: weglaten wat de agent zelf kan vinden.

Meer tekst is dus niet meer context. Context engineering is net zo goed beslissen wat er niet in gaat als wat er wel in gaat. Dat is precies wat architectuur is.

wat het oplevert, en wat nog niet

In de praktijk is het ritme simpel. Elke werksessie eindigt met dezelfde opdracht: werk de wiki bij met wat we vandaag hebben geleerd. Vijf minuten, geen aparte documentatietijd. De volgende sessie begint elke agent, welke tool dan ook, met die kennis. De context overleeft de tool.

Het rendement zit in de herhaling. Als ik bij een tweede klant een vergelijkbaar proces tegenkom, hoef ik mijn projectgeschiedenis niet opnieuw uit te leggen. De wiki bevat het patroon, de AI past het toe op de nieuwe context, en ziet verschillen die ik allang vergeten was.

Eerlijk is eerlijk: dit is in de huidige fase vooral een persoonlijk patroon, en Karpathy positioneert het zelf ook zo. Met een heel team tegelijk in dezelfde wiki schrijven zonder conflicten heb ik nog niet opgelost. Versiebeheer vangt een deel op, maar het echte antwoord heb ik nog niet.

Wat me het meest bezighoudt is hoe oud dit idee eigenlijk is. Vannevar Bush beschreef in 1945 zijn Memex: een persoonlijke, gecureerde kennisstore waarin de verbanden tussen documenten net zo waardevol zijn als de documenten zelf. Het deel dat Bush nooit oploste was wie het onderhoud doet. Mensen geven kennisbanken op omdat de onderhoudslast sneller groeit dan de waarde. Een LLM verveelt zich niet, vergeet geen kruisverwijzing en werkt vijftien pagina’s bij in één beweging. Het probleem dat tachtig jaar lang elke kennisbank liet versloffen is niet opgelost doordat wij gedisciplineerder werden, maar doordat het onderhoud terechtkwam bij de enige medewerker die het nooit beu wordt.

nlen