Die letzte große Abstraktion?
Die Geschichte der IT ist auch eine Geschichte der Abstraktion. Betriebssysteme und Treiber abstrahierten Hardware wie Speicher und Prozessoren, Programmiersprachen abstrahierten Bits und Bytes. Mit virtuellen Laufzeitumgebungen wie der JVM wurden Speicherbereiche und Pointer für viele Entwicklerinnen und Entwickler im Alltag weitgehend irrelevant, auch wenn sie technisch natürlich nie verschwunden sind.
Die Cloud abstrahiert das Rechenzentrum, Frameworks abstrahieren Infrastruktur, Integrationsdetails und wiederkehrende technische Muster. Über Jahrzehnte war die Stoßrichtung dabei erstaunlich konsistent: Wir bewegen uns schrittweise weg von der Maschine und hin zu einer Beschreibung dessen, was wir eigentlich erreichen wollen.
Und genau deshalb ist die aktuelle Entwicklung rund um generative KI so spannend. Denn erstmals steht nicht nur die nächste Abstraktionsschicht zur Debatte, sondern auch das Medium, in dem wir Software beschreiben. Natürliche Sprache wird nicht mehr nur zur Erklärung von Software genutzt, sondern zunehmend zu ihrem Ausgangspunkt: für Anforderungen, Architekturentscheidungen, Task-Zerlegung und Implementierungsvorschläge.
Damit verschiebt sich die eigentliche Frage. Es geht nicht mehr nur darum, ob KI Programmiersprachen teilweise abstrahiert — das passiert längst. Spannender ist, was an ihre Stelle tritt. Wenn Spezifikationen in natürlicher Sprache zum zentralen Steuerungsartefakt werden, dann entscheidet ihre Qualität zunehmend darüber, ob KI-gestützte Entwicklung kontrollierbar, nachvollziehbar und verantwortbar bleibt.
Weniger Vibe, mehr Verfahren
Wirklich seriös kann diese Frage derzeit niemand abschließend beantworten. Zwischen überdrehten Zukunftsvisionen und demonstrativer Nüchternheit ist aktuell fast alles vertreten. Die einen träumen bereits von autonomen KI-Agenten, die rund um die Uhr Software erzeugen und sich nebenbei vom Handy aus steuern lassen (und ja — es macht Spaß, Claude vom Handy zu steuern!). Die anderen warnen, dass KI immer größere Mengen an Code produziert und damit die Kluft zwischen dem entstehenden Softwaresystem und dem menschlichen Verständnis dafür weiter wächst. Thoughtworks spricht in diesem Zusammenhang von „cognitive debt”.
Genau in diesem Spannungsfeld taucht Spec-Driven Development auf. Nicht als sauber normierter Standard, nicht als klar abgegrenzte Methode und schon gar nicht als ausgereiftes Zielbild. Eher als Sammlung ähnlicher, neu entstehender Ideen und Verfahren. Der gemeinsame Kern vieler dieser Ansätze ist schnell beschrieben: Nicht der Prompt, nicht der generierte Code und auch nicht das Bauchgefühl des Entwicklers sollen im Zentrum stehen, sondern die Spezifikation.
Spec-Driven Development versucht, die Spezifikation zum eigentlichen Steuerungsartefakt der Softwareentwicklung zu machen. Sie beschreibt nicht nur grob, was gebaut werden soll, sondern dient als Start- und Referenzpunkt für Planung, Zerlegung, Implementierung und Abnahme. Die Spezifikation wird damit zur fachlichen und prozessualen Single Source of Truth.
Die Begriffsgrenzen sind dabei aktuell noch erstaunlich unscharf. Eine verbindliche Definition von Spec-Driven Development hat sich bislang nicht etabliert. Birgitta Böckeler beschreibt in ihrem vielbeachteten Beitrag, der für mich aktuell so etwas wie ein Referenzartikel zu SDD ist, genau diese Unschärfe sehr treffend. Letztlich eint die verschiedenen Ansätze aber eine gemeinsame Idee: Anforderungen an ein neues Feature oder System sollen möglichst präzise, nachvollziehbar und qualitätsgesichert in natürlicher Sprache formuliert werden.
Die Idee dahinter ist ebenso eingängig wie attraktiv: Wenn die eigentliche Spezifikation präzise, nachvollziehbar und überprüfbar genug ist, verliert die Implementierung ihre herausgehobene Stellung. Sie wird nicht unwichtig. Aber sie wird stärker zu dem, was sie in einer Welt leistungsfähiger Coding Agents vielleicht zunehmend sein könnte: ein umsetzbares, überprüfbares und in Teilen automatisierbares — Achtung Wortwitz — Implementierungsdetail.
Das ist das eigentliche Versprechen von Spec-Driven Development: weniger Vibe, mehr Verfahren. Weniger Hoffnung darauf, dass ein einzelner Prompt schon irgendwie den richtigen Code hervorbringt. Stattdessen mehr nachvollziehbare Zwischenschritte, mehr explizite Entscheidungen und im besten Fall auch weniger überraschende Halluzinationen im fertigen Ergebnis.
Der Mensch rückt an den Prüftisch
So technisch und zukunftsgewandt viele SDD-Frameworks auch auftreten: Im Kern enthalten sie eine erstaunlich konservative Botschaft. Sie stärken nicht die völlige Autonomie der Maschine, sondern die Rolle des Menschen zwischen den einzelnen Phasen. Der Mensch soll nicht einfach nur den Startknopf drücken und am Ende Code entgegennehmen. Er soll prüfen, schärfen, verwerfen, nachjustieren und freigeben.
Crucially, your role isn’t just to steer. It’s to verify. At each phase, you reflect and refine. Does the spec capture what you actually want to build? Does the plan account for real-world constraints? Are there omissions or edge cases the AI missed?
Die vollständige Einordnung liefert das Spec-Kit-Team auf dem GitHub-Blog.
In diesem Sinne ist Spec-Driven Development für mich nicht nur ein kleiner Schritt zurück auf der Abstraktionsleiter (weg vom reinen Vibe). Es ist zugleich auch ein deutliches Bekenntnis zur Rolle des Menschen als Verifikationsinstanz. Gerade in einer Welt, in der KI immer größere Teile der eigentlichen Umsetzung übernehmen kann, verschiebt sich der menschliche Beitrag. Weg von der manuellen Formulierung jeder einzelnen Anweisung, hin zur Verantwortung für Zielbild, Plausibilität, Randbedingungen und Qualität.
Das klingt erst einmal vernünftig. Vielleicht sogar beruhigend. Die entscheidende Frage ist allerdings, ob diese neue Rolle in der Praxis wirklich so belastbar ist, wie sie auf dem Papier wirkt.
Kontrolle auf dem Papier ist noch keine Kontrolle im Alltag
Genau hier beginnt für mich der wirklich spannende Teil. Denn auf dem Papier klingt das alles ziemlich überzeugend: erst Spezifikation, dann Planung, dann Zerlegung, dann Implementierung, dann Abnahme. Saubere Phasen, explizite Kontrollpunkte. Ein geordneter Entwicklungsprozess statt sich narrativ entwickelnder Prompt-Ketten und zufällig gutem Code.
In meinen eigenen Experimenten mit solchen Ansätzen habe ich allerdings schnell gemerkt, wie fragil dieses Kontrollversprechen in der Praxis werden kann. Nach zwei oder drei Schleifen beginnt man bereits, Spezifikationen nicht mehr wirklich zu lesen, sondern nur noch zu überfliegen. Man kennt den groben Inhalt ja schon. Man glaubt zu wissen, was sich geändert hat. Und man vertraut darauf, dass die Maschine die offensichtlichen Dinge schon richtig gemacht haben wird. Genau an dieser Stelle wird aus formaler Kontrolle sehr schnell ein Ritual.
Natürlich ist das zunächst nur anekdotische Evidenz. Und ja: Ich habe solche Ansätze bislang eher in vergleichsweise einfachen Greenfield-Projekten als in gewachsenen Brownfield-Kontexten erprobt. Trotzdem halte ich die Beobachtung für relevant. Denn wenn wir — und damit meine ich einen Großteil der Entwicklergemeinschaft — schon heute nicht gerade dafür bekannt sind, Dokumentation und Spezifikationen mit besonderer Hingabe zu schreiben, zu pflegen und aufmerksam zu lesen, dann erscheint mir die Vorstellung zumindest gewagt, dass künftig ganze Teams von Softwareentwicklern stundenlang hochkonzentriert Spezifikationen prüfen, Zwischenstände vergleichen und Änderungsdetails sauber nachvollziehen.
Greenfield vs. Brownfield
Greenfield bezeichnet Vorhaben, die auf der grünen Wiese starten — ohne gewachsene Altsysteme, historische Architekturentscheidungen oder schwer durchschaubare Altlasten.
Brownfield meint die Weiterentwicklung bestehender Systeme — oft mit Legacy-Code, technischen Schulden, gewachsenen Abhängigkeiten und organisatorischen Besonderheiten.
Viele neue KI-gestützte Entwicklungsansätze wirken im Greenfield besonders überzeugend. Ob sie sich im Brownfield genauso gut bewähren, ist häufig die eigentliche Bewährungsprobe.
Natürlich ist das bewusst etwas überspitzt. Aber die Zuspitzung trifft einen echten Punkt. Spec-Driven Development löst das Kontrollproblem nicht automatisch dadurch, dass mehr Text, mehr Phasen und mehr explizite Artefakte entstehen. Im Gegenteil: Im schlimmsten Fall verlagert sich die Intransparenz nur. Dann haben wir nicht weniger Black Box, sondern lediglich besser dokumentierte Black Boxes.
Wie sich das in heutigen SDD-Tools konkret niederschlägt, zeigt mein Kollege Daniel Schock in seinem praktischen Vergleich von Spec Kit, Kiro und GSD.
Genau deshalb ist SDD für mich nicht nur eine Frage besserer Tooling-Patterns, sondern auch eine Frage von Arbeitsweise, Disziplin und Organisationsdesign. Wer ernsthaft in diese Richtung gehen will, muss sich nicht nur mit Prompts und Frameworks beschäftigen, sondern auch mit Aufmerksamkeit, Verantwortlichkeit und letztlich mit Change Management. Denn das Berufsbild von Softwareentwicklern verändert sich an dieser Stelle sehr viel grundlegender, als es viele aktuelle Tool-Demos vermuten lassen.
Ist das nicht einfach Wasserfall mit KI?
An dieser Stelle drängt sich ein naheliegender Einwand auf: Haben wir nicht genau das in der Softwareentwicklung schon einmal versucht? Erst sauber spezifizieren, dann planen, dann umsetzen, dann abnehmen? Und sind wir nicht gerade deshalb bei agilen Vorgehensweisen gelandet, weil große Vorab-Spezifikationen in komplexen Softwarevorhaben selten stabil, vollständig oder ausreichend eindeutig waren?
Genau dieser Einwand ist für mich eine der Kernfragen von Spec-Driven Development. Wenn SDD nur bedeutet, am Anfang ein besonders ausführliches Dokument zu schreiben und anschließend zu hoffen, dass ein Coding Agent daraus schon das richtige System baut, dann ist es tatsächlich wenig mehr als Wasserfall mit besserem Tooling. Vielleicht schneller, vielleicht eleganter, aber nicht grundlegend anders.
Interessant wird SDD erst dort, wo Spezifikationen nicht als einmaliges Vorab-Artefakt verstanden werden, sondern als lebendige, versionierte und überprüfbare Arbeitsgrundlage. Eine gute Spezifikation beschreibt dann nicht das ganze System für die nächsten zwölf Monate, sondern den jeweils nächsten sinnvollen Ausschnitt: präzise genug, um Umsetzung und Abnahme zu steuern; klein genug, um überprüfbar zu bleiben; offen genug, um nach Lernen und Feedback fortgeschrieben zu werden.
In diesem Verständnis widerspricht SDD agilen Prinzipien nicht zwingend. Im Gegenteil: Es kann eine Antwort auf ein sehr aktuelles Problem agiler Entwicklung mit KI sein. Wenn Coding Agents immer schneller immer mehr Code erzeugen, dann reicht ein vages „wir iterieren uns schon dahin” nicht mehr aus. Gerade dann brauchen wir explizitere Zwischenergebnisse, klarere Akzeptanzkriterien und bewusstere Entscheidungen darüber, was der Agent eigentlich tun soll.
Trotzdem will ich die Sache nicht schöner reden, als sie sich in meinen ersten Experimenten angefühlt hat. Meine ersten Gehversuche mit SDD waren zäh. Fast ein wenig wie das schlechteste aus beiden Welten: Die Freude, in schnellen Iterationen greifbare Ergebnisse zu bekommen, ging verloren. Gleichzeitig konnte ich mich auch nicht mehr so „schön” wie in der klassischen Softwareentwicklung in ein Problem eindenken und selbst Code schreiben.
Insofern ist SDD für mich aktuell vor allem ein Vernunftthema. Mein Kopf sagt mir, dass es sinnvoll ist, sich vom rein vibe-getriebenen „Wir iterieren das schon, bis es funktioniert” zu lösen. Wenn KI-Agenten uns eine enorme Umsetzungsgeschwindigkeit geben, brauchen wir vermutlich auch mehr Struktur, klarere Qualitätskriterien und bewusstere Kontrollpunkte.
Aber ich will nicht lügen: So wenig Spaß wie in diesen ein bis zwei Tagen mit SDD-Frameworks hat mir Softwareentwicklung selten gemacht.
Vielleicht ist genau das der interessanteste Punkt. Wenn Spec-Driven Development relevant wird, dann nicht, weil es sich heute schon nach der eleganteren, kreativeren oder lustvolleren Art zu entwickeln anfühlt. Sondern weil es eine unbequeme Antwort auf ein reales Problem sein könnte: Wie behalten wir fachliche Kontrolle, technisches Verständnis und Verantwortung in einer Welt, in der Umsetzung plötzlich sehr viel schneller skaliert als unsere Fähigkeit, sie wirklich zu durchdringen?
Wer SDD und KI-Coding-Agenten methodisch im eigenen Team verankern möchte, findet den passenden Rahmen in unserem Training zu agentenbasiertem Coding.
Geschäftsbereichsleitung «Finanzdienstleistungen»
Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter bei atra consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.
