Het geheugen buiten de machine
Een taalmodel kan veel weten en toch niets van gisteren onthouden. Wat gebeurt er wanneer een organisatie haar werkwijze buiten de machine leert bewaren?
Conceptuele illustratie, gemaakt met AI.
Er bestaat een vreemd soort vergetelheid dat alleen bij zeer intelligente systemen lijkt te passen.
Een model kan een moeilijke fout in code vinden, een genuanceerde tekst schrijven en een onbekende technische handleiding doorgronden. Maar vraag het de volgende dag waarom jouw server op een bepaalde manier is ingericht, en het weet niets—tenzij iemand dat verhaal opnieuw vertelt.
De machine is niet dom geworden. Ze is eenvoudigweg nooit bij gisteren geweest.
Toen we Codex op meer computers gingen gebruiken, werd dat verschil steeds zichtbaarder. Op de ene machine bestond een goede werkwijze voor video. Op een andere was vastgelegd hoe de televisie veilig kon worden bediend. Er waren instructies voor fotografie, websites, productieplanning, Blender en serverbeheer. Los van elkaar waren ze nuttig. Samen vormden ze iets wat op een geheugen begon te lijken.
Alleen woonde dat geheugen nog op te veel plaatsen.
Een gesprek is geen archief
Een chatgeschiedenis voelt als geheugen omdat we kunnen terugbladeren. Toch is zij een slecht fundament voor een organisatie.
Gesprekken bevatten omwegen, tijdelijke gegevens, onuitgewerkte ideeën en soms informatie die juist niet verder verspreid mag worden. Ze vertellen wat er gebeurde, maar zelden in de meest bruikbare vorm waarom een keuze werd gemaakt en hoe die veilig herhaald kan worden.
Een goede werkwijze is kleiner dan haar ontstaansgeschiedenis.
Ze zegt bijvoorbeeld: controleer eerst welke machine de taak aankan. Gebruik voor zware renders de GPU-pc. Bewaar sleutels lokaal. Werk op een aparte branch. Laat een live website pas veranderen nadat de tests slagen en de pull request is gereviewd. Kijk na de deployment niet alleen naar een groene status, maar ook naar wat een bezoeker werkelijk ziet.
Zo’n beschrijving is geen verslag. Het is gecondenseerde ervaring.
Zesenveertig manieren om niet opnieuw te beginnen
We brachten de eigen Codex-skills daarom samen in één private GitHub-repository. Op het moment van inventariseren stonden daar 46 VDE-skills.
Het woord skill klinkt misschien groter dan het is. Een skill is in de kern een onderhoudbare instructie voor terugkerend werk. Zij beschrijft wanneer een werkwijze van toepassing is, welke bronnen eerst moeten worden gelezen, wat veilig kan worden gedaan, waar toestemming nodig is en wanneer het resultaat werkelijk klaar is.
Dat kan gaan over het afwerken van een RAW-foto, het deployen van een productieplanner, het beheren van een WordPress-site of het wakker maken van een krachtige computer. De waarde zit niet alleen in de handelingen. Ze zit in de grenzen ertussen.
Een installatie-instructie zonder stopvoorwaarde kan schade veroorzaken. Een contentskill zonder broncontrole kan overtuigende onzin produceren. Een machineprofiel zonder opslaggrenzen kan een technisch bereikbare schijf verwarren met een toegestane werkplek.
Het geheugen dat we wilden bouwen, moest daarom ook kunnen zeggen: hier niet.
Waarom Git en geen groot document
We hadden alles in één lang handboek kunnen zetten. Dat zou overzichtelijk lijken, maar snel onhandelbaar worden.
Git biedt iets wat een gewoon document nauwelijks zichtbaar maakt: verandering heeft een geschiedenis. Een nieuwe werkwijze komt binnen via een branch. De verschillen zijn leesbaar. Controles kunnen automatisch worden uitgevoerd. Iemand kan een voorstel beoordelen voordat het de gedeelde werkelijkheid wordt. Na de merge kunnen andere machines precies die gereviewde toestand ophalen.
Tussen 31 augustus en 11 september waren in de centrale configuratierepository 31 afzonderlijke pull-requestnummers terug te vinden. Dat getal is geen kwaliteitsbewijs op zichzelf. Het laat wel zien dat de werkwijze niet als een eenmalige installatie werd behandeld, maar als iets dat voortdurend wordt aangescherpt.
Git maakt geheugen niet waar. Het maakt geheugen betwistbaar.
Je kunt terugzien wanneer een regel ontstond. Je kunt ontdekken dat twee machines andere aannames hadden. Je kunt een onhandige beslissing herstellen zonder te doen alsof ze nooit heeft bestaan. Dat lijkt op een gezonde vorm van institutioneel geheugen: niet een foutloos verhaal, maar een spoor van verantwoorde veranderingen.
Drieënnegentig namen, vijf gekende werelden
Naast skills kwam er een catalogus voor projecten. Die bevatte 93 GitHub-repositories van VDE.
Dat betekent niet dat er 93 actieve, goed begrepen projecten waren. Integendeel. Slechts acht stonden als gevolgd geregistreerd en vijf hadden gecureerde context. Juist dat onderscheid is belangrijk.
Een lijst met repositories zegt alleen wat bestaat. Projectcontext zegt wat een naam betekent, welk project actief is, welke architectuur het gebruikt, hoe het wordt getest en welke beperkingen gelden. Zonder die context kan een AI een map vinden en toch in het verkeerde verhaal terechtkomen.
We kozen daarom voor lagen.
De centrale catalogus weet dat “kaarsen maaklijst” verwijst naar de canonical repository van de Alchemilla-productieplanner. De repository zelf bewaart de projectinstructies. Een operationele skill beschrijft terugkerend beheer. Een machineprofiel vertelt waar deployment technisch thuishoort.
Niet alles hoeft overal te worden onthouden.
Dat inzicht maakt het systeem lichter. Een fotograaf hoeft bij een RAW-selectie niet de volledige WordPress-geschiedenis te laden. Een servertaak hoeft niet te weten hoe een arcadekast cinematografisch wordt belicht. Het juiste geheugen verschijnt pas wanneer het werk erom vraagt.
Geheimen die niet gedeeld mogen worden
Centraliseren klinkt al snel als alles verzamelen. Dat was nadrukkelijk niet het doel.
Wachtwoorden, API-sleutels, browserprofielen, privésleutels, sessies en ruwe chatgeschiedenis horen niet in de repository. Ook koppelingen met apparaten blijven lokaal. De gedeelde instructie mag beschrijven hoe een verbinding veilig wordt gecontroleerd, maar niet het geheim bevatten waarmee die verbinding wordt geopend.
Er zit een bredere les in dat onderscheid.
Geheugen is niet hetzelfde als totale registratie. Een menselijk geheugen is waardevol doordat het betekenis geeft, niet doordat het iedere seconde bewaart. Een organisatie die werkelijk alles opslaat, kan uiteindelijk minder begrijpen omdat signalen verdwijnen in ruis en omdat mensen niet meer weten wat vertrouwelijk behoort te blijven.
Het bruikbare geheugen is gecureerd. Het laat weg met aandacht.
Wie leert hier van wie?
In De spiegel in de sandbox schreef ik dat een doel en een meetbare beloning niet vanzelf vertellen wat goed is om te doen. Dezelfde gedachte geldt voor instructies.
Een skill kan een machine leren hoe wij willen werken. Maar tijdens het schrijven ervan worden wij gedwongen onze eigen gewoonten te onderzoeken. Waarom doen we deze controle? Welke uitzondering vertrouwen we stilzwijgend op ervaring? Wanneer vinden we snelheid belangrijker dan review? Wie mag uiteindelijk beslissen dat iets live gaat?
De mens schrijft de instructie, maar de instructie stelt vragen terug.
Misschien is dat de verrassendste opbrengst van het centrale geheugen. Niet dat een AI voortaan alles onthoudt, maar dat wij beter leren kiezen wat het onthouden waard is.
Ergens in GitHub staat nu geen kopie van ons denken, maar een groeiende kaart van onze aandacht.
Iedere branch voegt een zijpad toe.
Iedere review vraagt of dat pad werkelijk begaanbaar is.
En iedere machine die de gemergde versie ophaalt, begint niet meer helemaal alleen aan de dag.