Deze post is een zijstap. Als je deze blog volgt, weet je dat het over één ding gaat: Claude Code gebruiken om sneller .NET-code te shippen. Praktische workflows, echte voorbeelden, geen hype.

Vandaag stap ik even buiten die lijn. Niet omdat ik geen Claude Code-onderwerpen meer heb — verre van — maar omdat er deze week iets gebeurde in de AI-wereld waar ik denk dat elke developer die AI-agents gebruikt op moet letten. Zelfs als je geen kennissystemen bouwt. Zelfs als je nog nooit van RAG hebt gehoord.

Andrej Karpathy publiceerde een idee, en het klikte.

Wie publiceerde wat

Op 2 april postte Andrej Karpathy — voormalig hoofd AI bij Tesla, medeoprichter van OpenAI, en een van de meest gerespecteerde stemmen in deep learning — op X dat een groeiend deel van zijn LLM-tokenverbruik niet naar code ging, maar naar kennis. Organiseren, verbinden, onderhouden.

Twee dagen later publiceerde hij een GitHub Gist met de titel “LLM Wiki.” Geen framework. Geen library. Een idee-bestand — een document dat je in je AI-agent plakt zodat die je kan helpen een kennisbank op te bouwen volgens zijn patroon.

De gist kreeg in dagen 5.000+ sterren en bijna 3.000 forks. Implementaties doken binnen uren op. VentureBeat schreef erover. De developer-community ging ermee aan de slag.

Waarom? Omdat het een probleem benoemde dat de meesten van ons voelen maar niet hebben verwoord.

Het probleem van dezelfde vraag twee keer stellen

Dit is hoe de meeste mensen tegenwoordig LLM’s gebruiken met hun eigen documenten. Je hebt een verzameling bestanden — misschien onderzoekspapers, vergadernotities, technische documentatie. Je gebruikt een vorm van RAG: het systeem knipt je documenten in stukken, slaat embeddings op in een vectordatabase, en haalt relevante fragmenten op wanneer je een vraag stelt.

Het werkt. Maar er is een fundamentele beperking: elke query begint van nul. De LLM herontdekt kennis elke keer opnieuw. Hij herinnert zich niet dat hij gisteren al de relatie tussen twee concepten in je documenten had uitgezocht. Hij bouwt geen begrip op.

Als je ooit dezelfde vraag over je codebase hebt gesteld aan een AI in twee verschillende sessies en twee verschillende (even matige) antwoorden hebt gekregen — dan heb je dit probleem gevoeld.

Karpathy’s inzicht: wat als de LLM niet alleen ophaalde uit je documenten, maar actief een kennisbank onderhield? Wat als elke vraag het systeem slimmer maakte, niet alleen jou?

Het LLM Wiki-patroon

De architectuur is verrassend eenvoudig. Drie lagen:

Laag 1: Ruwe bronnen. Je originele documenten — artikelen, papers, transcripten, databestanden. Deze zijn onveranderlijk. De LLM leest ze maar raakt ze nooit aan.

Laag 2: De wiki. Een verzameling markdown-bestanden die de LLM schrijft en onderhoudt. Samenvattingen, conceptpagina’s, entiteitpagina’s, vergelijkingen, kruisverwijzingen. Dit is de werkruimte van de LLM. Je bewerkt het zelden rechtstreeks.

Laag 3: Het schema. Configuratiebestanden (denk aan CLAUDE.md of AGENTS.md) die de LLM vertellen hoe de wiki onderhouden moet worden. Welke structuur te volgen, welke conventies te gebruiken, welke workflows uit te voeren.

Dat is het. Markdown-bestanden in mappen. Geen vectordatabase. Geen embedding-pipeline. Geen infrastructuur buiten een teksteditor en git.

Drie operaties, niet één

De echte innovatie is niet het opslagformaat — het is de workflow. Karpathy definieert drie operaties:

Ingest. Je dropt een nieuwe bron in de raw-map en vraagt de LLM om deze te verwerken. Hij leest het document, schrijft een samenvattingspagina, werkt relevante concept- en entiteitpagina’s bij, voegt kruisverwijzingen toe en logt de actie. Eén bron raakt typisch 10 tot 15 wiki-pagina’s.

Query. Je stelt vragen, maar tegen de wiki — niet de ruwe bronnen. De LLM leest de index, vindt relevante pagina’s en stelt een antwoord samen met bronvermeldingen. Als het antwoord waardevol genoeg is, gaat het terug in de wiki als nieuwe pagina. Je verkenning wordt een kennisartefact.

Lint. Periodiek vraag je de LLM om de wiki te auditen. Tegenstrijdigheden vinden. Verouderde claims markeren. Weespagina’s identificeren. Ontbrekende kruisverwijzingen opsporen. Kennisgaten voorstellen die het waard zijn om te vullen. Dit is de onderhoudspass die het systeem eerlijk houdt.

Dit is wat het anders maakt dan een chatsessie. Chat is vluchtig. Een wiki stapelt zich op.

Waarom developers het zouden moeten interesseren

