Spec-Driven Development Assess
Überblick
Spec-Driven Development nutzt maschinenlesbare Specs, Plans und Tasks (z. B. GitHub spec-kit) als Source of Truth für Agents und Menschen (spec-kit). Die wichtigsten Werkzeuge gehen unterschiedlich weit: Kiro führt durch die Abfolge Anforderungen, Design und Tasks; spec-kit ergänzt eine Projekt-„Constitution“ und konfigurierbare Schritte; Tessl zielt auf Spec-as-Source, bei dem Menschen nur noch die Spec bearbeiten (martinfowler.com).
Assess, wenn Agent-Workflows explizite Anforderungen vor Code brauchen. Specs müssen wie APIs reviewed und versioniert werden, sonst implementieren Agents das falsche Problem präzise.
Adoptionssignale
- GitHub spec-kit hatte am 30. September 2026 mehr als 139.000 Stars und 12.500 Forks, steht unter MIT-Lizenz und erschien am 21. August 2026 in Version 1.0.0, gefolgt von v1.0.13 am 29. September 2026 (GitHub spec-kit, v1.0.0 release).
- AWS machte Kiro am 17. November 2025 allgemein verfügbar, mit Property-Based Testing gegen Specs, Checkpointing, einer CLI und Teamverwaltung über AWS IAM Identity Center (Kiro GA).
- Der Thoughtworks Technology Radar Vol. 34 (November 2025) führt Spec-Driven Development in Assess (Thoughtworks).
- Böckelers Vergleich von Kiro, spec-kit und Tessl vom Oktober 2025 führte die Unterscheidung zwischen Spec-first, Spec-anchored und Spec-as-Source ein, mit der die Praxis heute diskutiert wird (martinfowler.com).
- AGENTS.md bietet Agents einen gemeinsamen, werkzeugneutralen Ort für dauerhafte Projektanweisungen, auf dem Spec-Workflows aufsetzen können (AGENTS.md).
Risiken
- Review-Last verschiebt sich, statt zu sinken. Generierte Specs, Pläne und Task-Listen können lang, repetitiv und mühsam zu prüfen sein (martinfowler.com, Thoughtworks); ungeprüfte Specs erzeugen eine Scheinfreigabe.
- Specs setzen nichts durch. Agents überspringen weiterhin Anweisungen (martinfowler.com); nur ausführbare Prüfungen wie Tests halten die Implementierung an der Spec.
- Ein Workflow für jede Aufgabengröße. Laut Thoughtworks verhalten sich die Werkzeuge je nach Größe und Art der Aufgabe sehr unterschiedlich, und bei generierten PRDs und User Stories ist manchmal unklar, für wen sie gedacht sind (Thoughtworks); der volle Prozess für kleine Fixes kostet nur Zeit.
- Spec-Drift. Im Spec-first-Ansatz dient die Spec nur der jeweiligen Aufgabe und wird danach nicht weitergepflegt (martinfowler.com); bleiben veraltete Specs im Repository liegen, behandeln spätere Agent-Läufe überholte Absichten als aktuell.
- Werkzeugspezifische Strukturen. Kiro, spec-kit und Tessl organisieren Specs unterschiedlich, ein Werkzeugwechsel bedeutet also, den Spec-Bestand umzubauen.
Vorteile & Nachteile
Vorteile
- Anforderungen, Design und Task-Zerlegung werden geschrieben und reviewed, bevor der Agent Code erzeugt; das macht die Absicht bei größeren Features prüfbar, und Kiro ergänzt Property-Based Tests, die den Code gegen das in der Spec definierte Verhalten prüfen.
- Die Werkzeuge sind 2026 gereift: GitHub spec-kit erreichte im August 2026 Version 1.0.0 unter MIT-Lizenz und läuft als Agent Skills über mehrere Coding Agents hinweg, statt Teams an einen Anbieter zu binden.
- Specs als versionierte Dateien im Repository liefern Reviewern und Auditoren eine nachvollziehbare Verbindung von der Anforderung zur Änderung, was zur Delivery in regulierten Umgebungen passt.
Nachteile
- Die Workflows erzeugen viel Text: Birgitta Böckeler stellte fest, dass spec-kit viele repetitive Markdown-Dateien produzierte, und zog das Review von Code vor.
- Agents halten sich nicht verlässlich an die Spec; in derselben Auswertung ignorierte der Agent trotz detaillierter Anweisungen Hinweise und legte Duplikate an.
- Thoughtworks warnt, man lerne womöglich „a bitter lesson“ neu, nämlich dass handgeschriebene Regeln für KI nicht skalieren, und laut Böckeler droht Spec-as-Source die Starrheit modellgetriebener Entwicklung mit dem Nichtdeterminismus von LLMs zu verbinden.
Empfehlung
Spec-Driven Development im Ring Assess an zwei oder drei mittelgroßen Features erproben, die mehrere Module berühren oder eine fachliche Freigabe brauchen; für Bugfixes und kleine Änderungen eignet sich der Ansatz nicht. Specs kurz halten, sie wie jede andere Änderung als Pull Request reviewen und jede Spec mit ausführbaren Akzeptanz- oder Property-Based Tests koppeln, denn erst die Tests halten den Agent an die Spec. Review-Zeit und Nacharbeit sollten mit vergleichbaren Features ohne Specs verglichen werden.
Regulierte Teams sollten die Spec-anchored-Variante als Nachweis der Verbindung zwischen Anforderungen und Änderungen betrachten. Spec-as-Source ist noch nicht reif für den Produktionseinsatz. Als Einstieg bietet sich spec-kit an, wenn das Team bereits mit mehreren Agents arbeitet, oder Kiro, wenn ein integrierter IDE-Workflow von AWS gewünscht ist.
Quellen
Beratung
Vom Radar zur Umsetzung
Du hast Technologien bewertet — wir helfen dir, sie sicher und messbar in produktive Systeme zu bringen.
