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.
Noch eine kurze Bemerkung zum Wort Harness. Seit Februar 2026 hat sich der Begriff Harness Engineering in der Branche etabliert. Geprägt wurde er von Mitchell Hashimoto, danach aufgegriffen von OpenAI, Martin Fowler und Birgitta Böckeler und Red Hat. Die Idee ist die gleiche wie bei AIUP: Man baut eine strukturierte Umgebung um den AI-Agenten, damit das Ergebnis vorhersehbar wird. AIUP geht einen Schritt weiter, denn der Harness allein reicht nicht. Es braucht auch ein klares Was darüber und ein verifizierbares Wie darunter. Genau darum geht es in diesem Beitrag.
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. Aber genau das ist der Teil, den Harness Engineering in der Form von OpenAI nicht abdeckt. Birgitta Böckeler hat das in ihrer ersten Reaktion auf den OpenAI-Artikel auf den Punkt gebracht: Der Harness konzentriert sich auf interne Qualität und Wartbarkeit, aber die Verifikation von Funktionalität und Verhalten fehlt. In AIUP beginnt diese Verifikation genau hier, im Was.
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.
Das ist auch die Schicht, in der sich AIUP am stärksten mit Harness Engineering überschneidet. Das OpenAI-Team beschreibt drei Bausteine: Context Engineering, Architectural Constraints und eine Art „Garbage Collection“, die der Entropie entgegenwirkt. Der Red-Hat-Artikel bringt es auf eine kurze Formel: structure in, structure out. AIUP sagt das Gleiche, aber es gibt dem Architekten eine konkrete Menge an Artefakten in die Hand:
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. Das ist der Context-Engineering-Teil von Harness Engineering, konkret gemacht.
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. Das ist der Architectural-Constraints-Teil von Harness Engineering.
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.
Diese Nachvollziehbarkeit in beide Richtungen schliesst die Lücke, auf die Birgitta Böckeler hingewiesen hat. Ein reiner Harness garantiert, dass der Code gut strukturiert ist. Er sagt aber nichts darüber aus, ob der Code auch das tut, was das Business verlangt hat. AIUP stellt diese Verbindung her.
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. In den Worten von Harness Engineering ist der Architekt der Harness Engineer.
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). Hier findet die Verhaltensverifikation statt. Und genau diese Schicht lässt die OpenAI-Version von Harness Engineering offen.
Schlussgedanke
Die meisten SDD-Diskussionen hören bei „Spec von Implementierung trennen“ auf. Die Harness-Engineering-Bewegung fügt einen wichtigen Gedanken hinzu: Dazwischen liegt eine dritte Schicht, und dort findet die eigentliche Engineering-Arbeit für AI-unterstützte Entwicklung statt. AIUP teilt diese Sicht, hört aber dort nicht auf. Der Harness allein liefert gut strukturierten Code. Er liefert nicht den richtigen Code. Dafür braucht es das Was darüber und verifizierbare Tests darunter. Die drei Schichten zusammen verwandeln Absicht in laufende Software, und zwar wiederholbar und nachweisbar.
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, verbinde ihn auf der einen Seite mit klaren Use Cases und auf der anderen Seite mit echten Tests, und AI-unterstützte Entwicklung fühlt sich wieder nach Engineering an.
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.
