Das nächste Konzept aus meinem tool-agnostischen KI-Coding-Briefing ist spezifikationsgetriebene Entwicklung. Für mich ist es die wichtigste Antwort auf eine sehr praktische Beobachtung: KI kann erstaunlich viel bauen, aber sie baut nicht automatisch das Richtige, wenn wir das Richtige nicht sauber beschrieben haben.
Viele KI-Coding-Anfragen klingen zunächst harmlos: „Bau mir eine Login-Seite“, „ergänze Passwort zurücksetzen“, „mach die Suche schneller“. Für ein menschliches Team sind solche Sätze oft nur Gesprächseinstieg. Für einen Coding-Agenten sind sie aber schnell ein Arbeitsauftrag. Wenn der Auftrag unterspezifiziert ist, füllt das Modell die Lücken mit plausiblen Annahmen. Und genau dort entstehen die späteren Korrekturschleifen.
Spezifikationsgetriebene Entwicklung dreht diese Reihenfolge um. Die KI wird nicht mit einem Wunsch gefüttert, sondern mit einem kleinen, prüfbaren Vertrag: Ziel, Nicht-Ziel, Nutzer, Trigger, Datenmodell, Verhalten, Fehlerfälle, Schnittstellen, Akzeptanzkriterien und Rückfallplan. Erst dann wird implementiert.
Warum Prompts allein nicht reichen
Ein Prompt beschreibt eine Aufgabe. Eine Spezifikation beschreibt einen Arbeitsvertrag. Das klingt wie ein kleiner Unterschied, ist aber in KI-gestützter Softwareentwicklung entscheidend.
Ein Prompt kann freundlich, ausführlich und sogar technisch klingen und trotzdem wichtige Dinge offenlassen: Was passiert bei ungültigen Eingaben? Welche Zustände gibt es? Welche Schnittstellen dürfen verändert werden? Welche Daten müssen auditierbar sein? Welche Fehlermeldung ist sicher? Was ist ausdrücklich nicht Teil der Aufgabe?
Ein menschlicher Entwickler würde vieles davon in Rückfragen klären. Ein Agent versucht häufig, weiterzukommen. Das ist seine Stärke und seine Gefahr zugleich. Spezifikationsgetriebene Entwicklung gibt dem Agenten die Klarheit, die er für sinnvolle Autonomie braucht.
Meine Kurzform: Ein guter Prompt sagt, was ich will. Eine gute Spezifikation sagt auch, woran wir erkennen, dass es richtig ist.
Was in eine produktive Spezifikation gehört
Eine produktive Spezifikation muss nicht lang sein. Sie muss die richtigen Lücken schließen. Aus meiner Praxis reichen für viele Features sieben Bestandteile.
Der SDD-Workflow
Der praktische Workflow ist einfach und gerade deshalb stark: Spec entwerfen, von der KI auf Lücken prüfen lassen, Spec finalisieren, Code und Tests erzeugen, Akzeptanz prüfen.
Der wichtigste Schritt ist dabei oft nicht die Implementierung, sondern die Lückenanalyse. Ich lasse die KI vor dem Coding bewusst fragen: Was ist hier noch unklar? Welche Fehlerfälle fehlen? Welche Annahmen würdest du treffen? Welche Akzeptanzkriterien sind nicht testbar?
Das fühlt sich zunächst langsamer an. In Wirklichkeit verschiebt es die Korrekturschleifen nach vorne, an einen Ort, an dem sie billig sind. Eine fehlende Regel in einer Spec zu ergänzen dauert Sekunden. Dieselbe fehlende Regel nach drei Implementierungsversuchen wiederzufinden, kostet Zeit, Nerven und Vertrauen.
Ein Beispiel: Passwort zurücksetzen
Nehmen wir eine typische Funktion: Passwort zurücksetzen. Eine schwache Anfrage wäre: „Bau Passwort zurücksetzen ein.“ Ein Agent kann damit loslaufen, aber er muss viele Dinge selbst erfinden.
Eine produktive Spec wäre deutlich konkreter: Nutzer mit verifizierter E-Mail können ihr Passwort über einen Single-Use-Token zurücksetzen. Nicht im Scope ist Account-Wiederherstellung ohne E-Mail-Zugriff. Das Datenmodell enthält einen ResetToken mit Nutzerbezug, Token-Hash, Ablaufzeit und Nutzungszeitpunkt. Der Hauptpfad lautet: Anforderung, E-Mail mit Link, neues Passwort setzen, Token invalidieren.
Wichtiger sind fast die Fehlerpfade: abgelaufener Token, bereits verwendeter Token, unbekannte E-Mail mit gleicher Antwort wie beim Erfolg, damit keine Account-Enumeration entsteht. Akzeptanz heißt nicht „sieht gut aus“, sondern: Integrationstest für Erfolg, abgelaufenen Token und doppelt eingelösten Token; Audit-Log pro Versuch; Feature-Flag, das in unter einer Minute ohne Deploy deaktivierbar ist.
Mit so einer Spezifikation erzeugen viele Coding-Agenten in einem Lauf eine deutlich brauchbarere Lösung. Ohne sie entstehen oft drei Varianten: eine vergisst die Sicherheit, eine vergisst den Test, eine vergisst die Produktkante.
Warum Akzeptanzkriterien der eigentliche Hebel sind
Akzeptanzkriterien sind der Teil der Spezifikation, der aus Meinung Überprüfung macht. Sie sind die Brücke zwischen Fachlichkeit und Tests.
Das ist auch der Grund, warum sich Spec-Driven Development gut mit etablierten Praktiken wie Gherkin, Behavior-Driven Development oder Issue-Templates verträgt. Formate wie „Given, When, Then“ sind nicht deshalb nützlich, weil sie hübsch aussehen, sondern weil sie Verhalten, Trigger und erwartetes Ergebnis disziplinieren.
Für KI-Coding ist das Gold wert. Ein Agent kann gegen Akzeptanzkriterien implementieren, Tests generieren, fehlende Fälle markieren und am Ende erklären, welche Kriterien erfüllt sind. Aus einem offenen Wunsch wird ein prüfbarer Arbeitsgegenstand.
Der Aufwand sitzt vorne, spart aber hinten
Ohne Spec ist der Start schnell, aber der Weg danach oft unruhig. Mit informeller Beschreibung ist es besser, aber viele Details bleiben implizit. Mit vollständiger Spec investiert man vorne vielleicht 15 bis 30 Minuten, reduziert dafür aber Korrekturrunden massiv.
Das klingt wie klassisches Requirements Engineering, und genau das ist es teilweise auch. Der Unterschied ist nur: Im KI-Coding ist die Rückkopplung schneller. Eine gute Spec ist nicht ein Dokument, das monatelang im Regal liegt. Sie ist ein direkt nutzbarer Input für Agenten, Tests und Reviews.
Was reife Teams anders machen
Reife Teams behandeln Spezifikationen als lebende Artefakte. Eine Spec entsteht nicht nebenbei im Chat und verschwindet danach. Sie wird versioniert, in Pull Requests referenziert, als Review-Grundlage genutzt und nach der Implementierung an die Realität angepasst.
Das heißt nicht, dass jede Kleinigkeit eine große Spezifikation braucht. Aber sobald ein Feature mehrere Zustände, Fehlerpfade, Schnittstellen oder Sicherheitsrisiken hat, wird eine Spec zur günstigsten Form von Klarheit.
Besonders wichtig finde ich den Schritt „what is unspecified?“. Bevor ein Agent Code schreibt, soll er die Spezifikation angreifen: Welche Annahmen sind versteckt? Welche Daten fehlen? Welche Schnittstelle ist unklar? Welche Testfälle werden später Streit erzeugen? Diese Kritik ist keine Verzögerung, sondern Qualitätssicherung vor dem teuersten Schritt.
Meine praktische Empfehlung
Ich würde für KI-Coding mit einem sehr knappen Spec-Template starten. Nicht als Bürokratie, sondern als Denkstütze. Eine Seite reicht oft: Ziel, Nicht-Ziel, Nutzer/Trigger, Daten, Verhalten, Fehlerfälle, Schnittstellen, Akzeptanz, Rückfall.
Danach sollte die KI zwei Rollen bekommen: zuerst Reviewer der Spezifikation, dann Implementierer. Diese Trennung ist wichtig. Wenn das Modell sofort baut, optimiert es auf Fortschritt. Wenn es zuerst Lücken suchen soll, optimiert es auf Klarheit.
Im Review würde ich nicht fragen: „Ist der Code gut?“ Ich würde fragen: „Welche Akzeptanzkriterien sind erfüllt, welche nicht, und welche Annahmen wurden getroffen?“ Genau dort wird Spec-Driven Development im Alltag wirksam.
Fazit
Spezifikationsgetriebene Entwicklung ist kein Rückfall in schwerfällige Wasserfall-Dokumentation. Es ist die Antwort auf eine neue Realität: Coding-Agenten können sehr schnell handeln. Deshalb müssen wir sehr klar sagen, worauf sie handeln sollen.
Für mich ist SDD einer der wichtigsten Hebel im professionellen KI-Coding. Es verlagert die anspruchsvolle Arbeit nach vorne, dorthin, wo menschliche Klarheit den größten Effekt hat. Die KI bekommt weniger Raum zum Raten und mehr Raum zum Umsetzen. Genau so sollte es sein.
Weiterführende Quellen
- GitHub Spec Kit als Open-Source-Toolkit für spezifikationsgetriebene Entwicklung.
- GitHub Blog: Spec-driven development with AI zur Idee, erst Intention und Akzeptanz zu schärfen und dann zu implementieren.
- Cucumber Gherkin Reference als etablierter Ansatz, Verhalten und Akzeptanzkriterien strukturiert zu formulieren.
- Microsoft Learn: Define features and epics zur strukturierten Beschreibung von Arbeit in Azure DevOps.
- GitHub Docs: About issues als Grundlage für nachvollziehbare Arbeitsgegenstände, Diskussionen und Akzeptanzkontext.