Virksomhedernes mest oversete vidensbank

Her er noget, der burde få enhver CTO og lead developer til at føle sig utilpas: Den mest sofistikerede forståelse af din forretning lever måske ingen andre steder end i produktionskoden.

En ny forskningsartikel fra teamet hos ServiceMatch udforsker en provokerende idé. De argumenterer for, at modne software-systemer ikke bare er værktøjer, der kører din forretning — de er eksekverbare repræsentationer af alt, din organisation har lært om den forretning. Det tricky ved det? Den viden har gemt sig i fuld offentlighed, låst inde i repositories, som kun blev læst af compilere og (lejlighedsvis) mennesker.

Dokumentationsmyten

Vi har alle været der. En ny udvikler starter, og hun får overrakt en mur af Confluence-sider, arkitekturbeslutninger og Wiki-opførsler. "Det her får dig up to speed," siger nogen med optimistisk sikkerhed.

Det gør det ikke.

Dokumentation fanger det, nogen syntes var værd at skrive ned, på et tidspunkt der kan være år siden. Den misser edge cases. Den misser de diskussioner, der skete i møder og formede beslutninger. Den misser den forretningslogik, der udviklede sig gennem tusindvis af commits, hvor hver eneste kæmpede med et virkeligt scenarie.

Ifølge Peter Naur's argument fra 1985 — ja, den samme Naur der gav os Backus-Naur form — kan programdokumentation aldrig fuldt ud fange "teorien" bag et system. Den egentlige forståelse lever i folks hoveder. Når de mennesker forlader virksomheden, forlader teorien med dem.

Men her bliver det interessant.

AI ændrer læserproblemet

Naur's argument handlede om to typer læsere: compilere (som eksekverer kode uden at forstå den) og mennesker (som forstår den langsomt og dyrt). Umuligheden af dokumentationsgenopladning antog, at der ikke eksisterede nogen anden type læser.

Large language models er en tredje type læser. Og de er overraskende gode til at rekonstruere de implicitte teorier, der er indlejret i kode.

ServiceMatch-systemet leverer overbevisende beviser. Deres CMDB-platform koder virksomhedskonfigurationsviden, der ville fylde bind, hvis den var skrevet som prosa. Men her er pointen — det er allerede skrevet, bare ikke i prosa. Det er i kode.

Tag deres identity resolution-logik. I stedet for en konsulents essay om "hvordan device identity virker," har de en konfigurationsfil med vægte: serienummer (25), hostname (25), asset tag (25), IP-adresse (20), MAC-adresse (15). Plus confidence thresholds og conflict resolution-regler. Hvert eneste tal repræsenterer en diskussion, nogen vandt. Hver conflict-type repræsenterer en reel hændelse, der skete et sted.

Dette er ikke en beskrivelse af policyen. Dette ER policyen, der kører hver nat mod faktiske virksomhedsmiljøer.

Hvad dette betyder for dit team

For udviklere og tekniske ledere har denne forskning praktiske implikationer:

Din kode er dokumentation, du ikke har vedligeholdt — og det har sine egne fordele. I modsætning til forældede wiki-sider bliver kode, der kører i produktion, konstant valideret. Hvis dokumentationen er uenig med koden, er dokumentationen forkert.

AI-værktøjer bliver bedre til at udtrække denne viden. Vi bevæger os mod en verden, hvor man kan spørge en AI om "hvordan vi håndterer device identity-konflikter" og få returneret ikke bare dokumentation, men den faktiske ræsonnement indkodet i vægte og thresholds.

Den rigtige viden lever i edge cases. Hovedforløbene er som regel godt dokumenteret. Det er specialhåndteringen, undtagelserne, hjørnetilfældene løst over år, der indeholder den dybe institutionelle viden.

Advarselsskiltet

Der er en ubehagelig korrelation til alt dette: hvis din forretningslogik kun er i din kode, og din kode har dårlig testdækning, uklare navne eller kaotisk struktur, sidder du på en bunke viden, der er næsten umulig at udtrække.

ServiceMatch-teamet fandt, at deres påstand — at "repository'et er tilstrækkeligt" — bryder sammen på forudsigelige måder. Naur's tause residue er reel. Noget viden lever virkelig kun i folks hoveder.

Men det stærkere fund er, at mere overlever i kode, end vi troede muligt. Repository'et fanger langt mere teori end dokumentation nogensinde kunne — vi havde bare brug for en ny type læser til at udtrække den.

Hvad du skal stille op med dette

Hvis du er en startup eller voksende teknologivirksomhed, er her et framework til at tænke over dette:

1. Stol mere på din kode end dine docs når de to er uenige
2. Skriv kode, der dokumenterer sin ræsonnement — meningsfulde variabelnavne, klare funktioner, kommentarer der forklarer HVORFOR, ikke bare HVAD
3. Behandl konfiguration som institutionel viden — de vægte og thresholds er beslutninger værd at bevare
4. Begynd at udforske AI-værktøjer der kan udspørge dit codebase som en videnskilde

Koden du skriver i dag er morgendagens institutionelle viden. Gør den værd at bevare.