Hauptgedanke

Ein Produktartefakt zu aktualisieren hieß immer, seine vorherige Fassung zu korrigieren: Man öffnet die vor achtzehn Monaten geschriebene Spezifikation, sucht die Absätze, die von der letzten Lieferung betroffen sind, und schreibt sie neu. Das Dokument erbt dann alles, was nicht noch einmal gelesen wurde — inzwischen entfernte Verhaltensweisen, Bildschirme, die es nicht mehr gibt, Annahmen, die die Entwicklung widerlegt hat.

Der andere Weg besteht darin, die vorherige Fassung wegzuwerfen und das Artefakt aus dem Repository neu zu erzeugen: die Support-Dokumentation nach einer Lieferung, den Changelog, die funktionale Spezifikation des aktuellen Stands. Das Dokument trägt dann nicht mehr die Ablagerungen seiner Fassungen, sondern das Datum, an dem der Code gelesen wurde.

Der Gewinn ist nicht die Schreibgeschwindigkeit. Er besteht darin, dass das Artefakt kein Bestand mehr ist, den man pflegen muss, sondern eine Projektion, die man neu anstößt. Eine Projektion driftet nicht ab: Entweder ist sie veraltet, oder sie wird neu erstellt.

Die Regel gilt auch innerhalb ein und desselben Dokuments, sobald es zwei Arten von Material mischt. In einem Steckbrief zu einem Produktobjekt beschreibt der Hauptteil die Wirklichkeit, wie sie im Code steht: Er lässt sich wegwerfen und neu erstellen, ohne dass etwas verloren geht. Die Abweichungen zwischen dieser Wirklichkeit und dem, was man sich wünschen würde, gehen dagegen auf eine menschliche Entscheidung zurück, finden sich nirgends wieder, wenn sie verloren gehen, und gehören deshalb in einen eigenen Block, den keine Neuerzeugung berührt. Was neu erzeugt und was gepflegt wird, kann nur nebeneinander bestehen, wenn beides sichtbar getrennt ist.

Ebene beigetragen von „Ich habe die Ontologie eines Produkts geschrieben. Dreimal dachte ich, ich wäre fertig.“ (2026-08-11).

Ebene beigetragen von „Vier Tage vibe coding als eingerosteter PM“ (2026-07-28). Die Umkehrung betrifft nicht nur die Aktualisierung eines bestehenden Dokuments: Sie betrifft auch den Moment, in dem das erste Dokument geschrieben wird. Bei einem internen Werkzeug, das direkt von jemandem aus dem Produktbereich gebaut wurde, gab es keine vorherige Spezifikation — die Person hat angefangen, gebaut, gezeigt, Änderungswünsche bekommen und iteriert. Das Verhalten ist im Produkt entstanden, und die fachliche Dokumentation wurde danach aus dem Code erzeugt. Die übliche Reihenfolge kehrt sich dann vollständig um: Man erzeugt ein Dokument nicht neu, weil man es nicht pflegen konnte, sondern man erzeugt es, weil es vorher nie geschrieben wurde.

Warum das wichtig ist

Das macht die Abweichung zwischen Produkt und Dokumentation ohne Disziplin beherrschbar. Solange man aktualisiert, sammelt sich die Abweichung mit jeder ausgelassenen Iteration an; sobald man neu erzeugt, hinterlässt eine ausgelassene Iteration keine Schuld — die nächste Neuerzeugung setzt am selben Punkt an.

Es verändert auch, was man archiviert: Es wird nützlicher, die Fähigkeit zur Neuerzeugung zu bewahren als die zuletzt erzeugte Fassung.

Nuancen und Grenzen

Der Code enthält nicht die Absicht. Eine neu erzeugte Spezifikation sagt, was das Produkt tut, nicht, warum dieses Verhalten gewählt und was verworfen wurde — und dieser Verlust ist unsichtbar, weil das Dokument vollständig wirkt.

Auch die Neuerzeugung ist nicht umsonst: Sie verlangt eine Durchsicht, und ein falsches Ergebnis, das richtig aussieht, kostet mehr als ein offensichtlich veraltetes Dokument.

Offene Fragen

• Wie bemerkt man, dass eine Neuerzeugung eine menschliche Entscheidung gelöscht hat, wenn sie ein tadellos geformtes Dokument liefert?