Die Spec-Driven Development (SDD) Bewegung gewinnt an Fahrt. Tools wie Amazon Kiro, GitHub Spec Kit und BMad Method versprechen, Struktur in die KI-gestützte Softwareentwicklung zu bringen. Und dieses Versprechen lösen sie ein, solange man auf der grünen Wiese beginnt.
Aber die meisten Enterprise-Teams beginnen nicht auf der grünen Wiese. Sie pflegen bestehende Systeme mit Hunderttausenden Zeilen Code, etablierten Architekturen und jahrelang gewachsener Geschäftslogik. Wenn diese Teams versuchen, die populären SDD-Tools einzusetzen, stossen sie an eine Wand.
Dieser Beitrag vergleicht die drei populärsten Spec-Driven Tools und erklärt, warum der AI Unified Process (AIUP) auf unifiedprocess.ai einen grundlegend anderen Ansatz verfolgt, einen, der tatsächlich für Enterprise-Softwareentwicklung funktioniert.
Die drei Kandidaten
Amazon Kiro
Kiro ist Amazons agentische IDE, die auf Amazon Bedrock aufbaut. Sie folgt einem dreiphasigen Workflow: Requirements, Design und Implementation. Man beschreibt ein Feature in natürlicher Sprache. Kiro generiert User Stories mit Akzeptanzkriterien in EARS-Notation, erstellt ein technisches Design-Dokument und zerlegt alles in Implementierungsaufgaben.
Der Workflow ist sauber und strukturiert. Aber er wurde für Greenfield-Projekte entworfen. Selbst Amazons eigenes Produktteam hat diese Lücke eingeräumt. Ein Broadcom-Ingenieur brachte es auf den Punkt: Die meisten Entwickler starten nicht mit einer Greenfield-Idee, sie starten mit einer bestehenden Codebasis, einem unübersichtlichen Bug oder einem Design, das bereits feststeht. Kiro hat inzwischen Design-first- und Bugfix-Workflows hinzugefügt, aber die Grundannahme bleibt: Man baut etwas Neues.
Für Enterprise-Teams erzeugt Kiros obligatorische dreiphasige Pipeline einen Overhead, der nicht zu ihrer Realität passt. Ein einzeiliger Bugfix in einem Legacy-System sollte keine vollständige Spec-Generierungs-Pipeline auslösen. Und wenn bestehende Applikationen gross sind, wird es für LLMs unpraktikabel, Spezifikationen zu erstellen, ohne die Kontextlimits zu sprengen.
GitHub Spec Kit
Spec Kit ist GitHubs Open-Source-Toolkit für SDD. Es bietet eine CLI und Templates, die durch vier Phasen führen: Specify, Plan, Tasks und Implement. Es ist agentenunabhängig und funktioniert mit GitHub Copilot, Claude Code, Gemini CLI und anderen.
Spec Kit führt ein starkes Konzept ein: die constitution.md-Datei, die nicht verhandelbare Prinzipien für das Projekt festlegt. Das ist nützlich für Organisationen mit klar definierten Technologie-Stacks. Der Workflow ist gut strukturiert und erzeugt einen klaren Pfad von der Absicht zur Implementierung.
Aber Spec Kit hat dasselbe Grundproblem. Die Templates sind generisch und erfordern manuelle Anpassung für bestehende Codebasen. Der Dokumentationsaufwand kann erheblich sein, manchmal generiert man mehr Markdown-Dateien zum Reviewen, als es kosten würde, das Feature direkt zu bauen. Und wie Martin Fowlers Analyse feststellte, ist die Einführung von SDD-Tools in eine bestehende, verflochtene Codebasis immer noch weitgehend vage, wenn es um eine praktische Migrationsstrategie geht.
BMad Method
BMad Method geht einen anderen Weg: ein Multi-Agenten-Framework, in dem spezialisierte KI-Agenten (Analyst, Product Manager, Architect, Developer, QA) über dateibasierte Kommunikation zusammenarbeiten. Es beansprucht, skalierungsadaptiv zu sein und sich automatisch von Bugfixes bis zu Enterprise-Systemen anzupassen.
BMad ist das ambitionierteste der drei Tools. Mit 19+ spezialisierten Agenten und 50+ Workflows bietet es umfassende Abdeckung. Es gibt sogar eine Enterprise-Test-Architektur-Erweiterung.
Aber diese Komplexität ist zugleich seine Schwäche. Das Framework erfordert Node.js 22+, hat eine steile Lernkurve, und die Agenten-Orchestrierung bringt erheblichen Overhead mit sich. Die v6 Alpha wird immer noch für neue Projekte empfohlen, was einiges über die Reife aussagt. Und trotz des Anspruchs auf Enterprise-Tauglichkeit sind die Belege für grossflächige Brownfield-Adoption dünn.
Das gemeinsame Problem
Alle drei Tools teilen dieselben fundamentalen Annahmen:
1. Man startet von null. Die Workflows sind optimiert für „beschreibe, was du willst, und generiere es.“ Sie berücksichtigen keine 500-Tabellen-Oracle-Schemas, keine etablierten Architekturmuster und keine fünfzehn Jahre gewachsenen Geschäftsregeln.
2. Ein Entwickler steuert den Prozess. Enterprise-Entwicklung involviert mehrere Stakeholder, teamübergreifende Abhängigkeiten, Review-Prozesse und Compliance-Anforderungen. Diese Tools gehen davon aus, dass eine einzelne Person von der Spec zum Code gelangt.
3. Der Tech-Stack ist flexibel. Diese Tools schlagen gerne das Framework vor, das am besten passt. Aber Enterprise-Teams haben standardisierte Stacks. Wenn die Organisation Spring Boot mit Vaadin und jOOQ auf OpenShift betreibt, muss das Tooling das verstehen und respektieren.
4. Specs entstehen aus dem Nichts. In der Realität haben Enterprise-Systeme bereits Anforderungen, oft in Form von bestehendem Code, Datenbank-Schemas und laufenden Geschäftsprozessen. Die Herausforderung ist nicht, Specs von Grund auf zu erstellen, sondern mit dem zu arbeiten, was existiert, und es inkrementell zu erweitern.
5. Die Methodik existiert nur auf Code-Ebene. Alle drei Tools konzentrieren sich darauf, Specs in Code umzuwandeln. Aber Enterprise-Entwicklung ist ein breiterer Prozess, der Requirements Engineering, Stakeholder-Abstimmung, Teststrategie und Continuous Delivery umfasst. Ein Tool, das nur den Schritt „Code-Generierung“ abdeckt, verpasst den grössten Teil des Bildes.
Ein anderer Ansatz: AI Unified Process (AIUP)
Der AI Unified Process auf unifiedprocess.ai wurde von Grund auf für die Realität der Enterprise-Softwareentwicklung konzipiert. Er verfolgt einen grundlegend anderen Ansatz.
Anforderungen stehen im Zentrum
AIUP beginnt nicht mit Code-Generierung. Es beginnt mit Anforderungen. Business-Anforderungskataloge, Entity-Modelle, Use-Case-Diagramme und Use-Case-Spezifikationen treiben den gesamten Prozess. Das sind Artefakte, die Business-Stakeholder reviewen und validieren können, keine Markdown-Dateien, die nur Entwickler sehen.
Das ist entscheidend für Enterprise-Teams, bei denen Business-Alignment keine Option, sondern Pflicht ist. Jede Zeile Code lässt sich auf eine geschäftliche Anforderung zurückführen. Wenn ein Bug auftritt, gräbt man sich nicht durch Code, um zu verstehen, was das System eigentlich tun sollte, man geht zurück zur Spezifikation.
Iterativ, nicht Wasserfall
Anders als Tools, die einer linearen Spec-to-Code-Pipeline folgen, läuft AIUP in vier agilen Phasen, Inception, Elaboration, Construction und Transition, jeweils mit mehreren kurzen Iterationen. Spezifikationen, Code und Tests verbessern sich gemeinsam durch kontinuierliche Zyklen. Das ist keine Rückkehr zu Big Design Up Front. Es ist iterative Verbesserung, bei der jeder Zyklus auf dem vorherigen aufbaut.
Kritiker von SDD argumentieren, dass es nur mit erschöpfenden Spezifikationen funktioniert, die deterministischen Output erzwingen. AIUP adressiert das direkt: Perfekte Spezifikationen sind unmöglich und unnötig. Der wahre Wert liegt in der iterativen Verbesserung, bei der Tests konsistentes Verhalten sicherstellen, unabhängig davon, wie die KI den Code generiert.
Technologiespezifisches Tooling
Hier unterscheidet sich AIUP am deutlichsten von generischen SDD-Tools. Statt Einheits-Templates bietet AIUP technologiespezifische Plugins für Claude Code:
Das aiup-core-Plugin behandelt stackunabhängiges Requirements Engineering: Anforderungskataloge, Entity-Modelle, Use-Case-Diagramme und Spezifikationen. Es funktioniert mit jeder Technologie.
Das aiup-vaadin-jooq-Plugin fügt konkrete Implementierungs-Skills für Java-Webanwendungen hinzu: Flyway-Datenbankmigrationen, Vaadin-UI-Implementierung, Karibu-Unit-Tests und Playwright-E2E-Tests. Es integriert sogar MCP-Server für Vaadin, jOOQ, Karibu Testing und JavaDocs, und gibt der KI damit direkten Zugriff auf frameworkspezifische Dokumentation und Patterns.
Diese Plugin-Architektur ist erweiterbar. Weitere technologiespezifische Plugins sind in Entwicklung. Die zentrale Erkenntnis: Enterprise-Teams brauchen Tooling, das ihre Sprache spricht, nicht generische Templates, die stundenlange Anpassung erfordern.
Gemacht für Brownfield
AIUP arbeitet auf Feature-Ebene innerhalb von Bounded Contexts, nicht auf der Ebene „generiere eine komplette App.“ Man kann es in ein bestehendes Projekt einführen, Spezifikationen für das nächste Feature erstellen und die KI die Implementierung innerhalb der bestehenden Architektur übernehmen lassen.
Es gibt keine obligatorische Gesamtsystem-Spezifikation. Es gibt keine Anforderung, die gesamte Codebasis mit Specs nachzurüsten, bevor man starten kann. Man startet dort, wo man ist, spezifiziert, was man als Nächstes baut, und lässt den iterativen Prozess die Dokumentationsabdeckung über die Zeit verbessern.
Testing als Sicherheitsnetz
AIUP behandelt Tests als primäres Sicherheitsnetz für KI-Code-Generierung. Umfassende Tests, Unit-Tests mit Karibu, Integrationstests, E2E-Tests mit Playwright, stellen sicher, dass das System sich konsistent verhält, unabhängig davon, wie die KI Code generiert oder regeneriert. Das ermöglicht sicheres Refactoring, sichere Modernisierung und sichere Weiterentwicklung der Codebasis.
Das unterscheidet sich von SDD-Tools, die Testing als optionalen Schritt behandeln oder Tests nachträglich generieren. In AIUP wird die Teststrategie ab der Inception-Phase geplant und durch Construction und Transition hindurch umgesetzt.
Zusammenfassung: Das richtige Tool für den richtigen Zweck
| Aspekt | Kiro | Spec Kit | BMad | AIUP |
|---|---|---|---|---|
| Primäre Zielgruppe | Solopreneure, Startups | Einzelne Entwickler | Kleine Teams | Enterprise-Teams |
| Greenfield/Brownfield | Greenfield-first | Greenfield-first | Greenfield-first | Brownfield-ready |
| Prozessumfang | Code-Generierung | Code-Generierung | Gesamter Projektlebenszyklus | Gesamter Entwicklungslebenszyklus |
| Tech-Stack | Stackunabhängig | Stackunabhängig | Stackunabhängig | Technologiespezifische Plugins |
| Requirements Engineering | User Stories aus Prompts | PRD aus Prompts | Agentengeneriert | Businessvalidierte Use Cases |
| Stakeholder-Einbindung | Minimal | Minimal | Minimal | Kontinuierliche Validierung |
| Teststrategie | Generierte Tests | TDD empfohlen | QA-Agent | Ab Inception geplant |
| Iterative Verbesserung | Lineare Pipeline | Lineare Pipeline | Sprint-basiert | Agile Phasen mit Iterationen |
| Enterprise-Tauglichkeit | Eingeschränkt | Experimentell | Beansprucht Enterprise-Support | Für Enterprise konzipiert |
| Tooling | Proprietäre IDE | Open-Source-CLI | Open-Source-Agenten | Claude Code Plugins + MCP |
Fazit
Amazon Kiro, GitHub Spec Kit und BMad Method sind wertvolle Beiträge zur Spec-Driven Development Bewegung. Sie lösen ein reales Problem: Struktur in die KI-gestützte Programmierung zu bringen. Für Greenfield-Projekte, Prototypen und kleine Teams funktionieren sie gut.
Aber Enterprise-Softwareentwicklung ist ein anderes Spiel. Sie erfordert die Arbeit mit bestehenden Systemen, den Respekt vor etablierten Architekturen, die Einbindung von Business-Stakeholdern und die Planung für langfristige Wartbarkeit. Die populären SDD-Tools wurden nicht für diese Realität gebaut.
Der AI Unified Process schliesst diese Lücke. Er bringt die Disziplin von Spec-Driven Development in den Enterprise-Kontext, mit Anforderungen im Zentrum, iterativer Verbesserung als Methode, technologiespezifischem Tooling als Enabler und umfassendem Testing als Sicherheitsnetz.
Wenn Sie ein Enterprise-Team sind, das Spec-Driven Development evaluiert: Zwingen Sie keine Greenfield-Tools in eine Brownfield-Welt. Starten Sie mit einer Methodik, die für Ihre Realität gebaut wurde.
Mehr erfahren auf unifiedprocess.ai.
