Spec Driven Development – Vibe Coding noch leistungsfähiger machen

Bevor es losgeht

Die IDE namens Kiro wurde bei GeekNews bereits einmal behandelt.

Eine Einführung aus der Perspektive von Spec Driven Development (SDD), der Entwicklungsphilosophie, auf die Kiro abzielt, gab es jedoch noch nicht,

und da nun ein gutes Video zum Verständnis von Spec Driven Development veröffentlicht wurde, stelle ich es hier vor.

---

Kiro

• Agentenbasierte IDE: unterstützt die Entwicklung per natürlicher Sprache, ist dabei aber klar darauf ausgerichtet, „Spezifikationen als Artefakte erster Klasse“ zu behandeln.

• Bewahrt das Tempo des „Vibe Coding“ bisheriger Agenten-IDEs und definiert Entscheidungen, Annahmen und Einschränkungen zugleich in Spezifikationsdokumenten.

• Workflow: Gibt man eine Idee ein, werden sofort drei Dateien erzeugt – requirements / design / tasks – und von dort aus gestartet. Der Editor basiert auf einem Code-OSS-Fork mit zusätzlichen Tabs für „Specs / Hooks / Steering“.

  • Specs: strukturiert Anforderungen (User Stories + Akzeptanzkriterien im EAR-Format) und verknüpft anschließend Implementierung, Tests und Änderungen mit der Spezifikation.
  • Hooks: überwacht Datei- und Codeänderungen und löst den Spec-Workflow aus.
  • Steering: checkt Team-Guides als Regeln (Markdown) im .kiro/-Verzeichnis im Repository-Root ein – z. B. TDD-Regeln, um das Verhalten des Agenten zu vereinheitlichen.

Warum Spec Driven nötig ist

• Ergänzt die Grenzen von Vibe Coding: Wenn durch Chat-Pingpong schnell Code erzeugt wird, verschwinden die Begründungen für Entscheidungen im Chat-Stream, sodass später unklar wird, „was warum gebaut wurde“. SDD setzt deshalb zuerst eine verhaltensorientierte Spezifikation auf und nutzt sie als stabilen Kompass.

• Definition der Spezifikation (Verhalten, Eigenschaften, Invarianten): Beschreibt nicht die Implementierung, sondern wie sich das System verhalten soll – mit Konzepten wie Safety-/Liveness-Eigenschaften und Invarianten, aber in einer entwicklerfreundlichen Syntax, die zugänglich bleiben soll.

Vorteile von SDD

• Sichtbarkeit und Wiederverwendung von Entscheidungen: Die Spezifikation wird zur „Quelle“ von Codeänderungen, erleichtert Reviews und Abstimmung, und selbst wenn sich Funktionen ändern, bleibt die Absicht (behaviors) erhalten.

• Kombinierbare, lebendige Spezifikationen: User-Szenarien, Akzeptanzkriterien, Interface-/Datenverträge, Performance-/SLA-Anforderungen usw. lassen sich modularisieren und wiederverwenden bzw. zusammensetzen (vom Service- bis zum System-Level).

• Einsatz über den gesamten SDLC: von der Abstimmung in Anforderungs- und Designphase bis zur Feedback-Schleife bei Problemen nach dem Deployment – die zentrale Frage ist, wie man trotz der hohen Geschwindigkeit der Codegenerierung im AI-Zeitalter Review, Qualität und Konsistenz sicherstellt.

SDD-Demo

• Für den Startpunkt der Demo im Video unter dem Main link siehe diese URL: https://youtu.be/olMxlFSxydc?si=sei-bBZ0Q0yszaWn&t=1085

SDD-Ablauf

A. Ersteinrichtung

1. Projektkonfiguration – Hooks, Steering, MCP
2. TDD einrichten (empfohlen)
3. Spec einrichten – Spec-Erstellung auf Basis des EAR-Formats (empfohlen; kann per AI auch automatisch aus der Analyse eines bestehenden Projekts erzeugt werden)

B. Feature-Implementierung

1. Spec-Ableitung – neue Anforderungen in der Spec abbilden bzw. aktualisieren
2. Guardrails einrichten (empfohlen) – Test-Stubs, Regeln erstellen
3. Implementierung <-> Test – dieser Bereich wird größtenteils wiederholt durch AI ausgeführt; der Entwickler greift nur bei kleineren Codekorrekturen ein, die die AI nicht sauber anpassen kann

• Nach Abschluss der Projektstruktur werden Funktionen durch Wiederholung der Phase „B. Feature-Implementierung“ erweitert.

Hinweise

• Wenn die Qualität der Spec-Dokumente nicht ein Mindestniveau erreicht, funktioniert es nicht.
• Die Regeln für Spec-Dokumente im Video werden nicht im Detail erklärt. (Referenz: https://kiro.dev/docs/specs/)
• Die Nutzung von TDD wird empfohlen, aber bei Projekten ohne TDD hätten die meisten laut Aussage kaum Nutzen aus dieser Methodik gezogen.

---

Persönliche Einschätzung

• Eine weitere Methodik, die aus einer anderen Perspektive heraus vorgeschlagen wurde, um AI gut zu nutzen.
• Gut geschriebene Dokumentation hat immer sehr viele Vorteile. Aus der praktischen Erfahrung, dass viele Dokumente in der Realität jedoch nicht gut gepflegt werden, scheint entscheidend zu sein, wie viel Zustimmung sich dafür gewinnen lässt.
• Zum jetzigen Zeitpunkt ist die Entwicklungsstrategie AI + TDD eine Methodik, mit der viele Entwickler sympathisieren und die bis zu einem gewissen Grad validiert ist. Wenn sich die Wirkung durch einen Vergleich zwischen reinem TDD und TDD zusammen mit SDD belegen ließe, dürfte das deutlich mehr Zustimmung finden.