Spec-Driven Development: Vom Programmierer zum Systemarchitekten

KI-Agenten entwickeln sich vom Coding-Assistenten zum eigenständigen Akteur in der Softwareentwicklung. Mit Spec-Driven Development (kurz SDD) entsteht ein neuer Ansatz, der KI systematisch steuert – und die Rolle von Entwicklern grundlegend verändert: weg vom Coding, hin zu Architektur, Spezifikation und Orchestrierung.

KI ist längst mehr als nur ein Autocomplete-Assistent. KI-Agenten übernehmen zunehmend ganze Arbeitspakete und entwickeln sich so zu einem aktiven Bestandteil des gesamten Softwareentwicklungsprozesses – der Agent plant, entwirft, implementiert und verfolgt dabei den eigenen Fortschritt. Doch je mehr sich KI vom „Helfer“ zum „Agenten“ entwickelt, desto stärker muss sich auch unsere Art, Software zu erstellen, verändern. 

Ein vielversprechender Ansatz in diesem Wandel ist die spezifikationsgetriebene Entwicklung (Spec-Driven Development). Dieser Artikel beleuchtet, was Spec-Driven Development bedeutet, wie es funktioniert und was sich dadurch für Entwickler verändert.

Die verwendeten Dokumente orientieren sich an den Artefakten klassischer Softwareentwicklungsprozesse, die bei SDD in der Regel als Markdown-Dokumente geführt werden.

• Anforderungsspezifikation 
  Die Anforderungsspezifikation beschreibt, was das System tun soll. Sie wird auch als Lastenheft bezeichnet und beschreibt:
  • Features
  • Use-Cases
  • Verhaltensweisen
  • Akzeptanzkriterien
  • Abgrenzungen
     
• Technische Spezifikation 
  Die technische Spezifikation beschreibt, wie das System umgesetzt werden soll. Sie wird auch als Pflichtenheft bezeichnet und enthält:
  • Architektur & Systemdesign
  • Technologieentscheidungen
  • Datenmodelle
  • APIs
  • Detaillierte Umsetzung der Anforderungen aus dem Lastenheft
     
• Arbeitspakete
  Die technische Spezifikation wird dann typischerweise in Implementierungsaufgaben zerlegt, die vom KI-Agenten umgesetzt werden sollen.

Dies mag auf den ersten Blick an das klassische Wasserfallmodell erinnern. Der entscheidende Unterschied ist jedoch: Der Prozess ist nicht auf das gesamte System ausgelegt, sondern wird gezielt auf einzelne Features angewendet – gewissermaßen als ein Wasserfallprozess im Kleinen auf Feature-Ebene.

Neben den klassischen Spezifikationsdokumenten gibt es in Spec-Driven-Development-Tools in der Regel zusätzliche Steuerungsoptionen über separate Dokumente mit allgemeinen Regeln und Rahmenbedingungen – also eine Art Dokumentation der Systemleitlinien. Während die Spezifikationsdokumente für einzelne Changes oder Features erstellt werden, gelten diese Instruktionen für alle Anpassungen. Festlegungen können sein:

• Nicht-funktionale Anforderungen (Performance, Sicherheit, Zuverlässigkeit)
• Grundsätzliche Architekturentscheidungen
• Festgelegter Technologiestack
• Testvorgehen
• Coding-Konventionen
• aber auch Regeln zu Format, Umfang und Qualität der Spezifikationen selbst

Achtung: In der Regel verfügen KI-Agenten über ähnliche Mechanismen (beispielsweise die copilot-instructions.md oder der sich etablierende AGENTS.md-Standard). Es ist sinnvoll, diese Dateien aufeinander zu verweisen, um die systemweiten Regeln nur einmal zu pflegen und Redundanzen zu vermeiden.

Für die praktische Umsetzung von Spec-Driven Development existiert inzwischen eine wachsende Zahl spezialisierter Werkzeuge. Sie unterscheiden sich vor allem hinsichtlich Workflow, Anpassbarkeit und dem Umgang mit langlebigen Spezifikationen. Zu den bekanntesten Vertretern zählen GitHub Spec Kit und OpenSpec.

GitHub Spec Kit

Ein mögliches Tool für Spec-Driven-Development ist GitHub Spec Kit. Es wird von GitHub entwickelt, ist aber nicht nur mit dem hauseigenen, sondern mit einer Vielzahl von Coding Agents nutzbar. 

