Die besten Spec-Driven-Development-Tools für KI-gestützte Programmierung
(Wenn Sie Videoinhalte bevorzugen, sehen Sie sich bitte die kurze Videozusammenfassung dieses Artikels unten an.)
Das Wichtigste auf einen Blick
- Spec-Driven Development stellt eine versionierte Spezifikation an den Anfang der Entwicklung. KI-Agenten erzeugen daraus Pläne, Aufgaben und Code.
- GitHub Spec Kit, Kiro, OpenSpec, Tessl, BMAD Method, Spec Kitty und SpecPilot decken unterschiedliche Schwerpunkte ab. Sie reichen von leichtgewichtigen CLI-Werkzeugen bis zu vollständigen Entwicklungsumgebungen.
- OpenSpec ist auf Änderungen an bestehenden Codebasen ausgelegt. GitHub Spec Kit und Spec Kitty zielen stärker auf neue Funktionen und strukturierte Workflows.
- Kiro bündelt Spezifikationen, Agenten und Editor in einer eigenen IDE von AWS. Die anderen Tools arbeiten mit vorhandenen Assistenten wie Claude Code, Cursor oder GitHub Copilot.
- Für die Auswahl zählen Projektumfang, Assistenten-Kompatibilität, Rückverfolgbarkeit, Unterstützung für Bestandscode, Freigabeprozesse, Validierung, Datenschutz und Gesamtkosten.
SaM Solutions zeigt, welche Tools für Spec-Driven Development im Jahr 2026 relevant sind und worin sie sich unterscheiden. Der Beitrag stellt sieben führende Spec-Driven-Development-Tools vor und vergleicht sie in einer Tabelle. Er erläutert außerdem acht Kriterien für die Auswahl und erklärt, wann sich ein externer Technologiepartner lohnt. So können Entwicklungsteams KI-Agenten gezielt steuern, statt Code ohne verbindliche Vorgaben zu generieren.
Was ist Spec-Driven Development?
Spec-Driven Development (SDD) ist ein Entwicklungsansatz, bei dem eine strukturierte Spezifikation den Ausgangspunkt bildet und Code daraus abgeleitet wird. Die Spezifikationen beschreiben Anforderungen, Verhalten und Randbedingungen so präzise, dass KI-Agenten sie zuverlässig umsetzen können. Sie liegen meist als Markdown-Dateien im Repository und lassen sich per Pull Request prüfen und versionieren.
Der typische Ablauf besteht aus mehreren Schritten, die je nach Tool variieren:
- Anforderungen und Ziele formulieren
- technischen Plan und Architektur festlegen
- Aufgaben ableiten
- Code durch Agenten erzeugen
- Ergebnis gegen die Spezifikation prüfen
Das Ziel ist ein reproduzierbares Ergebnis statt unstrukturierter Prompts. Dadurch lassen sich Entscheidungen später nachvollziehen, und die Dokumentation entsteht als Teil des Entwicklungsprozesses.
Nutzen Sie das Potenzial von KI und beschleunigen Sie Ihr Business mit maßgeschneiderten Lösungen
Die besten Spec-Driven-Development-Tools
Die besten Spec-Driven-Development-Tools unterscheiden sich vor allem in vier Punkten. Das sind der Workflow-Umfang, die Bindung an einen Editor oder Assistenten, der Umgang mit Bestandscode und der Grad der Automatisierung. GitHub Spec Kit, OpenSpec, BMAD Method, Spec Kitty und SpecPilot sind Open-Source-Werkzeuge für vorhandene Assistenten. Kiro ist eine eigene IDE, und Tessl verfolgt als Plattform mit Spec-Registry einen eigenen Ansatz.
| Tool | Schwerpunkt | Betriebsmodell | Besonders geeignet für |
| GitHub Spec Kit | Strukturierter Workflow von der Spezifikation bis zur Umsetzung | Open-Source-CLI | Neue Funktionen und Greenfield-Projekte |
| Kiro | Spezifikationen, Hooks und Agenten in einer IDE | Eigene IDE von AWS | Teams, die eine integrierte Umgebung wünschen |
| OpenSpec | Änderungsvorschläge als Delta-Spezifikationen | Open-Source-CLI | Bestehende Codebasen |
| Tessl | Spezifikationen als zentrales Artefakt, Spec-Registry | Plattform | Teams mit Fokus auf gepflegte Bibliotheks-Specs |
| BMAD Method | Agile Rollen-Agenten und Planungsdokumente | Open-Source-Framework | Größere Vorhaben mit mehreren Rollen |
| Spec Kitty | Work Packages, Git Worktrees, Kanban-Dashboard | Open-Source-CLI | Parallele Arbeit mehrerer Agenten |
| SpecPilot | Leichtgewichtige .specs-Struktur mit Validierung | Open-Source-CLI | Kleine bis mittlere Projekte |
GitHub Spec Kit
GitHub Spec Kit ist ein Open-Source-Toolkit von GitHub. Der Workflow führt über Slash-Commands von den Projektprinzipien über die Spezifikation und den Plan bis zu Aufgaben und Umsetzung. Es funktioniert mit mehreren KI-Assistenten, darunter GitHub Copilot, Claude Code und Gemini CLI.
Vorteile:
- klar definierter, nachvollziehbarer Ablauf
- breite Unterstützung gängiger Assistenten
- hohe Verbreitung und aktive Community
Nachteile:
- Aufwand für kleine Änderungen kann hoch sein
- für bestehende Codebasen weniger spezialisiert
Kiro
Kiro ist eine agentenbasierte IDE von AWS. Sie erzeugt pro Funktion die Dateien requirements.md, design.md und tasks.md. Hooks automatisieren Aktionen bei Dateiänderungen, und Steering-Dateien liefern dauerhaften Projektkontext.
Vorteile:
- Spezifikation, Editor und Agenten in einer Umgebung
- Hooks ermöglichen Automatisierung wiederkehrender Schritte
- niedrige Einstiegshürde für Teams ohne eigenes Tooling
Nachteile:
- Bindung an eine eigene IDE
- Preismodell und Datenschutzoptionen müssen vor dem Einsatz geprüft werden
OpenSpec
OpenSpec ist ein leichtgewichtiges Open-Source-Framework, das Änderungen als Vorschläge mit Delta-Spezifikationen verwaltet. Aktuelle Spezifikationen und laufende Änderungen liegen in getrennten Ordnern im Repository. Nach der Umsetzung fließen die Änderungen in die Basis-Spezifikationen zurück.
Vorteile:
- gut geeignet für Änderungen und Refactoring in Bestandscode
- geringer Einrichtungsaufwand
- Änderungen bleiben als Vorschläge prüfbar
Nachteile:
- weniger Funktionen für Projektmanagement und Rollen
- wenig integrierte Unterstützung für Dashboards
Tessl
Tessl verfolgt den Ansatz, Spezifikationen zum primären Artefakt zu machen. Eine Spec-Registry stellt gepflegte Spezifikationen für Bibliotheken bereit, damit Agenten aktuelle API-Informationen nutzen. Das Produkt entwickelt sich schnell, daher sollten Teams den aktuellen Funktionsumfang und die Verfügbarkeit bei Tessl prüfen.
Vorteile:
- Registry reduziert Fehler durch veraltetes Bibliothekswissen
- konsequenter Fokus auf Spezifikationen statt Code
- interessant für den Umgang mit Abhängigkeiten
Nachteile:
- kommerzielle Plattform mit Anbieterbindung
- Konzept erfordert Umdenken im Team
BMAD Method
BMAD Method (Breakthrough Method for Agile AI-Driven Development) ist ein Open-Source-Framework mit spezialisierten Rollen-Agenten. Dazu gehören Analyst, Product Manager, Architekt, Scrum Master, Entwickler und QA. Die Agenten erzeugen Planungsdokumente wie PRD und Architektur, aus denen Stories für die Umsetzung entstehen.
Vorteile:
- bildet agile Rollen und Workflows ab
- umfassende Planungsartefakte für große Vorhaben
- unabhängig von einem bestimmten Editor
Nachteile:
- hoher Einarbeitungs- und Dokumentationsaufwand
- für kleine Aufgaben überdimensioniert
Spec Kitty
Spec Kitty ist ein Open-Source-CLI, das als Community-Fork von GitHub Spec Kit entstanden ist. Es teilt die Umsetzung in Work Packages mit Status wie planned, in_progress, for_review und done auf. Jeder Agent arbeitet in einem isolierten Git Worktree, und ein optionales Kanban-Dashboard zeigt den Fortschritt.
Vorteile:
- parallele Arbeit mehrerer Agenten ohne Branch-Konflikte
- Review-, Accept- und Merge-Schritte unterstützen Governance
- lokal betreibbar, Kernartefakte liegen im Repository
Nachteile:
- zusätzliche Konzepte wie Missionen und Worktrees
- Voraussetzungen wie Python und Git müssen vorhanden sein
SpecPilot
SpecPilot ist ein Open-Source-CLI für Claude Code, Cursor und weitere Assistenten. Es legt einen .specs-Ordner mit Unterordnern für Architektur, Entwicklung und Anforderungen an. Ein validate-Befehl prüft, ob die Spezifikationen konsistent sind.
Vorteile:
- leichtgewichtig und schnell eingerichtet
- Markdown-Dateien lassen sich in Pull Requests gut vergleichen
- Validierung per CLI
Nachteile:
- kleineres Ökosystem als etablierte Alternativen
- weniger Funktionen für Zusammenarbeit und Freigaben
Wie wählen Sie das passende Spec-Driven-Development-Tool für Ihre Anforderungen?
Das passende Tool hängt von Projektumfang, Assistenten-Kompatibilität, Rückverfolgbarkeit, Bestandscode, Freigabeprozessen, Validierung, Datenschutz und Gesamtkosten ab. Ein Pilotprojekt mit zwei bis drei Kandidaten liefert dafür verlässlichere Ergebnisse als ein reiner Funktionsvergleich. Die folgenden Kriterien helfen, diese Pilotphase strukturiert zu bewerten.
Wir haben außerdem den Tech Lead bei SaM Solutions, Dzmitry Verasau, gebeten, diesen Punkte zu kommentieren und seine Expertenmeinung dazu abzugeben, wie Unternehmen das passende Spec-Driven-Development-Tool für ihre Anforderungen auswählen können.
Projektumfang und Komplexität definieren
Kleine Vorhaben profitieren von schlanken Werkzeugen wie OpenSpec oder SpecPilot. Große Programme mit mehreren Teams benötigen Rollen, Planungsartefakte und Orchestrierung, wie sie BMAD Method oder Spec Kitty bieten. Je komplexer die Architektur, desto wichtiger werden klare Anforderungen und Abhängigkeiten zwischen Komponenten. Ein allgemeiner Tipp von Dzmitry Verasau:
„Definieren, wie es vorher war, und 20 % weglassen.“
Kompatibilität mit KI-Programmierassistenten und Entwicklungsumgebungen prüfen
Die meisten Open-Source-Tools arbeiten mit mehreren Assistenten wie Claude Code, Cursor oder GitHub Copilot. Expertenmeinung:
„Die Kompatibilität lässt sich leicht überprüfen: Gibt es ein Plugin für die gewünschte Entwicklungsumgebung? Manchmal kann man ganz ohne Entwicklungsumgebung auskommen und stattdessen einen eigenständigen Command-Line-Agenten verwenden.“
Verwaltung von Spezifikationen und Rückverfolgbarkeit von Anforderungen bewerten
Gute Tools halten Spezifikationen im Repository und erlauben eine saubere Versionierung. Die Rückverfolgbarkeit von der Anforderung über die Aufgabe bis zum Commit ist besonders in regulierten Branchen relevant. Achten Sie darauf, ob Änderungen an Spezifikationen als Diff prüfbar sind.
Unterstützung für bestehende Codebasen prüfen
Die meisten Unternehmen arbeiten nicht auf der grünen Wiese. OpenSpec ist auf Änderungen an Bestandscode ausgelegt, während andere Tools primär neue Funktionen strukturieren. Für Refactoring und Modernisierung sollten Teams testen, wie gut sich vorhandenes Verhalten als Spezifikation erfassen lässt.Dzmitry Verasau sagt:
„Je standardisierter und verbreiteter eine Technologie ist, desto besser ist der Support. Es gibt nur wenige spezifische Benchmarks, aber gelegentlich gibt es entsprechende Meldungen – wie kürzlich, als OpenAI COBOL gezielt verbessert hat.“
Funktionen für die Zusammenarbeit und Freigabeprozesse bewerten
Mehrere Beteiligte benötigen definierte Review- und Freigabeschritte für Spezifikationen und Pläne. Spec Kitty bildet solche Stufen mit Review-, Accept- und Merge-Gates ab. Eine klare Governance legt fest, wer Spezifikationen ändern und Umsetzungen abnehmen darf.
Test- und Validierungsmöglichkeiten prüfen
Eine Spezifikation entfaltet ihren Nutzen erst, wenn sich das Ergebnis dagegen prüfen lässt. Prüfen Sie, ob das Tool Akzeptanzkriterien, automatische Validierung und die Ableitung von Tests unterstützt. Der Experte ist überzeugt: Das wird kein technisches Problem darstellen.
„Manuelles Testen ist immer möglich, automatisiertes Testen wird von allen modernen Lösungen unterstützt. Die Validierung hängt davon ab, ob klare Anforderungen vorliegen. Sind diese vorhanden, lässt sich validieren.“
Sicherheit, Datenschutz und Bereitstellungsoptionen berücksichtigen
Spezifikationen und Code gelangen an externe KI-Modelle, daher sind Datenverarbeitung und Speicherorte zu klären. Lokal betreibbare Werkzeuge mit Artefakten im eigenen Repository reduzieren die Abhängigkeit von Anbietern. Für deutsche Unternehmen sind DSGVO-Konformität und die Anforderungen des jeweiligen Modellanbieters zu prüfen.
Tech Lead bei SaM Solutions ergänzt:
„Wenn man verhindern möchte, dass der Code für das Training verwendet wird, sollte man die Vereinbarung mit dem LLM-Anbieter prüfen oder auf lokale Lösungen umsteigen.“
Gesamtkosten und Einrichtungsaufwand vergleichen
Open-Source-Tools verursachen keine Lizenzkosten, binden aber Zeit für Einrichtung und Schulung. Hinzu kommen die Kosten der genutzten KI-Modelle, die mit der Anzahl der Agentenläufe steigen. Berücksichtigen Sie zusätzlich den Pflegeaufwand für Dokumentation und Spezifikationen.
Dzmitry Verasau weist darauf hin, dass es hier noch keine etablierten Best Practices gibt:
„Man kann es kostengünstig angehen: Man abonniert eine chinesische LLM, installiert einen kostenlosen Coding-Agenten und legt los. Die Risiken liegen dabei in der Sicherheit und im Datenschutz. Teurere Lösungen wie Claude Enterprise kosten dagegen um ein Vielfaches mehr. Lokale Lösungen wiederum erfordern hohe Anfangsinvestitionen in die Hardware – ab 50.000 USD aufwärts.“
Spec-Driven Development mit SaM Solutions
SaM Solutions ist ein Softwareentwicklungsunternehmen mit Erfahrung in individueller Softwareentwicklung, Modernisierung und KI-gestützten Lösungen. Das Unternehmen unterstützt Kunden bei der Auswahl und Einführung von Spec-Driven-Development-Tools. Dazu gehört die Bewertung der vorhandenen Architektur und Toolchain.
Ein typischer Einstieg umfasst folgende Schritte:
- Analyse der Anforderungen und der bestehenden Codebasis
- Pilotprojekt mit ausgewählten Tools
- Definition von Governance und Review-Regeln
- Integration in bestehende CI/CD-Prozesse
SaM Solutions berücksichtigt dabei die individuellen Vorgaben zu Datenschutz, Sicherheit und Projektumfang.
Fazit
Die besten Spec-Driven-Development-Tools unterscheiden sich in Workflow-Umfang, Bestandscode-Unterstützung und Grad der Automatisierung. Unternehmen erzielen die größten Vorteile, wenn Tool, Assistenten und Governance zum Projektumfang passen. Ein Pilotprojekt mit klar definierten Kriterien reduziert das Risiko einer Fehlentscheidung.
FAQ
Lassen sich Spec-Driven-Development-Tools ohne KI-Programmierassistenten nutzen?
Ja, die Spezifikationen sind normale Markdown-Dateien und lassen sich manuell pflegen. Den größten Nutzen entfalten die Tools jedoch mit KI-Assistenten, weil diese Spezifikationen automatisch in Pläne und Code überführen. Ohne Assistenten dienen sie vor allem der Dokumentation und Abstimmung.
Können mehrere Spec-Driven-Development-Tools im selben Repository verwendet werden?
Wie können Teams Spezifikationen von einem Spec-Driven-Development-Tool in ein anderes übertragen?
Unterstützen Spec-Driven-Development-Tools Spezifikationen in anderen Sprachen als Englisch?