Misschien denk je: “Ik schrijf code, geen onderzoekspapers. Waarom zou ik me druk maken om een notitiepatroon?”

Drie redenen.

Je AI-agent heeft dit probleem al. Als je Claude Code, Codex, of welke agentische codingtool dan ook gebruikt met een CLAUDE.md of vergelijkbaar contextbestand — gefeliciteerd, je onderhoudt al een mini-kennisbank. Het LLM Wiki-patroon is een meer doordachte versie van wat je al doet wanneer je projectinstructies schrijft voor je agent.

Kenniswerk eet codeerwerk op. Karpathy zei het direct: een groeiend deel van zijn tokendoorvoer gaat naar kennis, niet code. Als je features bouwt met AI, besteed je meer tijd aan context, beslissingen en architectuur dan aan code typen. Het LLM Wiki-patroon erkent deze verschuiving.

De tooling is wat je al kent. Obsidian (of welke markdown-editor dan ook), git voor versiebeheer, bestanden in mappen. Geen nieuwe infrastructuur. Geen vendor lock-in. Als je markdown kunt lezen en git kunt gebruiken, kun je dit patroon gebruiken.

Wat ik er overtuigend aan vind

Er zijn twee dingen aan Karpathy’s aanpak die specifiek bij mij resoneerden.

Ten eerste: de LLM als boekhouder, niet als orakel. Karpathy formuleert het goed — het vervelende deel van kennis onderhouden is niet het lezen of nadenken. Het is de boekhouding. Kruisverwijzingen. Samenvattingen bijwerken. Consistentiecontroles. Dat is precies het soort werk waar LLM’s goed in zijn: systematisch, repetitief, aandacht vereisend maar geen creativiteit.

Ten tweede: het idee-bestand als distributieformaat. Karpathy publiceerde geen tool. Hij publiceerde een patroon — een document dat je in je agent plakt en het een nieuwe capability leert. Dat is een distributiemodel dat alleen werkt in het tijdperk van AI-agents. Geen installatie. Geen dependencies. Gewoon een goed geschreven prompt. Het feit dat tientallen implementaties binnen dagen verschenen bewijst dat het model werkt.

Dit is trouwens ook precies hoe Claude Code-skills werken. Een goed gestructureerd instructiebestand dat de agent een workflow leert. Karpathy’s gist is in wezen een skill-definitie voor kennisbeheer.

De beperkingen

Ik zou niet eerlijk zijn als ik de beperkingen niet noemde.

Schaal. Het patroon werkt goed voor persoonlijk onderzoek en kleine teamcontexten — ruwweg tot een paar honderd bronnen. Daarboven is pure index-gebaseerde navigatie waarschijnlijk niet genoeg, en heb je een vorm van retrieval-laag erbovenop nodig. Karpathy erkent dit.

Drift. Een wiki die door een LLM wordt onderhouden kan fouten net zo overtuigend consolideren als inzichten. De lint-pass helpt, maar vervangt menselijk oordeel niet. Iemand moet eigenaar zijn van de kwaliteit van de kennisbank, vooral in teamsettings.

Curatie. Het systeem gaat ervan uit dat je bewust bronnen van hoge kwaliteit kiest. Het is een compiler voor gecureerde kennis, geen webcrawler. Rommel erin, overtuigend geschreven rommel eruit.

Dit zijn echte beperkingen. Maar voor de sweet spot — persoonlijk onderzoek, afgebakende domeinen, teamkennis — is het patroon opmerkelijk praktisch.

Het grotere plaatje

Wat Karpathy eigenlijk zegt, onder de architectuur, is dit: stop met je LLM behandelen als alleen een antwoordmachine. Behandel het als een kenniswerker.

Een antwoordmachine geeft je antwoorden en vergeet. Een kenniswerker bouwt artefacten die blijven bestaan en zich opstapelen. De LLM Wiki is één implementatie van dat idee, maar het principe is breder.

Elke developer die dagelijks AI-agents gebruikt, is — of ze het nu beseffen of niet — aan het uitzoeken hoe ze AI-werk kunnen laten accumuleren in plaats van verdampen. Hoe vluchtige chatsessies om te zetten in duurzame waarde. Het LLM Wiki-patroon biedt één helder antwoord.

Wil je het proberen?

Als je met dit patroon wilt experimenteren:

  1. Lees Karpathy’s originele gist — het is de primaire bron en verrassend leesbaar
  2. Kies een onderwerp waar je onderzoek naar doet
  3. Maak een map met raw/, wiki/, en een instructiebestand voor je agent
  4. Drop er een paar bronnen in en vraag je agent om ze te verwerken

Je hebt geen speciale tooling nodig. Obsidian werkt goed als viewer, maar elke markdown-editor volstaat. Git geeft je gratis versiegeschiedenis.

Het patroon is het product. Dat is het hele punt.

Volgende week zijn we terug bij het vaste programma: Claude Code-workflows voor .NET-developers. Maar soms is het meest praktische wat je kunt doen even terugstappen en opmerken wanneer iemand een probleem beter formuleert dan jij erover hebt nagedacht.