Afgelopen week loste ik voor de derde keer hetzelfde serverprobleem op. PHP workers die vastlopen, een website die 508 errors geeft, een klant die belt. Ik wist dat ik dit eerder had opgelost. Ik wist zelfs hoe. Maar de oplossing zat ergens in een chatgeschiedenis van twee maanden geleden, en ik kon hem niet vinden.
Dat moment was de trigger.
Het probleem dat niemand benoemt
Ik werk al meer dan twintig jaar met websites. Ik beheer vier servers, driehonderd klanten, vijfhonderd domeinen. En wat me steeds meer opvalt is dat het probleem nooit de kennis is. Het probleem is dat kennis verdwijnt zodra je hem gebruikt.
Je lost iets op, je gaat door naar de volgende klant, en drie maanden later begin je weer bij nul. Elke chatgeschiedenis met Claude, elke terminal-sessie, elke mail met een oplossing erin: het verdampt. Je wordt niet slimmer van je eigen werk. Je herhaalt het alleen.
Een gist die bleef hangen
Andrej Karpathy, een van de grondleggers van de huidige AI-golf, publiceerde begin april een idee dat hij LLM Wiki noemde. De kern is simpel: laat een AI niet steeds opnieuw zoeken in je documenten, maar laat hem een wiki bouwen en bijhouden. Een plek waar kennis zich opstapelt in plaats van verdampt.
Het verschil met hoe de meeste mensen AI gebruiken: bij RAG (wat tools als NotebookLM doen) zoekt de AI elke keer opnieuw in je bestanden. Bij een wiki compileert de AI je kennis één keer, houdt die bij, legt verbanden, en signaleert tegenspraken. De kruisverwijzingen bestaan al. De patronen zijn al zichtbaar.
Wat mij aansprak: ik had negentig procent van de infrastructuur al staan. Obsidian voor notities, Claude Code voor development, scheduled tasks die elke ochtend mijn servers checken. Wat ontbrak was die compilatielaag. De plek waar losse ervaringen kennis worden.
Wat ik heb gebouwd
Mijn hele werkmap staat nu in een git repository op GitHub, privé, die synchroniseert tussen mijn Mac Mini (altijd aan, draait taken) en mijn MacBook (mobiel werkstation). Dropbox is eruit. Dat was trouwens een les op zich: Dropbox en git op dezelfde map is vragen om problemen. Dropbox synchroniseert de interne git-bestanden mee en kan je repository corrupt maken. Nu draait de Obsidian Git plugin op beide machines: auto-pull elke tien minuten, auto-commit elke dertig. Wijzigingen op de ene machine zijn binnen minuten zichtbaar op de andere. En alles heeft versiebeheer. Als Claude iets verkeerd compileert in de wiki, rol ik het terug.
In die repository zit een wiki-map die volledig door Claude wordt onderhouden.
De structuur is simpel. Zeven domeinen: servers, WordPress, klanten, SEO, business, design, content. Per domein twee soorten pagina's: entity pages (een specifieke server, een specifieke branche) en concept pages (een terugkerend patroon, een probleem dat steeds weer opduikt).
Elke ochtend om zeven uur checkt een geautomatiseerde taak mijn vier servers. Niet nieuw, dat deed ik al. Wat nieuw is: na de check schrijft Claude de bevindingen terug naar de wiki. Als server03 weer LVE-limits raakt, staat dat niet alleen in een los rapport. Het wordt toegevoegd aan de concept-pagina over resource exhaustion, met een link naar de server, het account, en de vorige keren dat dit speelde.
Na een week zie je patronen. Na een maand heb je een kennisbasis.
Waar het interessant wordt
De servers zijn het makkelijke deel. Technische problemen, concrete oplossingen, meetbare resultaten. Maar dezelfde aanpak werkt breder.
Ik bouw websites voor klanten in de bouw, de zorg, de horeca. Wat me opvalt is dat klanten in dezelfde branche steeds dezelfde dingen vragen. Dezelfde plugin-conflicten. Dezelfde Elementor-patronen. Dezelfde SEO-uitdagingen. Die kennis zat in mijn hoofd en in losse projectmappen. Nu wordt het gecompileerd naar branche-pagina's in de wiki.
Elke maandag draait er een lint-taak die de wiki checkt: zijn er incidenten die niet verwerkt zijn, zijn er patronen die nog geen eigen pagina hebben, zijn er pagina's die verouderd zijn. Het systeem onderhoudt zichzelf.
Wat ik hiervan leer
Ik merk dat het moeilijkste niet de techniek is. De techniek is een middag werk. Het moeilijkste is de gewoonte. Aan het eind van een Claude Code sessie zeggen: "schrijf dit terug naar de wiki." Dat is één zin. Maar het is een zin die je moet aanleren.
Karpathy schrijft dat mensen wikis opgeven omdat het onderhoud sneller groeit dan de waarde. Dat klopt. Ik heb genoeg Notion-databases opgegeven om dat te bevestigen. Het verschil nu is dat de AI het onderhoud doet. Ik hoef alleen de juiste vragen te stellen en af en toe te sturen.
Of dat over zes maanden nog steeds werkt, weet ik niet. Maar na een week zoek ik dingen niet meer opnieuw uit.