Specs beschleunigen, was schon da ist: Spec-Driven Development und der Reifegrad

Für einen kleinen Bug hat Kiro vier User Stories mit sechzehn Akzeptanzkriterien geschrieben. Birgitta Böckeler von Thoughtworks hat im Herbst 2025 drei Werkzeuge für Spec-Driven Development getestet und ihre Beobachtungen am 15. Oktober auf martinfowler.com veröffentlicht. Ein Satz daraus:

„To be honest, I’d rather review code than all these markdown files.“

Code fällt durch, wenn er nicht läuft. Eine Spec fällt nie durch. Ihr Review kennt keinen Fehlerzustand.

Ein Jahr später ist aus der Idee ein Markt geworden. Das Repository von GitHub Spec Kit, im August 2025 angelegt, hatte am 14. Oktober 2026 141.263 Sterne. Kiro, die Entwicklungsumgebung von AWS, ist seit dem 17. November 2025 allgemein verfügbar und der Nachfolger von Amazon Q Developer, das seit Mai 2026 keine Neuanmeldungen mehr annimmt. Tessl hat laut Presseberichten 125 Millionen Dollar eingesammelt, um Software nur noch aus Specs zu erzeugen. Alle verkaufen dasselbe Versprechen: Wer die Absicht vorher aufschreibt, bekommt bessere Software.

Dieser Essay prüft das Versprechen. Das Ergebnis steht vorne:

Eine Spec macht Software nicht von selbst besser. Sie macht schneller und sichtbarer, was eine Organisation ohnehin kann.

Wo die Fachlichkeit geklärt ist und jemand für Verträge zuständig ist, richtet sie Menschen und Agenten auf dasselbe Problem aus und spart Abstimmung. Wo beides fehlt, automatisiert sie das Fehlen. Prüfen kann eine Spec nur dort, wo eine Maschine sie liest. Vor die Wahl des Werkzeugs gehört also die Frage, wie reif die Organisation ist, die es benutzen soll.

Das Ergebnis ist begründet, nicht gemessen. Was es widerlegen würde, steht am Ende von Kapitel 8.