Codezentrierte Entwicklung, typische Spec-Driven-Tools und der AI Unified Process im direkten Vergleich.
| Codezentrierte Entwicklung | Typische Spec-Driven-Tools | AI Unified Process | |
|---|---|---|---|
| Quelle der Wahrheit | Der Code | Der Code; die Spec ist ein Prompt | Die Use Cases (Systemverhalten) |
| Wer schreibt die Spezifikation | Niemand, oder ein Dokument, das niemand nachführt | Entwickler | Business Analysts und Requirements Engineers, KI entwirft |
| Lebensdauer der Spezifikation | Nach dem ersten Release veraltet | Ein Feature, nach der Auslieferung verworfen | Die Lebensdauer des Systems, versioniert in Git |
| Einbezug der Kunden | Anforderungsworkshop, dann Abnahme | Selten | Business Review am Ende jeder Iteration |
| Bestehende Systeme | Manuelle Archäologie | Meist neuer Code | Brownfield-Workflow: zuerst Spezifikationen ableiten |
| Wechsel von KI-Modell oder Tool | Nicht relevant | Unvorhersehbar | Sicher: Tests schützen das spezifizierte Verhalten |
| Nachverfolgbarkeit | Manuell, wenn überhaupt | Pro Feature | Anforderung → Use Case → Code → Test |
Nein. Der Prozess beginnt mit einer Vision, Geschäftsprozessen, Anforderungen und Use Cases in Klartext. Kunden und Endbenutzer validieren sie, Business Analysts und Requirements Engineers verantworten sie, und Engineers generieren und testen die Anwendung daraus. Stakeholder lesen und prüfen die Use Cases als Markdown im Repository oder in AI Unified Studio im Browser, ohne Repository-Checkout.
Die Projektübersicht in AI Unified Studio →Use Cases, die beschreiben, was das System tut, in seiner Sprache, mit generierten Diagrammen und dem aktuellen Status. Jede Iteration endet mit einem Business Review genau dieser Use Cases, und Abnahmetests folgen ihnen eins zu eins. Was freigegeben wurde, wird gebaut, und was gebaut wurde, wird getestet.
Die vier Phasen und das Business Review →Nein. Der AI Unified Process ist iterativ und inkrementell. Jede kurze Iteration endet mit einem Business Review, und Spezifikationen, Code und Tests verbessern sich gemeinsam. Spezifikationen müssen nicht von Anfang an vollständig sein: Perfekte Spezifikationen sind unmöglich und unnötig. Entscheidend ist, dass das aktuelle Verständnis aufgeschrieben, geprüft und mit dem Code synchron gehalten wird.
Unser iterativer Ansatz →Die guten Teile davon, ja. Er behält die vier Phasen, die Use Cases und die kurzen Iterationen des Unified Process und lässt den Artefakt-Katalog, die Rollenbeschreibungen und die Zeremonie weg. Was ihn heute funktionieren lässt: KI hält Spezifikation, Code und Tests konsistent, also genau den Teil, den der ursprüngliche Prozess nur von Menschen von Hand verlangen konnte.
Was blieb, was wegfiel, was dazukam →Ja. Der AI Unified Process definiert Artefakte und wie sie in Code und Tests fliessen, keine Meetings. Iterationen entsprechen Sprints, das Business Review dem Sprint Review, und Use Cases sind eine natürliche Einheit für das Backlog.
KI entwirft, Menschen verantworten. Befehle erzeugen die erste Fassung von Anforderungen, Entity-Modell, Use Cases und Testfällen; Analysten prüfen und verfeinern sie. Die Zeit fliesst dorthin, wo sie sich auszahlt: Verhalten klären, bevor der Code existiert, statt Code nachträglich umzubauen. Teams berichten, dass die Implementierung «überraschend schnell» geht, sobald die Spezifikationen präzise sind.
Gratis-Guide: Use Cases schreiben für KI →Das sind Coding-Agenten, und der AI Unified Process läuft in ihnen. Ohne Methode arbeitet der Agent mit Prompts, und das Wissen landet in Chatverläufen. Mit ihr arbeitet der Agent mit versionierten Use Cases: Ergebnisse sind prüfbar, reproduzierbar und von der Anforderung bis zum Test nachvollziehbar.
Die meisten Spec-Driven-Tools sind entwicklerzentriert: Ein Entwickler schreibt eine Spezifikation für das nächste Stück Code, und sie wird faktisch verworfen, sobald der Code ausgeliefert ist. Im AI Unified Process beschreibt die Spezifikation das Verhalten des Systems, gehört dem Requirements Engineering, wird von Kunden validiert und bleibt über die Lebensdauer des Systems im Repository: spec-anchored, nicht spec-first.
Die drei Ebenen von Spec-Driven Development →Nein. Die Plugins sind Skill-Dateien nach den offenen Standards Agent Skills und Agent Plugins. Sie laufen in Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, Gemini CLI und OpenCode und lassen sich mit Tessl für jedes dieser Tools installieren. Die Befehle und die generierten Dateien sind in jedem Tool dieselben.
Die Plugins mit anderen KI-Coding-Tools nutzen →Vier Stack-Plugins sind einsatzbereit: Vaadin mit jOOQ, Angular mit JPA, Blazor mit .NET und NestJS mit Next.js. Das Core-Plugin ist stack-unabhängig, deshalb funktioniert auch jeder andere Stack: Ein Stack-Plugin hält Ihre Frameworks und Architekturentscheide fest. Ihr Team kann es nach dem Stack-Leitfaden selbst schreiben oder es zusammen mit dem Harness darum herum bauen lassen.
Alle Plugins auf der Werkzeuge-Seite → Eigenen Stack erstellen →Agent = Modell + Harness. Der Harness ist alles rund um das Modell: Agent-Anweisungen wie AGENTS.md oder CLAUDE.md, das Architekturdokument, Skills, Dokumentationsserver, Tests, Linter und CI-Gates. Alle nutzen dieselben Modelle; der Harness entscheidet, ob der generierte Code zu Ihrer Architektur passt. Ihn für Ihr Repository einzurichten, gibt es als Dienstleistung, zusammen mit einem Stack-Plugin für Ihren Stack.
Lesen: Harness Engineering und ein gutes Architekturdokument → Kontakt aufnehmen →Generierter Code kommt als Pull Request und wird geprüft wie jeder andere Code. Aus den Use Cases abgeleitete Tests schützen das Verhalten, ein Coverage-Check findet Use Cases ohne Tests, ein Spec Review prüft die Spezifikationen und kann den Build stoppen, und der AI Unified Process Navigator führt jeden Test auf seinen Use Case zurück.
Nachverfolgbarkeit von der Spezifikation bis zu Code und Tests →In Ihrer eigenen Umgebung. Alle Artefakte liegen in Ihrem Git-Repository. Die Plugins laufen in der Sitzung Ihres Coding-Agenten, Sie wählen also Agent und Modellanbieter. AI Unified Studio stösst die Generierung in der CI Ihres eigenen Repositories an, und das Ergebnis kommt als Pull Request. Ihr KI-Zugangstoken liegt ausschliesslich als Secret bei Ihrem Git-Provider, nie im Studio.
Wie die Generierung in Ihrer CI läuft →Ja, und genau dort zahlt es sich am meisten aus. Der Brownfield-Workflow leitet zuerst Use Cases, Entity-Modell und Testfälle aus dem bestehenden Code ab, damit die Spezifikation die Realität einholt. Ab dann laufen Änderungen, neue Features und Fehlerbehebungen über die Use Cases, und Funktionalität kann Schritt für Schritt aus dem Altsystem herausgelöst werden.
Greenfield vs. Brownfield →Die Agent-Plugins und der AI Unified Process Navigator sind Open Source und kostenlos. AI Unified Studio ist in privater Beta: Zugang auf Einladung, die kostenlose Testphase startet mit der Einladung, der Preis wird zur allgemeinen Verfügbarkeit bekannt gegeben. Das Buch verkauft Apress; der Guide ist gratis. Workshops, Coaching, Stack-Plugins für Ihren Stack, Harness Engineering und Unterstützung bei der Einführung gibt es auf Anfrage.
Studio-Einladung anfragen →Wählen Sie eine Anwendung oder einen klar abgegrenzten Bereich eines bestehenden Systems als Pilot. Ein eintägiger Hands-on-Workshop mit Ihrer eigenen Domäne bringt das Team zu einem Use-Case-Katalog und einer generierten ersten Iteration. Von dort aus geht es Iteration für Iteration weiter.
Der Team-Workshop → Drei Wege zum Start →Der AI Unified Process wurde von Simon Martinelli entwickelt, Java Champion, Vaadin Champion und Oracle ACE Pro mit über 30 Jahren Erfahrung. Er beschreibt die Methode vollständig in seinem Apress-Buch «Spec-Driven Development» und im Gratis-Guide «Use Cases schreiben für KI». Die Plugins werden offen auf GitHub entwickelt, und Teams bei Unternehmen wie der WBS GRUPPE und centeractive setzen ihn in der Praxis ein.
Buch und Leitfaden → Über den Autor →Workshops, Beratung, Stack-Plugins und Harness Engineering für Ihr Team. Oder sehen Sie die Use Cases Ihres eigenen Projekts in AI Unified Studio.
