Spec-Driven Development mit KI-Agenten: Ein praktischer Leitfaden
(Wenn Sie Videoinhalte bevorzugen, sehen Sie sich bitte die kurze Videozusammenfassung dieses Artikels unten an.)
Das Wichtigste auf einen Blick
- Spec-Driven Development mit KI-Agenten stellt eine strukturierte Spezifikation an den Anfang der Entwicklung und nutzt sie als verbindliche Grundlage für den generierten Code.
- Die Spezifikation beschreibt Ziel, Anforderungen und Akzeptanzkriterien einer Funktion, bevor ein Coding-Agent die erste Zeile Code schreibt.
- Ein typischer Prozess besteht aus drei Phasen: Anforderungen festlegen, Plan und Aufgaben ableiten, Ergebnis implementieren und verifizieren.
- Coding-Agenten benötigen Kontext zu Architektur, Konventionen und Abhängigkeiten sowie Leitplanken wie Coding-Standards, Sicherheitsvorgaben und Freigabegrenzen.
- Neue Produkte profitieren von klar definierten Funktionsumfängen, Legacy-Modernisierungen von dokumentierten Bestandsverhalten.
- Zu den Grenzen zählen der Aufwand für Erstellung und Pflege der Spezifikationen, Risiken durch veraltete Anforderungen und der weiterhin notwendige menschliche Review.
- Teams starten am besten mit einer kleinen, klar abgegrenzten Funktion und prüfen das Ergebnis konsequent gegen die Spezifikation.
Spec-Driven Development ist ein Vorgehen, bei dem eine strukturierte Spezifikation statt eines losen Prompts die Arbeit von KI-Coding-Agenten steuert. SaM Solutions zeigt, wie ein spezifikationsgesteuerter Prozess abläuft, welchen Kontext Agenten benötigen und in welchen Szenarien sich der Ansatz lohnt.
Was ist Spec-Driven Development mit KI-Agenten?
Spec-Driven Development mit KI-Agenten ist ein Entwicklungsansatz, bei dem die Spezifikation zur zentralen Quelle der Wahrheit wird. Sie umfasst mehrere zentrale Elemente:
- Fachliche Anforderungen: Sie beschreiben, was die Software leisten soll.
- Akzeptanzkriterien: Sie legen fest, wann eine Aufgabe als erfolgreich umgesetzt gilt.
- Technische Rahmenbedingungen: Sie definieren die Vorgaben für die Umsetzung.
- Plan und Aufgaben: Aus der Spezifikation werden ein konkreter Umsetzungsplan und einzelne Aufgaben abgeleitet, die KI-Agenten bearbeiten.
- Verifizierung: Das Ergebnis wird anhand derselben Spezifikation überprüft.
Die spezifikationsgesteuerte Entwicklung mit KI-Agenten unterscheidet sich damit von einem Vorgehen, bei dem Entwickler dem Agenten kurze, freie Anweisungen geben und das Ergebnis nachträglich korrigieren.
Der Ansatz reagiert auf ein bekanntes Problem: Coding-Agenten erzeugen auf Basis unscharfer Prompts oft Code, der syntaktisch korrekt wirkt, aber die eigentliche Absicht verfehlt.
Nutzen Sie das Potenzial von KI und beschleunigen Sie Ihr Business mit maßgeschneiderten Lösungen
Eine Spezifikation macht diese Absicht explizit und überprüfbar. Werkzeuge wie GitHub Spec Kit oder die Entwicklungsumgebung Kiro von AWS bilden den Ablauf aus Spezifikation, Plan und Aufgaben bereits in strukturierten Arbeitsabläufen ab. Das Prinzip lässt sich auch ohne spezielle Werkzeuge umsetzen, etwa mit Markdown-Dokumenten im Projektverzeichnis.
Unternehmen sollten jedoch berücksichtigen, dass dieser Ansatz auch zu höheren Kosten führen kann, erklärt Dzmitry Verasau, Tech Lead bei SaM Solutions:
„Die Kosten werden in jedem Fall höher sein, da die Nutzung von Agenten zusätzliche Kosten verursacht. Wenn eine Lösung bereits existiert, kann man versuchen, auf Basis des bestehenden Codes Spezifikationen zu erstellen und diese anschließend anzupassen. Dabei kann man schrittweise vorgehen, zunächst einzelne Module umstellen und nach und nach auf die Arbeit mit Spezifikationen umsteigen. Ich habe allerdings noch nicht erlebt, dass jemand diesen Ansatz bei einem bestehenden Projekt erfolgreich umgesetzt hat.“
Wie läuft ein spezifikationsgesteuerter Entwicklungsprozess ab?
Ein spezifikationsgesteuerter Prozess gliedert sich in drei Phasen: Teams legen zuerst Anforderungen und Akzeptanzkriterien fest, überführen sie dann in eine technische Planung mit konkreten Aufgaben und setzen sie anschließend um. Die Implementierung endet nicht mit dem generierten Code, sondern mit einer Verifizierung gegen die ursprüngliche Spezifikation. Die Phasen sind iterativ, denn Erkenntnisse aus der Umsetzung fließen in die Spezifikation zurück.
| Phase | Eingabe | Ergebnis des KI-Agenten | Menschliche Prüfung |
| Spezifizieren | Produktziel und Anforderungen | Spezifikation mit Akzeptanzkriterien | Sind die Anforderungen vollständig und eindeutig? |
| Planen | Freigegebene Spezifikation und Projektkontext | Technischer Plan | Passt der Plan zur Architektur? |
| Aufgaben aufteilen | Freigegebener Plan | Geordnete Implementierungsaufgaben | Sind Abhängigkeiten und Testaufgaben berücksichtigt? |
| Implementieren | Freigegebene Aufgaben | Code und Tests | Entspricht der Code dem Plan? |
| Verifizieren | Spezifikation und abgeschlossene Arbeiten | Testergebnisse und erkannte Lücken | Erfüllt die Funktion die Akzeptanzkriterien? |
Anforderungen und Akzeptanzkriterien festlegen
Am Anfang steht die Beschreibung, was eine Funktion leisten soll und für wen. Gute Anforderungen nennen Nutzerrollen, erwartetes Verhalten, Randfälle und ausdrücklich ausgeschlossene Punkte. Die Akzeptanzkriterien formulieren, unter welchen Bedingungen die Funktion als erfüllt gilt, zum Beispiel als Szenarien nach dem Muster „Gegeben, Wenn, Dann“. Je präziser diese Kriterien sind, desto eindeutiger lässt sich das Ergebnis später prüfen.
Die Spezifikation in einen Plan und konkrete Aufgaben überführen
Aus der Spezifikation entsteht zunächst ein technischer Plan, der Architekturentscheidungen, betroffene Komponenten und Schnittstellen beschreibt. Danach zerlegt das Team den Plan in kleine, einzeln prüfbare Aufgaben, die ein Agent nacheinander oder parallel abarbeiten kann. Jede Aufgabe verweist auf die Anforderung, die sie erfüllt. Diese Verknüpfung schafft die Rückverfolgbarkeit zwischen fachlichem Ziel, Aufgabe und Code.
Das Ergebnis implementieren, prüfen und verifizieren
Der Coding-Agent setzt die Aufgaben in der Implementierung um und bleibt dabei an Plan und Spezifikation gebunden. Automatisierte Tests leiten sich aus den Akzeptanzkriterien ab und bilden die erste Stufe der Verifizierung. Anschließend folgt die menschliche Prüfung durch Code-Review, die Abweichungen von Architektur und Standards aufdeckt. Weicht das Ergebnis von der Spezifikation ab, korrigiert das Team entweder den Code oder die Spezifikation, aber nie nur eines von beiden stillschweigend.
Welchen Kontext und welche Leitplanken benötigen KI-Agenten?
KI-Agenten benötigen Kontext über Codebasis, Architektur und Fachdomäne sowie Leitplanken, die ihren Handlungsspielraum begrenzen. Der Kontext beantwortet, wie das System aufgebaut ist und welche Konventionen gelten. Die Leitplanken legen fest, was der Agent tun darf, welche Standards er einhalten muss und wann ein Mensch entscheidet. Ohne beides greifen Agenten auf allgemeines Trainingswissen zurück und treffen Annahmen, die nicht zum Projekt passen.
Folgende Informationen gehören typischerweise zum Kontext und zu den Leitplanken:
- Architekturübersicht mit Modulen, Schnittstellen und Abhängigkeiten
- Coding-Standards, Namenskonventionen und bevorzugte Bibliotheken
- Teststrategie und Vorgaben zur Testabdeckung
- Sicherheitsanforderungen, etwa zum Umgang mit Zugangsdaten und personenbezogenen Daten
- Regeln dafür, welche Änderungen ein Agent eigenständig durchführen darf und welche eine Freigabe erfordern
Viele Coding-Agenten lesen dafür projektspezifische Anweisungsdateien, etwa die Konvention AGENTS.md. Diese Dateien gehören in die Repositories der jeweiligen Projekte und werden wie Code versioniert. Bei mehreren beteiligten Agenten oder Teams übernimmt eine Orchestrierung die Verteilung der Aufgaben und stellt sicher, dass alle Beteiligten denselben Kontext verwenden.
Wo eignet sich Spec-Driven Development besonders?
Spec-Driven Development eignet sich besonders für neue Produkte und Funktionen, bei denen sich Anforderungen von Beginn an strukturiert erfassen lassen. Ebenso geeignet sind bestehende Systeme und die Modernisierung von Legacy-Anwendungen, weil dort das Verhalten des Altsystems dokumentiert und als Referenz für die neue Umsetzung genutzt werden kann. Der Mehrwert wächst mit der Komplexität, der Teamgröße und der Zahl der beteiligten Agenten.
Neue Produkte und Funktionen
Bei neuen Produkten und Funktionen legt die Spezifikation Funktionsumfang, Nutzerrollen und Qualitätsziele fest, bevor Code entsteht. Teams können Annahmen früh mit Fachbereichen abstimmen und Fehlentwicklungen vermeiden, die sonst erst im Review sichtbar würden. Besonders hilfreich ist der Ansatz, wenn mehrere Entwickler und Agenten parallel an zusammenhängenden Funktionen arbeiten. Die Spezifikation dient dann als gemeinsame Referenz für alle Beteiligten.
Bestehende Systeme und Modernisierung von Legacy-Anwendungen
Bei bestehenden Systemen beschreibt die Spezifikation das gewünschte Verhalten einer Änderung und die Bereiche, die unverändert bleiben müssen. Bei der Modernisierung von Legacy-Anwendungen kann das Team das bestehende Verhalten zunächst dokumentieren und daraus Akzeptanzkriterien für die neue Implementierung ableiten. Dieser Schritt ist aufwendig, weil Altsysteme oft unvollständig dokumentiert sind. Er reduziert jedoch das Risiko, dass fachliche Regeln bei der Migration unbemerkt verloren gehen.
Welche Vorteile bietet Spec-Driven Development mit KI-Agenten?
Spec-Driven Development schafft klarere Anforderungen und reduziert Missverständnisse zwischen Fachbereich und Entwicklung. Die Spezifikation verbessert die Abstimmung zwischen Teams und Agenten, weil alle Beteiligten mit derselben Referenz arbeiten. Zusätzlich entsteht einheitlicherer Code, den Reviewer leichter gegen eine definierte Erwartung prüfen können. Diese Vorteile treten besonders deutlich bei größeren Teams und längeren Projektlaufzeiten auf.
Welche Grenzen hat Spec-Driven Development mit KI-Agenten?
Die Grenzen von Spec-Driven Development liegen im Zeitaufwand für Erstellung und Pflege der Spezifikationen, in den Risiken durch unklare oder veraltete Anforderungen und in der notwendigen menschlichen Prüfung. Eine Spezifikation ersetzt weder die Verantwortung für technische Entscheidungen noch das Code-Review. Teams sollten den Ansatz deshalb gezielt dort einsetzen, wo der Nutzen den Aufwand rechtfertigt.
Diese Aspekte begrenzen den Nutzen:
- Spezifikationen müssen geschrieben und aktuell gehalten werden.
- Fehlerhafte Anforderungen führen zu fehlerhaftem, aber konsistent umgesetztem Code.
- Agenten treffen weiterhin Annahmen, die Menschen bewerten müssen.
Zeitaufwand für die Erstellung und Pflege von Spezifikationen
Eine gute Spezifikation kostet Zeit, bevor der erste Code entsteht. Bei kleinen Änderungen, etwa einer Textanpassung oder einem Bugfix in einer einzelnen Funktion, übersteigt der Aufwand häufig den Nutzen. Hinzu kommt die Pflege, denn jede Änderung am Produkt erfordert eine Anpassung der Spezifikation. Teams sollten daher festlegen, ab welcher Größe oder Komplexität einer Änderung eine vollständige Spezifikation sinnvoll ist.
Risiken durch unklare oder veraltete Anforderungen
Ein Agent setzt eine Spezifikation konsequent um, auch wenn sie fachlich falsch oder unvollständig ist. Veraltete Dokumente führen dazu, dass der generierte Code ein früheres Verhalten abbildet, das nicht mehr gewünscht ist. Das Risiko lässt sich begrenzen, wenn Spezifikationen gemeinsam mit dem Code versioniert und bei jeder Änderung überprüft werden. Fachbereiche sollten die Spezifikation freigeben, bevor die Implementierung startet.
Notwendigkeit menschlicher Prüfung und technischer Entscheidungen
KI-Agenten können Annahmen treffen, die zur Spezifikation passen, aber architektonisch ungeeignet sind. Entscheidungen zu Datenmodellen, Sicherheit, Performance und Wartbarkeit verbleiben deshalb bei erfahrenen Entwicklern und Architekten. Die Prüfung des Plans vor der Umsetzung und das Review des Ergebnisses bleiben verpflichtende Schritte im Prozess, betont Dzmitry Verasau:
„Tests und ein manuelles Code-Review des gesamten generierten Codes sind unerlässlich. Man kann versuchen, eine andere KI-Modellfamilie für das Code-Review einzusetzen. Das ist jedoch kein Allheilmittel.“
Wie können Teams mit Spec-Driven Development beginnen?
Teams beginnen am besten mit einer kleinen Funktion, formulieren dafür Anforderungen und Akzeptanzkriterien und stellen dem Agenten den relevanten Kontext bereit. Vor der Implementierung prüfen sie den generierten Plan, danach testen sie das Ergebnis anhand der Spezifikation. Dieser überschaubare Pilot zeigt, welcher Aufwand entsteht und wie gut sich der Ansatz in die bestehenden Arbeitsabläufe einfügt.
Fazit
Spec-Driven Development mit KI-Agenten macht Anforderungen, Planung und Verifizierung für Teams und Agenten gleichermaßen nachvollziehbar und verbessert die Qualität des generierten Codes. Der Ansatz lohnt sich vor allem bei Funktionen mit höherer Komplexität und mehreren Beteiligten, benötigt aber gepflegte Spezifikationen und menschliche Prüfung. Ein kleiner Pilot zeigt, ob die spezifikationsgesteuerte Entwicklung mit KI-Agenten zu den eigenen Prozessen passt.
FAQ
Wer ist für die Spezifikation verantwortlich, wenn mehrere Teams an einem Produkt arbeiten?
Die fachliche Verantwortung liegt in der Regel beim Product Owner oder dem zuständigen Fachbereich, die technische Verantwortung bei Architektur und Entwicklung. Jedes Team verantwortet die Spezifikationen für seine Komponenten, gemeinsame Schnittstellen stimmen die Teams verbindlich ab. Eine klare Freigaberegel verhindert, dass widersprüchliche Spezifikationen entstehen und parallel arbeitende Agenten abweichende Ergebnisse liefern.
Sollten Spezifikationen im selben Repository wie der Code gespeichert werden?
Kann ein Team den Coding-Agenten wechseln, ohne seine Spezifikationen neu zu schreiben?
