Hauptgedanke

Um ein Softwareprodukt kreist eine ganze Familie von Artefakten: die Spezifikation, das Figma-Mockup, der Changelog, die Support-Dokumentation, die Vertriebsdokumentation. Keines davon sagt, was das Produkt heute tut. Sie sagen, was es tun sollte, oder was es in dem Moment tat, als jemand sie geschrieben hat.

Der Code dagegen kann sich über den Zustand des Produkts nicht irren: Er ist dieser Zustand. Ein Verhalten, das im Repository steht, ist ein Verhalten des Produkts, ob es spezifiziert wurde oder nicht; ein Verhalten, das in einer Spezifikation steht und im Repository fehlt, existiert für niemanden.

Das macht den Code weder zu einem guten Lesemedium noch zu einem Ersatz für die anderen Artefakte. Es legt nur eine Rangfolge der Verlässlichkeit fest: Widersprechen sich Repository und Dokument, hat das Dokument unrecht.

Dieselbe Rangfolge gilt für die Artefakte der Koordination: Ein Ticket und eine Spezifikation geraten schon während der Umsetzung aus dem Takt, miteinander und mit dem Produkt, und die einzige dauerhafte Realität bleibt das, was geliefert wird — der Code, das beobachtbare Verhalten und die Dokumentation, die von ihnen aus gepflegt wird.

Ebene beigetragen von „Das Backlog ist kein Mülleimer: Es ist ein Werkzeug zum Handeln“ (2026-06-03).

Über den Zustand des Produkts maßgeblich zu sein heißt nicht, ihn zu beschreiben. Der Code legt fest, wie das Produkt funktioniert — die Felder, die möglichen Werte, die Verarbeitungsschritte — und lässt draußen, was es nutzbar macht: die Regel in einem Satz, wenn ihre Prüfung über fünf Dateien verstreut ist; die Sonderfälle eines Objekts; die Wörter, die die Nutzer verwenden; die Reichweite eines Begriffs, wenn zwei Anwendungen hinter demselben Wort einen anderen Sinn sehen. Diese vier Informationen liegen übrigens nicht am selben Ort: Sie verteilen sich auf den Kern des Codes, die Datenbank, die Oberflächen und die Übersetzungen. Die Rangfolge der Verlässlichkeit bleibt richtig; sie entbindet nicht davon, den Sinn darüber aufzuschreiben.

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

Die Rangfolge bestätigt sich auch dort, wo sie auf die Spitze getrieben wird. Bei einem internen Werkzeug, das ohne vorherige Spezifikation entstanden ist — jemand legt los, baut, zeigt, bekommt Wünsche, passt an —, hat nie ein Dokument die Absicht beschrieben, und das Produkt funktioniert trotzdem. Das Umgekehrte gibt es nicht: Kein Produkt funktioniert ohne Code. Die Spezifikation verschwindet deshalb nicht aus allen Zusammenhängen, aber sie kann nicht mehr beanspruchen, dauerhaft die Wahrheit über das Produkt zu sein.

Ebene beigetragen von „Vier Tage vibe coding als eingerosteter PM“ (2026-07-28).

Warum das wichtig ist

Diese Rangfolge wird selten ausgesprochen, obwohl sie ständig angewendet wird: Ein Entwickler, der ein mehrdeutiges Verhalten klären muss, liest den Code, nicht die Spezifikation. Sie ausdrücklich zu benennen verändert, was man von den anderen Artefakten erwartet — sie werden zu datierten Ansichten, nicht zu Referenzen.

Sie liefert auch ein Kriterium, um einen Konflikt zwischen zwei Artefakten zu entscheiden, ohne ihre Autoren zusammenzurufen: Man sucht nicht, wer recht hat, man schaut ins Repository.

Nuancen und Grenzen

Der Code sagt, was das Produkt tut, nie warum. Die Absicht, die Abwägung, die kommerzielle Einschränkung, die zu diesem Verhalten geführt hat, lassen sich darin nicht ablesen — dieser Teil bleibt in den Dokumenten und in den Projektgesprächen.

Die Regel gilt für das gelieferte Verhalten, nicht für das gewollte: Ein Bug steht im Code und gehört trotzdem zu dem, was geändert werden muss.

Offene Fragen

• Wer bemerkt, dass eine Produktabsicht verloren gegangen ist, wenn das Verhalten, das sie hervorgebracht hat, ohne sie weiterläuft?