Spec-Driven Development und der AI Unified Process

Simon Martinelli war zu Gast für eine Session rund um zwei sich ergänzende Ideen: Spec-Driven Development als Philosophie und den AI Unified Process als strukturierten Workflow, um sie in die Praxis umzusetzen. Wir haben alle vier Phasen live durchlaufen, beginnend mit einem leeren Vision-Dokument bis hin zu einer laufenden Vaadin-App — und einem Deployment, das sehr nah dran war.

Co-Speaker

Simon Martinelli

Java Architect and author of the Vaadin-JOOQ Archetype

Simon joined the session to introduce Spec-Driven Development and walk through the AI Unified Process end-to-end, from Vision document to a running Vaadin app.

GitHub

Was Spec-Driven Development bedeutet

Simons Kernidee ist klar: Eine Spezifikation enthält nichts Technisches. Es ist ein reines Business-Anforderungsdokument — was das System tun soll, für wen und unter welchen Rahmenbedingungen. Keine Framework-Entscheidungen, keine Datenmodelle, keine API-Signaturen.

Sobald diese Spezifikation existiert, gibt man sie der KI und lässt sie die Anwendung implementieren. Wenn sich Anforderungen ändern, aktualisiert man zuerst die Spezifikation und lässt die KI die Änderungen in den Code übertragen. Die Spezifikation ist die einzige Quelle der Wahrheit, die alles steuert.

Das ist eine saubere Trennung. Sie hält fachliche Belange und technische Entscheidungen in verschiedenen Bereichen und gibt der KI eine fokussiertere Aufgabe.

Der AI Unified Process

Der AI Unified Process (AIUP) ist ein strukturierter Ansatz für KI-gestützte Entwicklung, inspiriert vom klassischen Unified Process. Er organisiert die Arbeit in vier Phasen:

Inception: Man erstellt ein Vision-Dokument, einen Anforderungskatalog und eine Teststrategie. Diese Phase geht um Ausrichtung — was bauen wir und warum?

Elaboration: Man erarbeitet die Architekturartefakte: ein Entity Model (die Domänenobjekte), eine System-Use-Cases-Datei mit Akteuren und ihren Aktionen, ein Software Architecture Document mit Entscheidungen zu Tech-Stack, Programmiersprache und Bibliotheken sowie Akzeptanztests.

Construction: Man implementiert und testet Code auf Basis der Spezifikationen. Jedes Ergebnis — Code und Dokumente gleichermaßen — wird reviewt.

Transition: Man deployt die Anwendung und führt User Acceptance Tests durch.

Für jede Phase gibt es dedizierte KI-Skills im AIUP Marketplace. Der Marketplace ist das, was den Prozess praktikabel macht: Statt für jedes Artefakt von Grund auf zu prompten, ruft man einen speziell entwickelten Skill auf, der bereits weiß, was zu erstellen ist und wie.

Die Phasen live durchlaufen

Wir haben alle Phasen live durchgespielt und dabei für jeden Schritt Marketplace-Skills eingesetzt.

In der Inception-Phase haben wir das Vision-Dokument und den Anforderungskatalog erstellt. Das gab uns ein klares Bild davon, was die Anwendung sein soll, bevor wir irgendeinen Code angefasst haben.

In der Elaboration haben wir das Entity Model erstellt, dann die Use-Cases-Datei, danach einzelne Use-Case-Spezifikationen und schließlich das Software Architecture Document.

Sobald Elaboration abgeschlossen war, wechselten wir in die Construction und nutzten Simons Vaadin-JOOQ Archetype, um das Java-Projekt aufzusetzen. Der Archetype leistet viel: Er richtet Projektstruktur, Build und Stack-Defaults in einem Schritt ein. Danach haben wir Flyway-Migrationen aus dem Entity Model generiert und einen Use Case von Ende bis Ende implementiert.

Claude Code und der Archetype

Der Vaadin-JOOQ Archetype hat uns schnell vorankommen lassen. In Kombination mit Simons zusätzlichen AIUP-Skills fühlten sich Scaffolding und erste Implementierungsschritte reibungslos an.

Eines haben wir dabei herausgefunden: Wir brauchten das Vaadin Claude Plugin überhaupt nicht. Der Archetype und die Marketplace-Skills gaben Claude Code genug Kontext, um Vaadin-spezifische Ausgaben korrekt zu behandeln.

Was uns verlangsamte, war Claude Code selbst. Es war an diesem Tag spürbar träge. Die wahrscheinlichste Ursache war entweder ein Rate Limit des Pro-Abonnements oder Docker sbx, das ausgehende Netzwerkanfragen blockiert hat — etwas, das wir erst gegen Ende der Session vermuteten. Das zwang uns, mehr Zeit in der Construction-Phase zu verbringen als geplant.

Fast in Produktion

Gegen Ende haben wir neon.tech eingerichtet und das Deployment auf Fly.io vorbereitet. Beide Dienste brauchen wenig Konfiguration, und die Fähigkeit von neon.tech, eine PostgreSQL-Datenbank auf null zu skalieren, wenn sie nicht genutzt wird, macht es zu einer guten Wahl für Demo-Setups.

Das Deployment haben wir nicht abgeschlossen. Ein kleines Problem mit der Fly.io-Konfiguration verhinderte, dass die App innerhalb der Session live ging. Das war ein Zeit- und Tooling-Problem, keine strukturelle Lücke im Prozess.

Fazit

Spec-Driven Development fühlt sich wie eine natürliche Erweiterung der Ideen hinter Guided Coding, Vise Coding und Semantic Contracts an: Der KI ein klares, eingegrenztes Ziel geben, und sie arbeitet besser. Die Spezifikation rein in fachlichen Begriffen zu halten, ohne technische Details einfließen zu lassen, ist eine sinnvolle Einschränkung, die man leicht unterschätzt.

Der AI Unified Process ist ein echter Schritt hin zu einem Standardansatz für KI-gestützte Softwareentwicklung. Die Vier-Phasen-Struktur, die Artefaktdefinitionen und die Marketplace-Skills senken die Einstiegshürde. Der ehrliche Nachteil: AIUP ist beim ersten Kontakt nicht einfach — es gibt viele bewegliche Teile, und es braucht einige Übungsrunden, bis der Prozess sich natürlich anfühlt. Aber das gilt für die meisten strukturierten Workflows. Sobald man ihn verinnerlicht hat, kann man abweichen, wo es sinnvoll ist. AIUP ist ein Prozessvorschlag, keine starre Spezifikation.

Nützliche Links

• AI Unified Process Methodologie
• AIUP Skills Marketplace
• Vaadin-JOOQ Archetype
• Simons Petclinic-Beispiel mit AIUP
• neon.tech — Serverless PostgreSQL
• Fly.io — App-Deployment