Ein Python-Kommandozeilentool namens „specify“ initialisiert Spec Kit in einem Projekt, indem es bestimmte vordefinierte Prompts (sog. Slash Commands) sowie Vorlagen und einige Skripte im Projektverzeichnis ablegt.

Die systemweiten Instruktionen heißen bei Spec Kit „Constitution“, was die Unverhandelbarkeit signalisieren soll. Man wird initial über /speckit.constitution bei der Anlage unterstützt.

Die Hauptkommandos zur Abbildung des SDD-Workflows sind:

• /speckit.specify zur Erstellung der fachlichen Spezifikation.
  Optional kann dabei /speckit.clarify verwendet werden, um Unklarheiten in Interviews zu beseitigen.
• /speckit.plan zur Erstellung der technischen Spezifikation
• /speckit.tasks um die technische Spezifikation in Aufgaben herunterzubrechen
• /speckit.implement um die Umsetzung zu starten

Spec Kit ist sehr gut mit GitHub Copilot integriert, indem es z. B. mögliche Antworten auf Fragen mit dem „Ask Questions“-Tool als Schaltflächen darstellt.

Bei Spec Kit werden die Spezifikationen zwar zusammen mit dem Quellcode versioniert, sie spiegeln aber immer nur das Delta zum vorherigen Systemzustand wider, sodass keine Gesamtspezifikation des Systems entsteht. Spec Kit folgt daher nur dem „Spec-First“-Ansatz.

Zuletzt gab es zudem Diskussionen, ob das Tool nach dem Wechsel eines der Hauptentwickler von Microsoft zu Anthropic, noch genug Weiterentwicklung erfahren wird.

 

OpenSpec

Eine Alternative stellt das Tool OpenSpec dar. Auch dieses ist mit diversen Coding Agents nutzbar und wird ähnlich wie bei Spec Kit über eine CLI initialisiert, die in diesem Fall als NPM-Paket installiert wird.

Die systemweiten Instruktionen werden bei OpenSpec in der config.yaml abgelegt. Diese bietet bereits ein vordefiniertes Format, um den grundsätzlichen Systemkontext von Regeln für die einzelnen Dokumentationsartefakte abzugrenzen. 

OpenSpec bietet unterschiedliche Workflows (Quick Path und Expanded) an, die sich hauptsächlich dadurch unterscheiden, ob die Spezifikationsdokumente alle gemeinsam in einem Schritt erstellt werden oder dies in separaten Schritten geschieht. Letzteres hat den Vorteil, dass z. B. die technische Spezifikation geprüft werden kann, bevor daraus die Arbeitspakete erzeugt werden. 

OpenSpec unterstützt zudem die Definition eigener Schemata, über die der Workflow und die verwendeten Spezifikationsartefakte komplett anpassbar sind.

Die wichtigsten OpenSpec-Kommandos sind:

• /ospx:explore als optionaler Schritt zur Verfeinerung der Spezifikationen durch ein Interview.
• /ospx:propose als Bestandteil des „Quick Paths“, der alle Spezifikationsdokumente in einem Schritt erzeugt. Alternativ verwendet man /ospx:new zur Anlage des Changes und dann /ospx:continue pro Artefakt.
• /ospx:apply startet die Umsetzung
• OpenSpec trennt Changes (= vorgeschlagene Änderungen) von Specs (= wie das System aktuell funktioniert). /ospx:archive integriert die Change-Spezifikation in die Systemspezifikation und schließt den Change ab. 

Der Abgleich von Changes und Specs lässt eine langlebige Systemdokumentation entstehen. OpenSpec ist daher „Spec-Anchored“.

Weitere SDD-Werkzeuge

Neben den genannten Lösungen existieren diverse weitere Anbieter wie z. B. Kiro, Tessl und BMAD. Eine umfassende Evaluation jedes neu aufkommenden Tools gestaltet sich jedoch anspruchsvoll, da hierfür vergleichbare, nicht triviale Anwendungsfälle und Erfahrungen über mehrere Iterationszyklen hinweg erforderlich sind.

Stattdessen empfiehlt es sich, die verfügbaren Frameworks anhand der definierten Kategorien einzuordnen und ihre Workflows und Anpassbarkeit zu vergleichen. Ein fokussierter Ansatz – das heißt, die Auswahl und tiefgehende Beherrschung weniger geeigneter Werkzeuge – ist dabei zielführender als die kontinuierliche Bewertung aller neuen Marktteilnehmer.

