Doku macht wieder Spaß
Seien wir ehrlich, was interne Dokumentation in den meisten Unternehmen angeht: Es gibt keine.
Nicht „veraltet“. Nicht „lückenhaft“. Es gibt sie nicht. In fünfundzwanzig Jahren in der Branche habe ich kaum eine Handvoll Teams erlebt, die ihre eigenen Services korrekt und gepflegt dokumentiert hatten. Es läuft immer gleich. Beim ersten Aufbau schreibt jemand eine Wiki-Seite. Achtzehn Monate lang entwickelt sich das System weiter. Die Wiki-Seite friert ein, bis alle sie stillschweigend ignorieren. Die wenigen vorhandenen Seiten sind schlimmer als nichts. Sie beschreiben ein System, das es so nicht mehr gibt. Und das ist gefährlicher als gar keine Beschreibung.
Das war nie eine Frage der Disziplin. Es war eine Frage der Wirtschaftlichkeit. Und die hat sich gerade umgekehrt.
Die alte Ausrede ist tot
Dass Dokumentation wichtig ist, fanden immer alle. Bezahlt hat sie nie jemand.
Kein Unternehmen, für das ich gearbeitet habe, hat technische Redakteure für interne Systeme eingestellt. Die Rolle gab es allenfalls für öffentliche API-Dokumentation. Und auch das nur in großen Firmen. Für interne Services galt Doku als „Aufgabe der Entwickler“. Das betraf das Payment-Gateway ebenso wie die Benachrichtigungs-Pipeline oder die Authentifizierung, an der drei Teams hingen. Also war sie Aufgabe von niemandem. Die Entwickler mussten ihren Sprint liefern. Doku stand nie in den Akzeptanzkriterien.
Wer einen Nachmittag lang die Retry-Logik eines Service dokumentiert, hat an diesem Nachmittag kein Feature geliefert. Das Management wollte Features. Die Doku hat jedes Mal verloren.
Die Werkzeugfalle
Manche Teams wollten den Schmerz wegautomatisieren. Werkzeuge wie Structurizr versprachen Architecture as Code: das System in einer DSL beschreiben, die C4-Diagramme fallen automatisch heraus. Die Idee war gut. Man konzentriert sich auf die wertvollsten Artefakte und überlässt sie der Automatisierung.
In der Praxis war es ein Albtraum. Die erzeugten Diagramme waren generisch statt auf den einzelnen Service zugeschnitten. Ein schlichter CRUD-Service und eine komplexe, ereignisgetriebene Pipeline ergaben dieselbe Schablone. Am Ende kämpften die Entwickler mit dem Werkzeug. Sie lernten Syntax, suchten Fehler im Rendering und rangen mit dem Layout. Dabei wollten sie nur das Diagramm zeichnen, das sie brauchten.
Eine Mermaid-Skizze in zehn Minuten sagte mehr als alles, was das Werkzeug nach einer Stunde Konfiguration ausspuckte.
Die Lehre daraus ist nicht, dass Structurizr ein schlechtes Werkzeug wäre. Die Lehre ist: Der Dokumentation fehlten nie Generatoren. Gute Doku verlangt Verständnis. Was ist wichtig, was kann weg, worin unterscheidet sich dieser Service von jenem? Die Automatisierung vor der KI konnte Strukturen auslesen. Relevanz beurteilen konnte sie nicht.
KI verändert die Rechnung
KI kann das. Ein Agent, der gerade den Payment-Service umgebaut hat, beschreibt den neuen Ablauf in Minuten korrekt und strukturiert. Kein grober Entwurf, sondern eine echte Beschreibung: was der Code tut, wie die Komponenten zusammenspielen, wie es schiefgehen kann und wie man die API aufruft. Die Entwicklerin prüft das Ergebnis und committet. Nachschärfen muss sie nur dort, wo menschliches Urteil gefragt ist.
Interne Doku zu schreiben kostet heute eine Größenordnung weniger. Keine zu haben kostet so viel wie immer.
Wenn Doku Minuten statt Stunden braucht, zieht die Ausrede mit dem Backlog nicht mehr. Wenn ein Agent die Doku eines Service bei jeder Codeänderung nebenbei aktualisiert, veraltet sie nicht mehr.
Doku, die sich selbst pflegt
Der eigentliche Wandel: KI schreibt Doku nicht nur einmal. Sie hält sie aktuell.
Das Muster sieht so aus: Eine Entwicklerin ändert den Authentifizierungsablauf eines Service. Die CI-Pipeline merkt, dass die zugehörige Doku nicht mehr stimmt – oder gleich der Agent, der die Änderung umgesetzt hat. Er erzeugt eine aktualisierte Fassung, öffnet einen PR und legt den Diff einem Menschen zur Prüfung vor. Die Doku folgt dem Code, nicht umgekehrt.
Das ist keine Zukunftsmusik. Teams mit AI-nativen Abläufen behandeln Doku schon heute als Build-Artefakt. Derselbe Agent, der den Code schreibt, schreibt die Doku. Dasselbe Review, das schlechten Code findet, findet schlechte Doku. Dokumentation wird Teil der Definition of Done. Nicht als Häkchen auf einer Checkliste, sondern als automatischer Schritt in der Pipeline.
Doku, die sich selbst aktualisiert, ist kein Luxus. Sie ist die logische Folge, wenn Sie Doku nicht länger von der Entwicklung trennen.
Das eigentliche Problem war immer die Pflege. Erste Entwürfe sind lästig, aber machbar. Zwanzig Service-Dokus bei Hunderten Commits im Monat korrekt zu halten hat kein Team durchgehalten. Die KI schafft das mühelos.
Das Schwungrad des Kontexts
Jetzt wird es spannend. Was eine KI als Doku schreibt, liest eine KI als Kontext. Mit einem gut dokumentierten Service können Agenten verlässlich arbeiten.
Soll ein Agent etwas an den Payment-Service anbinden, liest er dessen Doku. Ist sie aktuell, strukturiert und korrekt, schreibt der Agent korrekten Integrationscode. Ist sie veraltet oder fehlt sie, halluziniert er. Er erfindet Endpunkte und rät Schemas. Heraus kommt Code, der kompiliert und zur Laufzeit scheitert.
So entsteht ein Schwungrad. Bessere interne Doku heißt bessere Ergebnisse der Agenten. Bessere Ergebnisse heißen schnellere Entwicklung. Schnellere Entwicklung heißt mehr Änderungen. Die dokumentiert die KI. Das hält die Doku aktuell und macht die nächste Runde des Agenten besser.
Interne Doku protokolliert nicht mehr nur, was gebaut wurde. Sie ist die Schnittstelle, über die Agenten das Bestehende verstehen und erweitern.
Teams, die gut dokumentieren, werden schneller besser. Nicht weil sie disziplinierter sind, sondern weil ihre Agenten besseren Kontext haben. Doku ist keine Bremse mehr, sondern ein Multiplikator.
Wie gute interne Doku heute aussieht
Die Form nützlicher interner Doku hat sich kaum verändert. Struktur schlägt Erzählung: klare Überschriften, ausdrückliche API-Verträge, Fehlerfälle und Abhängigkeiten. Ehrlich schlägt vollständig: Drei korrekte Absätze sind besser als dreißig veraltete Seiten. Verändert hat sich, wer sie schreibt und wie oft sie aktualisiert wird.
Die beste interne Doku liest sich wie ein Briefing für eine erfahrene Entwicklerin, die programmieren kann, aber Ihr System nicht kennt.
Genau das ist Kontext für Agenten. Context Engineering legt fest, welche Information das Modell wann und in welcher Struktur erreicht. Das ist dieselbe Disziplin wie gute interne Doku. Die Fähigkeiten sind zusammengewachsen. Wenn Doku einem Menschen nachts um zwei bei einem Vorfall hilft, hilft sie auch einem Agenten beim Integrationscode. Das eine schließt das andere nicht aus.
Doku ist nicht mehr das, wofür niemand Zeit hat. Sie ist das, wofür KI unbegrenzt Zeit hat. Und sie macht jede weitere Arbeit mit KI besser.
Die älteste lästige Pflicht der Softwareentwicklung ist zu einem Kreislauf geworden, der sich selbst trägt. Die KI schreibt die Doku. Die Doku füttert die KI. Mit jedem Commit wird das System klüger.
Doku macht wieder Spaß. Nicht weil jemand das Schreiben spannend gemacht hat, sondern weil es niemand mehr tun muss.
Sie wollen Doku-Pipelines, die Ihr internes Wissen aktuell und für Agenten lesbar halten? Sprechen wir darüber.