Eine Frage höre ich immer wieder zu Spec-Driven Development: Wo hört die Spezifikation auf und wo fängt die Implementierung an? Die Grenze ist oft unscharf. Specs rutschen in Klassennamen. Implementierungsentscheide schleichen sich in Use-Case-Beschreibungen. Nach ein paar Wochen weiss niemand mehr, was Absicht ist und was Zufall.

Der AI Unified Process (AIUP) zieht diese Grenze anders. Statt zwei Schichten (Spec und Code) arbeitet AIUP mit drei: Was, Harness und Wie. Die mittlere Schicht ist der eigentliche Hebel und macht AIUP anders als andere SDD-Ansätze.

Schauen wir uns die drei Schichten der Reihe nach an.

Das Was: Use Cases und Entity Model

Das Was ist der Problemraum. Es beschreibt das System, ohne etwas darüber zu sagen, wie das System gebaut wird.

Zwei Artefakte leben hier:

Use Cases beschreiben Verhalten. Sie folgen Ivar Jacobsons Use-Case 2.0 Denken: Ein Use Case ist ein Stück Nutzen, das ein Anwender vom System will. Ein Use Case hat ein Ziel, ein Hauptszenario, alternative Abläufe und Akzeptanzkriterien. Er ist in der Sprache der Fachdomäne geschrieben, nicht in der Sprache des Codes.

Das Entity Model beschreibt Struktur. Welche Geschäftsobjekte gibt es? Welche Attribute haben sie? Welche Invarianten und Beziehungen bestehen zwischen ihnen? Auch hier: Domänensprache. Keine Tabellen, keine Spalten, keine JPA-Annotationen.

Zusammen ergibt das Was ein vollständiges Bild des Problems. Ein Fachexperte oder ein Business Owner sollte es lesen und sagen können: „Ja, das ist das System, das wir wollen.“ Wenn er das nicht kann, ist das Was nicht fertig.

Das ist die gleiche Idee wie klassische Anforderungsanalyse. Bis hier nichts Neues. Der interessante Teil beginnt mit der nächsten Schicht.

Das Wie: Die Implementierung

Springen wir zuerst zum Wie, weil viele Entwickler vor allem an diese Schicht denken. Das Wie ist der eigentliche Code, der in Produktion läuft: Spring Boot Services, Vaadin Views, jOOQ Queries, REST Endpoints, Konfigurationsdateien.

In einem traditionellen Projekt schreiben Entwickler all das von Hand. In einem AI-unterstützten Projekt wird vieles davon generiert. So oder so: Das Wie ist die Lösung. Es ändert sich oft. Es hängt von Technologieentscheidungen ab. Es kann ersetzt werden, ohne dass sich das Was ändert.

Die Frage ist: Wie stellt man sicher, dass das Wie auch wirklich das Was widerspiegelt? In kleinen Projekten verlässt man sich auf einen guten Entwickler, der die Spec gelesen hat. In grösseren Projekten oder in AI-unterstützten Projekten skaliert das nicht. Man braucht etwas dazwischen.

Dieses Etwas ist der Harness.

Der Harness: Hier lebt der Architekt

Der Harness ist die Brücke zwischen dem Was und dem Wie. Er ist die Sammlung von Leitplanken, die jedes Stück Implementierung formen, egal ob es von einem Menschen geschrieben oder von einer AI generiert wird. Der Harness ist das wichtigste Lieferobjekt des Architekten.

Der Harness besteht aus drei Teilen:

Skills kodieren wiederverwendbares Know-how. Ein Skill könnte beschreiben, wie man eine Vaadin View baut, die den Layout-Konventionen des Projekts folgt. Ein anderer Skill könnte beschreiben, wie man eine jOOQ Query schreibt, die die Datenzugriffsmuster respektiert. Ein weiterer könnte beschreiben, wie man einen Karibu-Test für eine View schreibt. Skills sind wiederverwendbar. Sie werden einmal geschrieben und vielfach angewendet. Sie sorgen dafür, dass AI-generierter Code über Module hinweg konsistent wirkt.

MCP-Server geben der AI Zugriff auf den Kontext und die Werkzeuge, die sie braucht. Ein jOOQ MCP-Server lässt die AI das echte Datenbankschema inspizieren, statt zu raten. Ein Karibu Testing MCP-Server lässt sie Tests ausführen. Ein Atlassian MCP-Server gibt ihr Zugang zu den Use Cases in Confluence oder Jira. Ohne MCP arbeitet die AI blind. Mit MCP arbeitet sie mit den gleichen Informationen wie ein erfahrener Entwickler.

Guidelines legen die Regeln fest. Namenskonventionen. Paketstruktur. Teststrategie. Welche Bibliotheken benutzt werden und welche nicht. Was in eine Service-Schicht gehört und was in einer View bleibt. Das sind die Regeln, die jede gute Codebasis hat, aber meist nur in den Köpfen von zwei oder drei erfahrenen Entwicklern. Mit AIUP sind sie aufgeschrieben und werden automatisch angewendet.

