Spec-Driven Development ist gerade ein beliebter Begriff. Alle verwenden ihn, und alle meinen etwas leicht anderes. Birgitta Böckeler von Thoughtworks hat auf martinfowler.com einen hilfreichen Artikel geschrieben, in dem sie Tools untersucht, die sich als spec-driven bezeichnen. Ihre wichtigste Erkenntnis: Spec-Driven Development ist nicht eine Sache. Es gibt drei Stufen.

In diesem Beitrag erkläre ich die drei Stufen in einfachen Worten, ordne einige bekannte Tools ein und beantworte dann eine Frage, die ich oft höre: Wo steht der AI Unified Process?

Stufe 1: Spec-first

Du schreibst eine Spezifikation, bevor du Code schreibst. Die Spezifikation ist der Input für den KI Coding Agent. Wenn das Feature fertig ist, wird die Spezifikation nicht mehr gebraucht. Für die nächste Änderung schreibst du eine neue.

Spec-first ist schon viel besser, als einen Prompt zu schreiben und auf das Beste zu hoffen. Aber die Spezifikation ist ein Wegwerfartefakt. Sechs Monate später weiss niemand mehr, warum der Code so aussieht, wie er aussieht.

Stufe 2: Spec-anchored

Die Spezifikation bleibt nach dem Feature im Repository. Wenn sich das Feature ändert, aktualisierst du Spezifikation und Code zusammen. Die Spezifikation ist die langfristige Referenz für Menschen und für die KI.

Auf dieser Stufe wird die Spezifikation zur Dokumentation, die tatsächlich stimmt, weil der Agent sie vor jeder Änderung liest. Es ist auch die Stufe, auf der Brownfield-Systeme möglich werden. Du kannst Spezifikationen für ein bestehendes System schreiben und alle zukünftigen Änderungen daran verankern.

Stufe 3: Spec-as-source

Die Spezifikation ist das Einzige, was ein Mensch bearbeitet. Der Code wird aus der Spezifikation generiert. Menschen fassen den Code nie an.

Das ist die radikalste Idee. Sie ist auch die am wenigsten bewiesene. Böckeler vergleicht sie mit Model-Driven Development von vor zwanzig Jahren. Damals haben wir Modelle in UML oder einer DSL geschrieben und mit eigenen Generatoren Code erzeugt. Für Geschäftsanwendungen hat sich das nie durchgesetzt. Die Abstraktionsebene war unhandlich, und die Einschränkungen waren zu streng. Jetzt ersetzt das LLM den Generator. Das entfernt die Einschränkungen, aber es bringt Nichtdeterminismus. Generiere dieselbe Spezifikation zweimal, und du bekommst zwei verschiedene Implementierungen.

Wo stehen die Tools?

Kiro und spec-kit sind spec-first. Beide erzeugen pro Feature eine Spezifikation, ein Design und eine Aufgabenliste. spec-kit erstellt sogar pro Spezifikation einen neuen Git-Branch. Das zeigt, dass die Spezifikation so lange lebt wie der Änderungsauftrag, nicht so lange wie das Feature.

BMad ist eine Methode mit Agent-Rollen. Ein Analyst schreibt ein Briefing, ein Product Manager ein PRD, ein Architekt ein Architekturdokument, und ein Scrum Master schneidet Stories, die ein Developer-Agent umsetzt. PRD und Architekturdokument bleiben im Repository, es gibt also eine dauerhafte Planungsebene. Aber die Arbeitseinheit ist die Story, und eine Story wird verbraucht und ist dann erledigt. In der Praxis ist BMad ein Spec-first-Workflow mit guten Planungsdokumenten obendrauf.

OpenSpec ist spec-anchored, und es ist ehrlich damit. Es gibt zwei Bereiche: einen specs-Ordner, der das aktuelle Verhalten des Systems beschreibt, und einen changes-Ordner, in dem jede Änderung ein eigenständiges Paket mit Proposal, Design, Aufgaben und Delta-Spezifikationen ist. Wenn die Änderung fertig ist, archivierst du sie, und das Delta wird in die Hauptspezifikationen gemergt. Das ist die richtige Idee für Brownfield-Arbeit: Beschreibe den Unterschied, nicht die ganze Welt.

