Spec Driven Development gewinnt im Kontext von KI gestützter Softwareentwicklung stark an Bedeutung. Wenn ich mir jedoch anschaue, was konkret darunter verstanden wird, erkenne ich mindestens zwei sehr unterschiedliche Interpretationen. Beide verwenden den Begriff Spezifikation. Beide integrieren KI tief in den Entwicklungsprozess. Und dennoch optimieren sie für sehr unterschiedliche Ziele.

In den letzten Monaten habe ich intensiv über diese Unterscheidung nachgedacht, weil sie aus meiner Sicht einen fundamentalen Einfluss darauf hat, wie wir Systeme bauen.

Die task-getriebene Interpretation

Eine Ausprägung von Spec Driven Development ist aus meiner Sicht stark task-getrieben und entwicklerzentriert. Werkzeuge wie Kiro oder Spec-Kit stehen exemplarisch für diese Richtung. Der typische Ablauf beginnt mit einer Feature-Beschreibung. Daraus wird eine Spezifikation generiert, in Tasks zerlegt und anschliessend mithilfe von KI in Code übersetzt.

In diesem Modell fungiert die Spezifikation als strukturiertes Zwischenartefakt zwischen Idee und Implementierung. Ihr Hauptzweck ist es, Automatisierung zu verbessern. Das Zentrum ist der Entwickler und das primäre Ziel ist Beschleunigung. Die zentrale Frage lautet: Wie kommen wir möglichst effizient von einer Idee zu lauffähigem Code?

Daran ist grundsätzlich nichts falsch. Für Prototypen, interne Tools oder klar abgegrenzte Features kann dieser Ansatz sehr wirkungsvoll sein. KI ist besonders stark darin, technische Aufgaben zu zerlegen und konsistent Code zu generieren.

Aus meiner Erfahrung heraus entsteht die Spezifikation hier jedoch häufig aus der Implementierungsperspektive. Sie beschreibt in technischen Begriffen, was gebaut werden soll. Sie ist eng mit Tasks, Komponenten und Code-Strukturen verknüpft. Dadurch verschwimmt die Grenze zwischen Problemraum und Lösungsraum sehr früh im Prozess.

Bei einfachen Systemen mag das keine grosse Rolle spielen. Bei langlebigen, komplexen Systemen mit mehreren Stakeholdern hingegen sehr wohl.

Die stakeholder-zentrierte Interpretation

Die andere Ausprägung setzt an einem ganz anderen Punkt an. Sie beginnt nicht mit Features oder Tasks, sondern mit System Use Cases. Diese beschreiben die Interaktion zwischen Akteuren und dem System auf Verhaltensebene. Im Fokus stehen beobachtbare Ergebnisse und nicht die technische Zerlegung.

In diesem Ansatz ist die Spezifikation kein Hilfsartefakt zur Code-Generierung, sondern das zentrale Artefakt des Projekts. Sie repräsentiert ein gemeinsames Verständnis zwischen Stakeholdern und Entwicklungsteam. Sie hält die Intention fest, bevor Implementierungsentscheidungen getroffen werden.

Der Ablauf fühlt sich daher grundlegend anders an. Er führt von der Vision zu Anforderungen, von Anforderungen zu System Use Cases, weiter zum Entitätsmodell und zu nicht funktionalen Rahmenbedingungen. Erst wenn diese Artefakte stabil sind, beginnt die Implementierung.

KI spielt auch hier eine wichtige Rolle. Aber ihre Rolle ist eine andere. Sie arbeitet innerhalb klar definierter Artefakte. Das Gedächtnis des Projekts liegt nicht im Kontextfenster eines Modells, sondern in versionierter Dokumentation. KI wird zu einem leistungsfähigen Umsetzungshelfer, aber nicht zur Quelle der Wahrheit.

Der AI Unified Process (AIUP) verfolgt genau diesen Ansatz.

Worauf ich Wert lege

Meine Präferenz liegt klar bei der stakeholder-zentrierten Variante.

Die meisten Systeme, an denen ich arbeite, sind keine kurzlebigen Experimente. Es sind geschäftskritische Anwendungen, oft in der öffentlichen Verwaltung oder im ERP Umfeld. Sie entwickeln sich über viele Jahre hinweg weiter, häufig über mehrere Teams und Generationen von Entwicklern hinweg. In solchen Umfeldern ist fehlende Ausrichtung zwischen Stakeholdern und Implementierung deutlich teurer als langsame Code Generierung.

Task-getriebene Workflows optimieren Entwicklergeschwindigkeit. Stakeholder-zentrierte Workflows optimieren Ausrichtung und Langlebigkeit. Für mich hat Ausrichtung klar Vorrang.

Wenn wir mit Tasks starten, laufen wir Gefahr, sehr effizient das Falsche zu bauen. KI verstärkt dieses Risiko sogar, weil sie jede vorhandene Struktur potenziert. Eine vage oder technisch geprägte Spezifikation führt zu grossen Mengen selbstbewusst erzeugten, aber fachlich unpassenden Outputs.

Wenn wir hingegen mit präzisen System Use Cases beginnen, wird KI zum Verstärker von Klarheit statt von Verwirrung. Sie kann Tasks ableiten, Queries vorschlagen, UI Komponenten generieren oder Tests schreiben. All das folgt jedoch aus einer stabilen Beschreibung des Problemraums.

Wie ich das Zusammenspiel sehe

Ich sehe diese beiden Ausprägungen nicht als Gegensätze, die sich ausschliessen. Task-getriebene KI Workflows sind sehr wertvoll, sobald eine solide stakeholder-zentrierte Spezifikation existiert. Wenn System Use Cases klar definiert sind, kann KI hervorragend bei der Ableitung von Implementierungsaufgaben, bei der Code Generierung und bei Refactorings unterstützen.

Der entscheidende Unterschied liegt für mich darin, woher die Richtung kommt. In meiner Sicht sollte sie aus der Systembeschreibung kommen und nicht aus einem Feature Prompt.

Wenn ich von Spec Driven Development spreche, meine ich nicht bessere Prompt Technik. Ich meine das bewusste und dauerhafte Explizitmachen des Problemraums. Ich meine Artefakte, die länger bestehen als eine einzelne KI Session und länger als ein einzelner Entwickler.

KI ist ein aussergewöhnlich starkes Werkzeug. Aber sie sollte innerhalb einer klar definierten Spezifikation arbeiten, die die Intention der Stakeholder widerspiegelt. Sie sollte diese Intention nicht selbst festlegen.

Deshalb verstehe ich unter Spec Driven Development die stakeholder-zentrierte Variante. Nicht weil die andere falsch wäre, sondern weil sie für die Art von Systemen, die ich baue, nicht ausreicht.