Spec-Driven Development: KI-Entwicklung planbar machen

Ein typisches Beispiel: „Bau mir einen Login.“ Der KI-Agent legt los. Ein Formular entsteht, dazu etwas Code für die Anmeldung. Bei der Prüfung zeigt sich, dass eigentlich eine API gebraucht wird. Die Eingabefelder passen außerdem zu den Vorgaben des bestehenden Systems noch nicht.

Schon beginnt die Korrekturschleife. Nachfragen, ändern lassen, prüfen, wieder nachfragen.

Spec-Driven Development setzt vor der Implementierung an. Das gewünschte Verhalten, die Anforderungen und die technischen Rahmenbedingungen werden zuerst beschrieben und geprüft. Daraus entstehen ein Entwurf, konkrete Aufgaben und schließlich der Code. Ein Sprachmodell kann in allen diesen Schritten unterstützen.

Der Ansatz ist für Entwickler und Teams interessant, die KI zum Aufbau ihrer Anwendungen nutzen und dabei nachvollziehen wollen, warum ein Agent eine bestimmte Lösung umsetzt.

Spec-Driven Development als Arbeitsgrundlage

Spec-Driven Development, auch spezifikationsgetriebene Entwicklung genannt, macht die Spezifikation zum zentralen Arbeitsdokument. Sie beschreibt, was ein System leisten soll und welche Vorgaben dabei gelten.

Diese Beschreibung dient als gemeinsame Grundlage für:

• die Anforderungen an eine Funktion,
• den technischen Entwurf,
• die Aufgaben für die Implementierung,
• die Tests und die Überprüfung des Ergebnisses,
• die Dokumentation.

Ein Large Language Model, kurz LLM, kann aus einer ersten Beschreibung Anforderungen ausarbeiten. Ein Mensch prüft diese, ergänzt fehlende Angaben und gibt sie frei. Erst danach folgt der nächste Schritt.

Die Spezifikation wirkt dabei wie eine Vereinbarung über das erwartete Verhalten. Das Team kann die Umsetzung daran prüfen und fehlende Funktionen benennen.

Ein Prompt als Ausgangspunkt

Ein Prompt kann der Ausgangspunkt sein. Eine brauchbare Spezifikation braucht überprüfbare Angaben.

Eine hilfreiche Spezifikation macht Anforderungen überprüfbar. Sie benennt beispielsweise eine Schnittstelle, deren Eingaben, das erwartete Ergebnis und noch offene Entscheidungen. Außerdem wird sie vor der Umsetzung bewusst geprüft.

Ein seitenlanger Auftrag voller allgemeiner Wünsche kann weiterhin viel Spielraum lassen. Schon wenige präzise Angaben können diesen Spielraum deutlich verkleinern.

Ein konkretes Beispiel: Eine Login-Schnittstelle spezifizieren

Die Aufforderung „Erstelle eine Login-Seite“ lässt einiges offen. Eine Benutzeroberfläche und ein Endpunkt zur Authentifizierung sind unterschiedliche Aufgaben. Auch die übertragenen Daten und das Verhalten bei fehlenden Angaben brauchen eine Festlegung.

Für eine spezifikationsgetriebene Umsetzung lässt sich das Vorhaben zunächst so festhalten:

Damit ist bereits nachvollziehbar, warum der spätere Code einen POST-Endpunkt und genau diese Feldnamen verwendet. Der Agent erhält dafür ausdrückliche Vorgaben.

Auch die Lücke wird sichtbar: Die konkrete Fehlerantwort bei fehlendem Benutzernamen ist noch offen. Sie sollte vor der Umsetzung geklärt werden. Ein Platzhalter wie „passenden Fehler zurückgeben“ überlässt dem Modell weiterhin eine Entscheidung.

Aus Anforderungen werden prüfbare Fälle

Aus diesem kleinen Beispiel lassen sich unmittelbar Prüfaufgaben ableiten:

• Der vereinbarte Endpunkt unterstützt die Methode POST.
• Die Implementierung verarbeitet die Felder user und pass.
• Gültige Zugangsdaten führen zum vereinbarten Status 200.
• Ein fehlender Benutzername führt zur zuvor festgelegten Fehlerantwort.

Das Beispiel beschreibt einen Ausschnitt der Authentifizierung. Auch das Verhalten bei ungültigen Zugangsdaten oder fehlendem Passwort müsste beschrieben werden. Solche offenen Punkte gehören in die Planung, bevor der Agent sie beiläufig selbst ausfüllt.

Die Bestandteile einer brauchbaren Spezifikation

Eine Spezifikation muss dem Umfang der Aufgabe entsprechen. Für eine überschaubare Funktion reicht eine kompakte Beschreibung. Für eine größere Anwendung braucht es mehr Struktur.

