Dokumentation ist Teil des Produkts

Viele Teams sprechen noch immer über Dokumentation, als beginne sie erst nach der eigentlichen Arbeit. Zuerst wird das Produkt gebaut, danach schreibt jemand auf, was passiert ist. Dieses Modell war schon vor KI-gestützter Entwicklung schwach. Mit KI wird es zu einem echten Risiko.

Wenn Code, Text, Oberflächen und Arbeitsabläufe sehr schnell erzeugt werden können, ist Dokumentation nicht mehr nur eine nachträgliche Schicht. Sie wird Teil des Mechanismus, der das Produkt kohärent hält.

Warum das heute noch wichtiger ist

KI kann Implementierung aus unvollständiger Absicht erzeugen. Das wird oft als Bequemlichkeit dargestellt. In der Praxis bedeutet es, dass jede Unklarheit im Projekt zu einem Ort wird, an dem das Produkt abdriften kann.

Wenn die Dokumentation schwach oder veraltet ist, werden verschiedene Menschen und verschiedene Werkzeuge aus demselben Repository verschiedene Produkte ableiten.

Ein Mitwirkender kann der aktuellen Benutzeroberfläche folgen. Ein anderer kann einer alten README-Datei folgen. Ein KI-Assistent kann der nächstgelegenen Datei folgen und den Rest erfinden.

Das Problem ist nicht nur Korrektheit auf Code-Ebene. Das Problem ist, ob das Projekt noch immer ein Produkt beschreibt statt mehrerer sich überlagernder Vermutungen.

Dokumentation erfüllt vier Produktaufgaben

Gute Dokumentation tut weit mehr, als die Oberfläche nachträglich zu erklären.

Erstens trägt sie Absicht. Sie sagt zukünftigen Mitwirkenden, was das Produkt erreichen will und was es ausdrücklich nicht werden will.

Zweitens setzt sie Erwartungen. Lesende können erkennen, was jetzt existiert, was geplant ist und was nicht so beschrieben werden sollte, als wäre es bereits implementiert.

Drittens senkt sie Koordinationskosten. Neue Mitwirkende, Reviewer, Institutionen und KI-Assistenten können sich alle orientieren, ohne das Projekt aus Fragmenten rekonstruieren zu müssen.

Viertens stützt sie Vertrauen. Ein Projekt, das aktuellen Zustand, geplante Richtung und experimentellen Workflow klar trennt, ist leichter zu bewerten und leichter zu pflegen.

Let Books ist bereits so aufgebaut

Das Let-Books-Repository zeigt diesen mehrschichtigen Ansatz bereits.

• AGENTS.md definiert Produktzweck, Workflows, Domänengrenzen und langfristige Richtung.
• AGENTS-Implementation.md definiert taktische Regeln für Implementierung und Dokumentation.
• README.md erklärt den aktuellen Zustand des Repositories und unterscheidet gegenwärtige Liefergegenstände von zukünftigen Plänen.
• docs/ definiert eine Wissensplattform mit Konventionen für Veröffentlichung, Schreiben, Lokalisierung und Quellenabbildung.

Das bedeutet: Dokumentation ist hier nicht nur Erklärung. Sie ist Teil der Arbeitsweise des Projekts.

Veraltete Dokumentation ist Produktschuld

Teams erkennen technische Schulden oft erst, wenn sie im Code auftauchen. Veraltete Dokumentation erzeugt aber eine ähnliche Art von Reibung.

Veraltete Dokumentation führt zu:

• falschen Implementierungsannahmen
• Wiederholung bereits getroffener Entscheidungen
• Demos, die versehentlich zur Produktwahrheit werden
• langsamerer Einarbeitung neuer Mitwirkender
• schwierigeren Reviews, weil der Standard unklar ist

In KI-gestützten Abläufen wächst diese Schuld noch schneller, weil Assistenten sehr gut von nahegelegenen, selbst veralteten Annahmen fortsetzen.

Dokumentation und Implementierung müssen eine Kette bilden

Das richtige Modell ist keine starre Reihenfolge „erst Dokumentation, dann Code“. Das richtige Modell ist eine gepflegte Kette:

• Spezifikationen definieren Absicht
• Dokumente zum aktuellen Zustand erklären, was jetzt existiert
• Demo und Implementierung machen den Ablauf konkret
• Tests und Validierung prüfen Erwartungen
• CI hält Drift sichtbar

Wenn sich ein Glied ändert, sollten auch die benachbarten überprüft werden.

Warum sich auch ein breiteres Publikum dafür interessieren sollte

Das ist nicht nur ein technisches Thema.

Institutionen sollten sich dafür interessieren, weil Dokumentation Governance, Vertrauen in Beschaffung, Onboarding, Kontinuität und Auditierbarkeit beeinflusst.

Studierende sollten sich dafür interessieren, weil das Dokumentieren von Absicht Teil des Lernens ist, wie man verlässliche Systeme baut, und kein administratives Extra.

Allgemeine Leserinnen und Leser sollten sich dafür interessieren, weil ein Produkt mit klarer Dokumentation meist auch ein Produkt mit klareren Entscheidungen im Hintergrund ist.

Der praktische Test

Eine hilfreiche Frage für jedes Team ist einfach:

Wenn heute ein neuer Mitwirkender oder ein KI-Assistent ins Repository käme, würden die Dokumente ihm helfen, das beabsichtigte Produkt zu bauen, oder vor allem etwas, das nur plausibel wirkt?

Dieser Unterschied ist der Unterschied zwischen Dokumentation als Kommentar und Dokumentation als Teil des Produkts.

Die dauerhafte Lehre

Dokumentation ist nicht von Produktqualität getrennt.

Sie prägt Implementierung, Review, Kommunikation, Validierung und langfristiges Vertrauen. In KI-gestützten Projekten ist Dokumentation Teil des Produkts, weil sie Teil des Systems ist, das Produktdrift verhindert.

Weiterführende Seiten

• ../../wiki/documentation-traceability.md
• ../../wiki/validation-layers.md
• ai-as-an-oracle.md
• spec-driven-development-in-let-books.md