Zusammen bilden Skills, MCP-Server und Guidelines eine ausführbare Architektur. Das finde ich am spannendsten. In traditionellen Projekten endet Architektur oft als Foliensatz oder als Confluence-Seite, die niemand liest. In AIUP ist die Architektur der Harness, und der Harness formt jede Zeile Code, die die AI produziert. Ändert der Architekt eine Guideline, spiegelt sich das in jedem zukünftigen Artefakt. Wird ein Skill verbessert, wird jede zukünftige View, die damit gebaut wird, besser. Architektur hört auf, Dokumentation zu sein, und wird ein lebendes System.

Das Diagramm

So passen die drei Schichten zusammen:

Das Was fliesst in den Harness. Der Harness formt das Wie. Nachvollziehbarkeit läuft in beide Richtungen: Jedes Stück Code sollte auf einen Use Case zurückgeführt werden können, und jeder Use Case sollte durch Tests abgedeckt sein, die den Code ausführen.

Zwei Aufgaben des Harness

Der Harness erfüllt zwei Aufgaben gleichzeitig, und beide sind wichtig.

Er befähigt die AI. Skills sagen ihr, wie sie Dinge bauen soll. MCP-Server sagen ihr, was vorhanden ist. Ohne Befähigung arbeitet die AI aus generischen Mustern und produziert generischen Code. Das Ergebnis ist isoliert korrekt, passt aber nicht zum Rest des Projekts.

Er schränkt die AI auch ein. Guidelines sagen ihr, was sie nicht tun soll. Sie verhindern, dass die AI eine neue Paketstruktur erfindet, ein anderes Test-Framework wählt oder eine Bibliothek einsetzt, die das Projekt nicht will. Ohne Einschränkung sieht jedes Modul anders aus, und die Codebasis driftet auseinander.

Ein Harness, der nur befähigt, ist zu freizügig. Er produziert funktionierenden Code, der nicht passt. Ein Harness, der nur einschränkt, ist zu restriktiv. Er blockiert die AI, ohne ihr zu helfen. Ein guter Harness macht beides.

Warum diese Trennung wichtig ist

Drei Gründe.

Specs bleiben sauber. Wenn der Architekt den Harness besitzt, kann die Spec frei von Implementierungsdetails bleiben. Es gibt keine Versuchung, in einem Use Case „verwende hier ein Vaadin Grid“ zu schreiben, weil es einen passenden Ort gibt, um diesen Entscheid festzuhalten: den Harness.

Architektur wird real. Statt eines Lieferobjekts, das in der Schublade landet, wird Architektur ein arbeitender Teil der Entwicklungsumgebung. Der Wert des Architekten ist messbar: Bessere Skills, bessere Guidelines, bessere MCP-Integration führen direkt zu besserem Code.

AI skaliert ohne Chaos. Bei spontaner AI-Nutzung promptet jeder Entwickler anders, und die Codebasis driftet. In AIUP ist der Harness geteilt. Die AI verhält sich konsistent, weil die Leitplanken konsistent sind.

Was das für die Rollen bedeutet

Auch die Rollen verändern sich.

Der Requirements Engineer besitzt das Was. Use Cases und Entity Model. Keine Technologie. Validiert von Fachexperten.

Der Architekt besitzt den Harness. Skills, MCP-Server, Guidelines. Das ist jetzt eine Rolle, die anpackt. Ein Architekt, der nur Diagramme zeichnet, reicht nicht mehr. Ein Architekt in AIUP schreibt Skills, konfiguriert MCP-Server und pflegt Guidelines.

Der Entwickler arbeitet vor allem im Wie, aber anders als früher. Statt jede Zeile von Hand zu schreiben, steuert er die AI durch den Harness, prüft das Ergebnis und verfeinert entweder den Code oder den Harness, wenn etwas nicht passt.

Der Tester sitzt quer über allen drei Schichten. Tests werden aus Use Cases abgeleitet (Was), laufen gegen die Implementierung (Wie) und nutzen die Test-Skills und MCP-Werkzeuge, die der Architekt bereitstellt (Harness).

Schlussgedanke

Die meisten SDD-Diskussionen hören bei „Spec von Implementierung trennen“ auf. Das ist richtig, aber unvollständig. Die eigentliche Frage ist, was dazwischen sitzt. AIUP antwortet darauf mit dem Harness: einer Schicht ausführbarer Architektur, die Specs auf wiederholbare und kontrollierte Weise in Code übersetzt.

Wenn du Business-Anwendungen mit AI-Unterstützung baust, ist der Harness der Ort, in den ich zuerst investieren würde. Die besten Use Cases der Welt nützen nichts, wenn jeder Entwickler die AI anders promptet. Und die stärkste AI hilft nichts, wenn sie keine Leitplanken hat. Bau den Harness, dann arbeiten beide Seiten zusammen.

Wenn du lernen willst, wie man das in der Praxis mit Spring Boot, Vaadin und jOOQ anwendet, schau dir meinen Spec-Driven Development Workshop an oder besuche unifiedprocess.ai.