Als Ausgangspunkt helfen sechs Angaben:

1. Ziel: Die gewünschte Funktion.
2. Verhalten: Das erwartete Systemverhalten in den beschriebenen Fällen.
3. Eingaben und Ergebnisse: Die angenommenen Daten und erwarteten Antworten.
4. Rahmenbedingungen: Die gesetzten technischen Vorgaben, Sprachen und Bibliotheken.
5. Fehlerfälle: Das Verhalten bei fehlenden Voraussetzungen.
6. Überprüfung: Die Kriterien für eine erfüllte Anforderung.

Dazu gehört eine Liste offener Fragen. Das klingt unspektakulär, erspart aber das spätere „Ach so war das gemeint“.

Technische Vorgaben sollten ausdrücklich genannt werden, wenn sie bereits feststehen. Die Detailplanung kann anschließend im Entwurfsdokument erfolgen. So bleibt erkennbar, welche Anforderungen vorgegeben sind und welche Umsetzung erst noch vorgeschlagen wird.

Der Arbeitsablauf: Von der Anforderung bis zum Betrieb

Der folgende Ablauf verbindet Spec-Driven Development mit Bestandteilen des Softwareentwicklungslebenszyklus, häufig als SDLC bezeichnet. Dazu gehören Planung, Entwurf, Implementierung, Tests, Qualitätssicherung, Bereitstellung und Wartung.

Die KI unterstützt diesen Ablauf. Freigaben und Prüfungen schaffen dabei klare Übergänge zwischen den einzelnen Schritten. Als konkretes Werkzeug dokumentiert GitHub Spec Kit den Weg von der Spezifikation über den technischen Plan und die Aufgaben bis zur Implementierung und anschließenden Prüfung.

1. Das gewünschte Verhalten beschreiben

Am Anfang steht die Beschreibung der Funktion samt Rahmenbedingungen. Ein Modell kann daraus einen ersten Anforderungsentwurf erstellen.

Für das Login-Beispiel wären dies die Authentifizierung, der Endpunkt, die Eingabefelder sowie Erfolgs- und Fehlerfälle. Mit der Implementierung muss an dieser Stelle noch niemand beginnen.

2. Anforderungen prüfen und freigeben

Das Team prüft, ob der Entwurf tatsächlich das gewünschte System beschreibt. Die Prüfung umfasst fehlende Fälle, eingefügte Annahmen und mehrdeutige Begriffe.

Unklarheiten werden hier korrigiert. Anschließend werden die Anforderungen freigegeben. Damit steht die Grundlage für die weitere Arbeit.

3. Einen technischen Entwurf erstellen

Aus den freigegebenen Anforderungen entsteht ein Entwurfsdokument. Es beschreibt, wie die Funktion umgesetzt werden soll, und zerlegt die Arbeit in konkrete Aufgaben.

Auch diesen Entwurf kann ein LLM vorbereiten. Bevor daraus Code entsteht, wird die vorgeschlagene Umsetzung geprüft. Falls eine Bibliothek oder eine technische Lösung ungeeignet ist, lässt sich der Entwurf noch ändern.

4. Aufgaben umsetzen lassen

Nach der Freigabe des Entwurfs kann ein KI-Agent die Implementierung übernehmen. Er arbeitet auf Basis der vereinbarten Anforderungen und der daraus abgeleiteten Aufgaben.

Bei weiterem Klärungsbedarf geht die Arbeit zurück in die Anforderungs- oder Entwurfsphase. Das Team kann die offene Entscheidung dort dokumentieren und prüfen.

5. Tests, Qualitätssicherung und Dokumentation durchführen

Die Spezifikation liefert die Grundlage für Testfälle und die Prüfung des Ergebnisses. Auch die Dokumentation orientiert sich an denselben Anforderungen.

Ein Agent kann Code schreiben und Tests ausführen. Die Ergebnisse müssen trotzdem mit den freigegebenen Vorgaben abgeglichen werden. Das Team sollte außerdem festlegen, welche Änderungen und Ausführungsschritte der Agent selbstständig vornehmen darf.

6. Bereitstellen und weiter pflegen

Zum Entwicklungsprozess gehören auch die Übergänge von der Entwicklungsumgebung über Staging bis zur Produktion sowie die anschließende Wartung.

Ändert sich eine Anforderung, sollte diese Änderung wieder in die Spezifikation einfließen. Anschließend lassen sich Entwurf, Implementierung und Tests daran ausrichten. Andernfalls verliert das zentrale Arbeitsdokument nach und nach seinen Bezug zum tatsächlichen System.

Spec-Driven Development und Vibe Coding im Vergleich

