De kennis die in je code verstopt zit

Iets verontrustends voor elke CTO en lead developer: de meest uitgebreide kennis over je bedrijf zou best eens ergens kunnen wonen waar je nooit naar kijkt — in je productiecode.

Een recent onderzoekspaper van het ServiceMatch-team verkent een provocerend idee. Ze stellen dat volwassen software niet alleen instrumenten zijn die je bedrijf draaiende houden — het zijn uitvoerbare representaties van alles wat je organisatie heeft geleerd. Het lastige? Die kennis zit al die tijd verborgen in repositories die alleen door compilers werden gelezen.

De documentatiefabel

We kennen het allemaal. Een nieuwe ontwikkelaar komt erbij en krijgt een muur van Confluence-pagina's, architecture decision records en wiki's. "Dit brengt je snel op de hoogte," zegt iemand met optimistische zekerheid.

Dat klopt niet.

Documentatie vangt wat iemand het waard vond om op te schrijven, op een moment dat jaren geleden kan zijn. Het mist de edge cases. Het mist de discussies die beslissingen vormgaven. Het mist de bedrijfslogica die evolueerde door duizenden commits, elk met een echte wereld-scenario.

Volgens Peter Naur (ja, die van Backus-Naur form) kan programmadocumentatie nooit de volledige "theorie" achter een systeem vastleggen. Het echte begrip zit in hoofden van mensen. En als die vertrekken, verdwijnt de theorie met ze.

Maar hier wordt het interessant.

AI verandert het lezersprobleem

Naur's argument ging over twee types lezers: compilers (die code uitvoeren zonder begrip) en mensen (die het langzaam en duur begrijpen). De onmogelijkheid van documentatie-herstel ging ervan uit dat er geen andere lezer bestond.

Large language models zijn een derde type lezer. En ze zijn verrassend goed in het reconstrueren van impliciete theorieën ingebed in code.

Het ServiceMatch-systeem levert overtuigend bewijs. Hun CMDB-platform codeert enterprise configuratiemanagement-kennis die pagina's zou vullen als het als proza was geschreven. Maar hier is het punt — het IS al geschreven, alleen niet als proza. Het staat in code.

Neem hun identity resolution logica. In plaats van een consultant's essay over "hoe apparaat-identiteit werkt," hebben ze een configuratiebestand met gewichten: serienummer (25), hostname (25), asset tag (25), IP-adres (20), MAC-adres (15). Plus confidence thresholds en conflict resolution rules. Elk getal vertegenwoordigt een argument dat iemand won. Elk conflict type vertegenwoordigt een echte incident dat ergens gebeurde.

Dit is geen beschrijving van het beleid. Dit IS het beleid, dat elke nacht draait tegen echte enterprise-omgevingen.

Wat dit betekent voor je team

Voor developers en technisch leiders heeft dit onderzoek praktische implicaties:

Je code is documentatie die je niet hebt onderhouden — en dat heeft voordelen. Anders dan vergeelde wiki-pagina's wordt code in productie constant gevalideerd. Als de documentatie het niet eens is met de code, is de documentatie fout.

AI-tools worden steeds beter in het extraheren van deze kennis. We bewegen naar een wereld waar je een AI kunt vragen "hoe handelen we apparaat-identiteitsconflicten af" en niet alleen documentatie krijgt, maar de daadwerkelijke redenering ingebed in de gewichten en thresholds.

De echte kennis zit in de edge cases. De hoofdstromen zijn meestal goed gedocumenteerd. Het is de speciale afhandeling, de uitzonderingen, de hoekgevallen die over jaren zijn opgelost die het diepe institutionele begrip bevatten.

Het waarschuwingssignaal

Er is een ongemakkelijke conclusie: als je bedrijfslogica alleen in je code zit, en je code heeft slechte testdekking, onduidelijke naming of chaotische structuur, dan zit je op een berg kennis die nauwelijks te extraheren valt.

Het ServiceMatch-team ontdekte dat hun claim — dat "de repository volstaat" — op voorspelbare manieren breekt. Naur's tacit residue is real. Sommige kennis leeft echt alleen in hoofden van mensen.

Maar de sterkere bevinding is dat er meer in code overleeft dan we dachten. De repository vangt veel meer theorie dan documentatie ooit kon — we hadden alleen een nieuw type lezer nodig om het eruit te halen.

Wat je hiermee doet

Als je een startup of groeiend techbedrijf bent, hier is een framework:

1. Vertrouw je code meer dan je docs wanneer ze het niet eens zijn
2. Schrijf code die zijn redenering documenteert — betekenisvolle variabelenamen, duidelijke functies, comments die uitleggen WAAROM, niet alleen WAT
3. Behandel configuratie als institutionele kennis — die gewichten en thresholds zijn beslissingen die het waard zijn om te bewaren
4. Begin met het verkennen van AI-tools die je codebase kunnen bevragen als kennisbron

De code die je vandaag schrijft is morgen's institutionele kennis. Maak er iets van.