Warum dein Code wertvoller ist als deine Dokumentation

Hier ist etwas, das jeden CTO und Lead Developer unbehaglich stimmen sollte: Das tiefste Verständnis für dein Geschäft könnte nirgendwo anders existieren als in deinem Produktivcode.

Ein kürzlich veröffentlichter Forschungsartikel des Teams von ServiceMatch untersucht eine gewagte These. Sie argumentieren, dass reife Software-Systeme nicht nur Werkzeuge sind, die dein Geschäft betreiben – sie sind ausführbare Repräsentationen von allem, was eine Organisation über dieses Geschäft gelernt hat. Das Problem dabei? Dieses Wissen war die ganze Zeit da, versteckt in Repositories, die bisher nur von Compilern und (gelegentlich) Menschen gelesen wurden.

Der Mythos der Dokumentation

Wir kennen das alle. Ein neuer Entwickler kommt ins Team und bekommt einen Stapel Confluence-Seiten, Architecture Decision Records und Wiki-Einträge in die Hand gedrückt. „Damit bist du schnell auf dem neuesten Stand", sagt jemand mit optimistischer Überzeugung.

Wird er nicht.

Dokumentation fängt ein, was jemand für wert hielt, aufzuschreiben – zu einem Zeitpunkt, der vielleicht Jahre zurückliegt. Sie verpasst die Edge Cases. Sie verpasst die Diskussionen, die in Meetings stattfanden und Entscheidungen geprägt haben. Sie verpasst die Geschäftslogik, die sich durch Tausende von Commits entwickelt hat, jeder einzelne davon ein Ringen mit einem realen Szenario.

Gemäß Peter Naur's Argumentation von 1985 (ja, derselbe Naur, der uns Backus-Naur-Form gegeben hat) kann Programmdokumentation die „Theorie" hinter einem System niemals vollständig erfassen. Das eigentliche Verständnis lebt in den Köpfen der Menschen. Wenn diese Menschen gehen, geht das Wissen mit ihnen.

Aber hier wird es interessant.

KI verändert das Leser-Problem

Naur's Argumentation drehte sich um zwei Typen von Lesern: Compiler (die Code ausführen, ohne ihn zu verstehen) und Menschen (die ihn langsam und teuer verstehen). Die Unmöglichkeit der Dokumentations-Wiederbelebung nahm an, dass keine andere Art von Leser existierte.

Large Language Models sind ein dritter Leser-Typ. Und sie sind überraschend gut darin, die impliziten Theorien zu rekonstruieren, die im Code eingebettet sind.

Das ServiceMatch-System liefert überzeugende Belege dafür. Ihre CMDB-Plattform kodiert Enterprise-Konfigurationsmanagement-Wissen, das Bände füllen würde, wenn es als Fließtext geschrieben wäre. Aber hier ist der Clou – es ist bereits geschrieben, nur eben nicht als Fließtext. Es ist im Code.

Betrachten wir ihre Identity-Resolution-Logik. Statt eines Berateraufsatzes über „wie Geräte-Identität funktioniert" haben sie eine Konfigurationsdatei mit Gewichtungen: Seriennummer (25), Hostname (25), Asset-Tag (25), IP-Adresse (20), MAC-Adresse (15). Plus Confidence-Thresholds und Konfliktauflösungsregeln. Jede Zahl repräsentiert ein Argument, das jemand gewonnen hat. Jeder Konflikttyp repräsentiert einen echten Incident, der irgendwo passiert ist.

Das ist keine Beschreibung der Richtlinie. Das IST die Richtlinie, die nächtlich gegen echte Enterprise-Umgebungen läuft.

Was das für dein Team bedeutet

Für Entwickler und technische Führungskräfte hat diese Forschung praktische Implikationen:

Dein Code ist Dokumentation, die du nicht gepflegt hast – und das hat sogar Vorteile. Im Gegensatz zu veralteten Wiki-Seiten wird Code, der in Produktion läuft, ständig validiert. Wenn die Dokumentation dem Code widerspricht, liegt die Dokumentation falsch.

KI-Tools werden immer besser darin, dieses Wissen zu extrahieren. Wir bewegen uns auf eine Welt zu, in der die Frage „wie lösen wir Geräte-Identitätskonflikte" nicht nur Dokumentation liefern könnte, sondern die tatsächliche Begründung, die in den Gewichtungen und Schwellenwerten kodiert ist.

Das echte Wissen steckt in den Edge Cases. Die Hauptflüsse sind meist gut dokumentiert. Es sind die Sonderbehandlungen, die Ausnahmen, dieCorner Cases, die über Jahre gelöst wurden, die das tiefe institutionelle Wissen enthalten.

Das Warnsignal

Es gibt eine unbequeme Schlussfolgerung aus dem Ganzen: Wenn deine Geschäftslogik nur in deinem Code steckt und dein Code schlechte Testabdeckung, unklare Benennung oder chaotische Struktur hat, sitzt du auf einem Haufen Wissen, der kaum extrahierbar ist.

Das ServiceMatch-Team fand heraus, dass ihre Behauptung – „das Repository genügt" – auf vorhersehbare Weise zusammenbricht. Naur's tacitness Residue ist real. Einiges Wissen lebt tatsächlich nur in den Köpfen der Menschen.

Aber die stärkere Erkenntnis ist, dass mehr im Code überlebt, als wir für möglich hielten. Das Repository erfasst viel mehr Theorie als Dokumentation jemals könnte – wir brauchten nur einen neuen Lesertyp, um es zu extrahieren.

Was du damit anfangen solltest

Wenn du ein Startup oder ein wachsendes Tech-Unternehmen bist, hier ein Framework, um darüber nachzudenken:

1. Vertraue deinem Code mehr als deinen Docs, wenn die beiden nicht übereinstimmen
2. Schreibe Code, der seine Begründung dokumentiert – aussagekräftige Variablennamen, klare Funktionen, Kommentare, die das WARUM erklären, nicht nur das WAS
3. Behandle Konfiguration als institutionelles Wissen – diese Gewichtungen und Schwellenwerte sind Entscheidungen, die es wert sind, bewahrt zu werden
4. Beginne damit, KI-Tools zu erkunden, die deine Codebasis als Wissensquelle befragen können

Der Code, den du heute schreibst, ist morgen das institutionelle Wissen. Mach ihn wertvoll.