Im hier betrachteten Vibe-Coding-Ablauf beginnt die Arbeit mit einer direkten Aufforderung an einen Coding-Agenten. Dieser erzeugt Code. Danach folgen Rückmeldungen und weitere Änderungen, bis das Ergebnis den Erwartungen entspricht. Der Vergleich beschreibt zwei mögliche Arbeitsweisen; Teams können sie je nach Aufgabe kombinieren.

Für Experimente und erste Prototypen kann das praktisch sein. Eine Idee wird schnell greifbar, und Anpassungen lassen sich direkt ausprobieren.

Die Schwierigkeit liegt in den vielen möglichen Interpretationen. Derselbe allgemeine Auftrag kann unterschiedliche Lösungen hervorbringen. Bei einer Login-Funktion betrifft das beispielsweise die Schnittstelle, die Bibliothek oder die Behandlung von Fehlern.

Eine Spezifikation verringert Mehrdeutigkeit. Sie garantiert weder identischen Code bei jedem Durchlauf noch eine fehlerfreie Umsetzung. Der Spielraum für ungeklärte Produktentscheidungen wird jedoch kleiner.

Spec-Driven Development, TDD und klassische Entwicklung

Beim Test-Driven Development, kurz TDD, wird für den nächsten kleinen Funktionsschritt zuerst ein Test geschrieben. Danach folgt der Code, der ihn erfüllt, und anschließend das Refactoring. Kent Beck beschreibt diesen Ablauf in „Canon TDD“.

Spec-Driven Development setzt eine Ebene früher an: Anforderungen und Entwurf liefern die Grundlage, aus der auch Tests entstehen können. Beide Ansätze lassen sich deshalb gemeinsam nutzen.

Auch Planung und Anforderungsdokumente gehören längst zur klassischen Softwareentwicklung. Spec-Driven Development rückt die Spezifikation als steuerndes Dokument für die KI-gestützte Umsetzung in den Mittelpunkt.

In einem codezentrierten Ablauf kann Dokumentation erst nach der Implementierung ergänzt werden. Bei einem spezifikationsgetriebenen Ablauf liegt die vereinbarte Beschreibung bereits vor, wenn die Codeerzeugung beginnt.

Häufige Fehler beim Spec Coding

Unklare Anforderungen ausführlich formulieren

„Die Anmeldung soll zuverlässig und benutzerfreundlich sein“ bleibt auch mit zusätzlichen Absätzen schwer überprüfbar. Konkrete Eingaben, Ergebnisse und Fehlerfälle geben dem Agenten mehr Orientierung.

Den Entwurf ungeprüft übernehmen

Ein sauber gegliedertes Dokument kann falsche Annahmen enthalten. Anforderungen und technische Lösung brauchen jeweils eine Prüfung, bevor die nächste Phase startet.

Offene Punkte durch den Agenten entscheiden lassen

Fehlt eine Vorgabe, kann das Modell eine plausible Lösung wählen. Diese muss nicht zur Anwendung passen. Offene Fragen sollten sichtbar bleiben und bewusst geklärt werden.

Nur den Erfolgsfall beschreiben

Im Login-Beispiel reicht der Status für gültige Zugangsdaten allein kaum aus. Fehlende Angaben brauchen ebenfalls ein definiertes Verhalten. Die Fehlerbehandlung bleibt sonst interpretationsbedürftig.

Die Spezifikation nach Änderungen liegen lassen

Wer nur den Code aktualisiert, arbeitet irgendwann mit zwei unterschiedlichen Beschreibungen des Systems. Anforderungen, Umsetzung und Tests sollten bei Änderungen gemeinsam überprüft werden.

Ein sinnvoller Einstieg: Eine Funktion sauber durchziehen

Für den ersten Versuch eignet sich eine klar abgegrenzte Funktion. Dafür werden Verhalten und Rahmenbedingungen beschrieben, offene Fragen geklärt und die Anforderungen freigegeben. Danach folgen Entwurf, Aufgaben, Implementierung und Prüfung.

Vor dem Start der Codeerzeugung hilft diese kurze Checkliste:

• Das gewünschte Verhalten ist konkret beschrieben.
• Eingaben und erwartete Ergebnisse sind festgelegt.
• Relevante Fehlerfälle sind geklärt.
• Technische Vorgaben sind ausdrücklich dokumentiert.
• Anforderungen und Entwurf sind geprüft.
• Überprüfbare Testfälle lassen sich daraus ableiten.

Spec-Driven Development verlagert einen Teil der Arbeit an den Anfang. Das braucht Aufmerksamkeit, bevor der erste Code entsteht. Dafür erhält der KI-Agent einen klareren Auftrag, und das Team hat eine belastbare Grundlage für die Prüfung. Das Team kann Abweichungen zwischen Anforderung und Umsetzung gezielt benennen.