Wo steht der AI Unified Process?

Ebenfalls auf Stufe 2: spec-anchored.

Im AI Unified Process sind der Anforderungskatalog, das Use-Case-Diagramm, die Use-Case-Spezifikationen und das Entitätsmodell keine Wegwerf-Prompts. Sie leben im Repository, neben dem Code, während der ganzen Lebensdauer des Systems. Wenn sich ein Use Case ändert, änderst du zuerst die Spezifikation. Dann ändert der Agent den Code. Die Tests sind über die Annotation @UseCase mit den Use Cases verknüpft, sodass du von der Spezifikation zum Test zum Code und zurück navigieren kannst.

Der Unterschied zu OpenSpec liegt nicht in der Stufe, sondern im Inhalt. OpenSpec gibt dir eine leichtgewichtige Struktur für Anforderungen und Szenarien. Der AI Unified Process bringt die Disziplin des Requirements Engineering mit: Akteure, Use Cases mit Haupt- und Alternativabläufen, Geschäftsregeln, ein Entitätsmodell und Nachvollziehbarkeit von der Anforderung bis zum Test. Das kennen Enterprise-Teams schon von RUP und Use-Case, jetzt angepasst für KI Agents.

Und es funktioniert mit Brownfield-Systemen. Die meiste Arbeit im Enterprise ist nicht Greenfield. Du kannst Use Cases und ein Entitätsmodell aus einem bestehenden System per Reverse Engineering ableiten, und ab diesem Moment ist jede Änderung an einer Spezifikation verankert.

Aber du schreibst doch gar keinen Code mehr. Ist das nicht Stufe 3?

Diese Frage höre ich oft, weil ich in der Praxis kaum noch selbst Code tippe. Das macht der Agent. Ist das also Stufe 3?

Nein, und zwar mit Absicht. Stufe 3 bedeutet nicht nur „der Mensch tippt keinen Code“. Sie hat drei Teile:

  1. Menschen bearbeiten den Code nie.
  2. Der Code wird aus der Spezifikation neu generiert. Spezifikation ändern, Build starten, neuen Code bekommen.
  3. Die Spezifikation bildet eins zu eins auf Code-Dateien ab.

Der AI Unified Process erfüllt in der Praxis den ersten Teil. Die anderen beiden erfüllt er nicht, und das soll er auch nicht:

Der Code wird nicht neu generiert. Der Agent entwickelt ihn weiter. Der bestehende Code ist Input für die nächste Änderung, nicht Output eines Builds. Nur so funktioniert Brownfield. Niemand generiert ein fünfzehn Jahre altes ERP aus einer Spezifikation neu.

Die Spezifikationen sind auf Use-Case-Ebene, nicht auf Dateiebene. Ein Use Case bildet auf Views, Services, Queries, Migrationen und Tests ab. Das ist die Abstraktionsebene, auf der Fachleute und Entwickler miteinander reden können. Eine Spezifikation pro Datei ist eine Spezifikation nur für Entwickler.

Der Code bleibt ein vollwertiges Artefakt. Du reviewst ihn. Du kannst ihn lesen. Du kannst ihn ändern, wenn du willst, und das solltest du auch, wenn es schneller geht. Die Tests verknüpfen ihn mit den Use Cases. Niemand schreibt „nicht bearbeiten“ darüber.

Du bekommst den grössten Teil der Produktivität von Stufe 3, ohne von einem nichtdeterministischen Compiler abhängig zu sein. Und du behältst etwas, das Stufe 3 aufgibt: ein Team, das sein eigenes System versteht.

Fazit

Spec-first ist ein guter Anfang. Spec-anchored ist die Stufe, auf der langfristig der Wert entsteht. Spec-as-source ist ein interessantes Experiment, aber für Geschäftsanwendungen im Enterprise waren wir mit Model-Driven Development schon einmal dort, und die Lektion war nicht „einfach fester versuchen“.

Der AI Unified Process ist eine Spec-anchored-Methode. Die Spezifikationen sind die Wahrheit für die Anforderungen. Der Code ist die Wahrheit für die Implementierung. Beides wird behalten, beides ist verknüpft, und beides gehört dem Team.

Referenzen