Entscheidend ist die Auswahl eines flexiblen Frameworks, das gut zu den eigenen Anforderungen passt, sowie dessen gezielte Optimierung und Anpassung an unternehmens- und projektspezifische Prozesse. Hierzu zählt zum Beispiel die Integration in bestehende Systeme wie Ticketsysteme, Versionskontrolle und Wissensdatenbanken, die Anpassung der Spezifikationsartefakte an die eigenen Standards sowie die Definition geeigneter Instruktionen und Rahmenbedingungen, die es dem Agenten ermöglichen, Änderungen eigenständig zu validieren und durch automatisierte Tests abzusichern.

Eine zentrale Frage ist, wie viel Spezifikation tatsächlich notwendig ist – denn die verschiedenen SDD-Tools unterscheiden sich hier teils erheblich.

Die folgende Grafik stellt die „Lines of Spec“ (also die Anzahl der Zeilen in den Markdown-Spezifikationen) den „Lines of Code“ gegenüber, die zur Umsetzung eines Features entstehen. Ist die Spezifikation für ein umfangreiches Feature zu knapp, steigt die Wahrscheinlichkeit, dass die Ergebnisse nicht den Erwartungen entsprechen. Ist sie hingegen zu ausführlich, werden Reviews allein durch die schiere Menge an zu lesendem und zu validierendem Inhalt ineffizient. 

Unabhängig von konkreten Methoden und Werkzeugen wird deutlich, dass KI-gestützte Softwareentwicklung und Spec-Driven Development Entwickler nicht ersetzen, sondern ihren Fokus verschieben und das Aufgabenfeld nachhaltig erweitern, wodurch sich die Entwicklerrolle grundlegend neu definiert:

• Der Fokus rückt zunehmend ab vom reinen Schreiben von Code und hin zur Strukturierung von Problemen.
• Planung und systematische Spezifikationen rücken in den Fokus, um die Arbeit von Coding-Agenten effektiv zu steuern und zu parallelisieren.
• Architekturentscheidungen und eine präzise Orchestrierung der KI gewinnen an Bedeutung, da Modelle häufig zu „klassischen“ Lösungsansätzen neigen – einfach, weil diese den Großteil der Trainingsdaten prägen, selbst wenn inzwischen modernere Alternativen verfügbar sind.
• Gleichzeitig verlagert sich der Schwerpunkt zunehmend auf Review und Qualitätssicherung, da mit wachsender Unterstützung durch automatisierte oder KI-gestützte Implementierung die sorgfältige Prüfung von Spezifikationen und generiertem Code, das frühzeitige Erkennen von Inkonsistenzen sowie die Sicherstellung fachlicher und technischer Anforderungen immer stärker den Mittelpunkt der Entwicklungsarbeit prägen.
   

Viele dieser Aufgaben lagen bisher vor allem bei erfahrenen Entwicklern. Künftig werden auch Junioren diese Fähigkeiten wesentlich früher aufbauen müssen, während erfahrene Entwickler verstärkt in die Rolle von Mentoren und Qualitätswächtern für die gesamte Systemarchitektur hineinwachsen.

Gleichzeitig wird Experimentieren deutlich einfacher. Wo früher lange diskutiert wurde, um vor der aufwendigen Umsetzung die optimale Lösung zu finden, lassen sich heute verschiedene Ansätze schnell und unkompliziert ausprobieren und verschiebt die Debatte von der Theorie in die Praxis.

So viel Potenzial diese neue Arbeitsweise auch bietet, geht sie doch unweigerlich mit einer Reihe neuer Herausforderungen einher, die sowohl technische als auch organisatorische Aspekte betreffen und für die es bislang nur teilweise erprobte Lösungsansätze gibt.

• Wie lässt sich die stetig wachsende Menge an Spezifikationen und generiertem Code effizient und zuverlässig validieren?
• Wenn Entwickler selbst nur noch wenig oder gar keinen Code schreiben, wie können sie ihre Programmierkompetenz auf einem Niveau halten, das es ihnen erlaubt, die Arbeit von KI-Agenten fundiert zu steuern und zu bewerten?
• Wie und von wem werden Programmiersprachen und Frameworks künftig weiterentwickelt, wenn ihre primären Nutzer zunehmend KI-Systeme sind?
• Wie sollte die Ausbildung der nächsten Generation von Softwareentwicklern gestaltet werden, und welche Kompetenzen müssen dabei künftig im Mittelpunkt stehen?

All dies sind Fragestellungen, mit denen wir uns aktiv auseinandersetzen – und für deren Beantwortung unsere Branche eine gemeinsame Verantwortung trägt.