Din kod vet mer om din verksamhet än någon anställd

Här är något som borde få varje CTO och utvecklare att känna obehag: den mest sofistikerade förståelsen för din verksamhet finns kanske ingen annan stans än i produktionskoden.

En färsk forskningsrapport från teamet på ServiceMatch utforskar en provocerande idé. De menar att mogna mjukvarusystem inte bara är verktyg som driver din verksamhet — de är körbara representationer av allt din organisation har lärt sig om den. Det kluriga? Den kunskapen har gömt sig i fullt dagsljus, låst inne i repositories som bara lästs av kompilatorer och (ibland) människor.

Myten om dokumentation

Vi har alla varit där. En ny utvecklare börjar och får en vägg av Confluence-sidor, arkitekturbeslut och Wiki-inlägg. "Det här kommer att få dig up-to-speed," säger någon med optimistisk säkerhet.

Det kommer det inte.

Dokumentation fångar det någon tyckte var värt att skriva ner, vid en tidpunkt som kan ha varit år sedan. Den missar edge cases. Den missar diskussionerna som ägde rum i möten och som formade beslut. Den missar affärslogiken som utvecklades genom tusentals commits, var och en som kämpade med ett verkligt scenario.

Enligt Peter Naur (ja, samma Naur som gav oss Backus-Naur form) kan programdokumentation aldrig fullt ut fånga "teorin" bakom ett system. Den verkliga förståelsen lever i människors huvuden. När de personerna slutar, försvinner teorin med dem.

Men här blir det intressant.

AI förändrar läsarproblemet

Naurs argument handlade om två typer av läsare: kompilatorer (som kör kod utan att förstå den) och människor (som förstår den långsamt och dyrt). Omöjligheten av dokumentationsåteruppväckande förutsatte att ingen annan typ av läsare fanns.

Stora språkmodeller är en tredje typ av läsare. Och de är förvånansvärt bra på att rekonstruera de implicita teorier som är inbäddade i kod.

ServiceMatch-systemet ger övertygande bevis. Deras CMDB-plattform kodar företagskonfigurationskunskap som skulle fylla volymer om det skrevs som prosa. Men här är grejen — det är redan skrivet, bara inte i prosa. Det är i kod.

Tänk på deras identitetsmatchningslogik. Istället för en konsults essä om "hur device identity fungerar" har de en konfigurationsfil med vikter: serienummer (25), hostname (25), asset tag (25), IP-adress (20), MAC-adress (15). Plus konfidens-trösklar och konfliktlösningsregler. Varje siffra representerar ett argument någon vann. Varje konflikttyp representerar ett verkligt incident som hände någonstans.

Det här är inte en beskrivning av policyn. Det ÄR policyn, som körs varje natt mot verkliga företagsmiljöer.

Vad detta betyder för ditt team

För utvecklare och tekniska ledare har denna forskning praktiska implikationer:

Din kod är dokumentation du inte har underhållit — och det har sina egna fördelar. Till skillnad från föråldrade wiki-sidor valideras kod som körs i produktion ständigt. Om dokumentationen är oense med koden, är dokumentationen fel.

AI-verktyg blir bättre på att extrahera denna kunskap. Vi rör oss mot en värld där man kan fråga en AI om "hur vi hanterar device identity-konflikter" och få tillbaka inte bara dokumentation, utan den faktiska resonemangen inkodade i vikterna och trösklarna.

Den verkliga kunskapen lever i edge cases. Huvudflödena är oftast väl dokumenterade. Det är specialhanteringen, undantagen, corner cases som löstes över år som innehåller den djupa institutionella kunskapen.

Varningssignalen

Det finns en obekväm korrolär till allt detta: om din affärslogik bara finns i din kod, och din kod har dålig testtäckning, otydliga namn eller kaotisk struktur, sitter du på en hög av kunskap som är nästan omöjlig att extrahera.

ServiceMatch-teamet fann att deras påstående — att "repositoryt räcker" — brister på förutsägbara sätt. Naurs tysta rester är verkliga. viss kunskap lever verkligen bara i människors huvuden.

Men det starkare fyndet är att mer överlever i kod än vi trodde var möjligt. Repositoryt fångar betydligt mer teori än dokumentation någonsin kunde — vi behövde bara en ny typ av läsare för att extrahera den.

Vad du ska göra med detta

Om du är ett startup eller växande teknikföretag, här är ett ramverk för att tänka på detta:

1. Lita mer på din kod än dina dokument när de två inte är överens
2. Skriv kod som dokumenterar sin egen resonemang — meningsfulla variabelnamn, tydliga funktioner, kommentarer som förklarar VARFÖR, inte bara VAD
3. Behandla konfiguration som institutionell kunskap — de vikterna och trösklarna är beslut värda att bevara
4. Börja utforska AI-verktyg som kan fråga din kodbas som kunskapskälla

Koden du skriver idag är morgondagens institutionella kunskap. Se till att den räknas.

Har du reflekterat över vilken kunskap som bara finns i din kod?