Spec-Driven Development: Wenn das Geschäft nicht länger auf die Entwicklung wartet

Der durchschnittliche Entwicklungszyklus für eine neue Funktion in Unternehmenssoftware dauert drei bis sechs Monate. Bis sie ausgeliefert ist, hat sich der Markt bewegt, die Prioritäten haben sich verschoben, und ein Teil der ursprünglichen Anforderungen entspricht nicht mehr der Wirklichkeit. Niemand ist schuld. Der Prozess funktioniert genau so, wie er angelegt ist. Genau darin liegt das Problem.

Spec-Driven Development ist der Versuch, dieses Modell zu durchbrechen – nicht, es auszubessern.

Woran die klassische Entwicklung tatsächlich scheitert

Der klassische Softwareprozess gleicht dem Spiel „Stille Post“. Das Geschäft formuliert eine Idee. Ein Analyst interpretiert sie. Ein Architekt übersetzt sie in eine technische Spezifikation. Ein Entwickler liest diese Spezifikation durch die Brille seines eigenen Denkmodells. Die Qualitätssicherung testet, was gebaut wurde, nicht, was gemeint war. Bei jeder Übergabe verliert das Signal an Schärfe – und wenn das Produkt ausgeliefert wird, setzt es etwas um, das der ursprünglichen Absicht nahekommt, ihr aber nicht ganz entspricht.

Das ist kein Problem mangelnder Begabung, sondern ein Architekturproblem: zu viele Übersetzer zwischen Absicht und Ergebnis.

Die zweite Schwachstelle sind die Kosten von Änderungen. Untersuchungen zum Anforderungsmanagement zeigen immer wieder, dass ein in der Anforderungsphase entstandener Fehler fünf- bis zehnmal so viel kostet, sobald er in funktionierendem Code steckt. Das Geschäft weiß das und vermeidet daher Anforderungsänderungen. Die Entwicklung weiß das und wehrt sich gegen Änderungen des Umfangs. Beide Seiten arbeiten am Ende mit einem veralteten Bild der Wirklichkeit – nur um die Rechnung für die Nacharbeit zu vermeiden.

Was SDD tatsächlich ändert

Der Kerngedanke ist von trügerischer Einfachheit: Die Spezifikation wird zum maßgeblichen, steuernden Artefakt des gesamten Projekts, und KI-Agenten übernehmen die technische Umsetzung.

Das Geschäft beschreibt, was das System leisten soll – in verständlicher Sprache, ohne Fachjargon. Der KI-Agent bestimmt, wie es umgesetzt wird. Der Ingenieur kontrolliert Qualität und Korrektheit dieser Übersetzung. Der Code wird aus der Spezifikation abgeleitet – nicht umgekehrt.

Drei Dinge ändern sich grundlegend.

Tempo. Ein funktionsfähiger Prototyp einer neuen Funktion in Tagen statt Wochen. Mehrere Hypothesen lassen sich gleichzeitig testen. Geschäftsideen lassen sich rasch überprüfen, ohne einen vollständigen Sprint aufzusetzen. Bain & Company berichtet, dass KI-Werkzeuge Entwicklungszyklen bereits um 20–30 % verkürzen. SDD geht weiter: Es automatisiert nicht nur die Codegenerierung, sondern auch die Übersetzung der Anforderungen – die langsamste und teuerste Phase des gesamten Prozesses.

Kosten von Änderungen. In der klassischen Entwicklung kommt eine Anforderungsänderung mitten im Projekt einer Krise nahe. Bei SDD ist sie ein Routinevorgang. Da der Code aus der Spezifikation generiert und nicht von Hand gefertigt wird, kostet seine Neugenerierung fast nichts. Das verändert die Logik der Entscheidungsfindung grundlegend: Teams können experimentieren, Annahmen prüfen und die Richtung wechseln, ohne die Rechnung für die Nacharbeit fürchten zu müssen.

Ein konkretes Beispiel: Ein Team baut eine Architektur rund um ein bestimmtes Geschäftsmodell und stellt nach einem Monat fest, dass das Modell falsch ist. In der klassischen Entwicklung sind damit drei bis vier Monate Arbeit verloren. Bei SDD wird die Spezifikation an einem Tag korrigiert. Der Code wird in wenigen Stunden neu generiert.

Transparenz. Die Spezifikation ist kein technisches Dokument, sondern ein Geschäftsdokument. Auch Beteiligte ohne technischen Hintergrund können sie lesen, prüfen und ändern. Das Geschäft sieht genau, was gebaut wird, bevor die Entwicklung beginnt. Jede Abweichung von der Geschäftslogik zeigt sich auf der Ebene der Spezifikation, nicht erst nach der Veröffentlichung. Die gesamte Historie der Anforderungsänderungen ist versioniert und einsehbar.

Was das für das Team bedeutet

SDD macht Ingenieure nicht überflüssig. Es verändert, was sie wertvoll macht. Die Tiefe des Technologiewissens verliert an Bedeutung. Architektonisches Denken und die Fähigkeit, Anforderungen zu formalisieren, gewinnen an Bedeutung. Ein Ingenieur, der KI-Agenten orchestriert, bewältigt heute das Arbeitspensum, für das früher ein Team aus drei oder vier Spezialisten nötig war.

McKinsey dokumentiert Produktivitätsgewinne von 20–45 % in Organisationen, die KI systematisch in ihre Entwicklungsprozesse eingebunden haben. SDD verstärkt diesen Effekt, indem es den gesamten Zyklus automatisiert – von den Anforderungen bis zum Code.

Ein weniger offensichtlicher Effekt verdient Erwähnung: der Erhalt von Wissen. Im klassischen Modell steckt die Geschäftslogik in den Köpfen der Mitarbeiter. Verlässt ein Ingenieur in einer Schlüsselrolle das Unternehmen, geht entscheidendes Wissen darüber verloren, warum das System so funktioniert, wie es funktioniert. Bei SDD ist die Spezifikation ein lebendes Dokument, das die vollständige Beschreibung der Geschäftslogik des Systems enthält. Ein neues Teammitglied liest sie und versteht sofort das gesamte System.

Wo es am besten funktioniert

Seine größte Wirkung entfaltet SDD in bestimmten Situationen. Start-ups mit großer Unsicherheit bei den Anforderungen und häufigen Kurswechseln – die Kosten von Experimenten sinken nahezu auf null. Wettbewerbsintensive Märkte mit kurzen Veröffentlichungszyklen – das Tempo bei neuen Funktionen wirkt sich unmittelbar auf den Marktanteil aus. Regulierte Umfelder – Compliance-Anforderungen werden in die Spezifikation eingebettet und bei jeder Änderung automatisch geprüft. Modernisierung von Altsystemen – die Spezifikation des bestehenden Systems wird einmal geschrieben und bildet die Grundlage für eine kontrollierte Migration.

Die ehrliche Einschränkung

SDD löst nicht das Problem schlecht formulierter Anforderungen – es legt sie offen. Kann das Geschäft nicht klar beschreiben, was ein System leisten soll, schließt auch kein KI-Agent diese Lücke. Die Qualität der Spezifikation wird zum entscheidenden Engpass. Das ist eine neue Kompetenz, die aufgebaut werden muss – auf der Geschäftsseite ebenso wie auf der Seite der Entwicklung.

Doch genau darum geht es bei diesem Wandel. SDD automatisiert nicht das Denken. Es beseitigt alles, was zwischen dem Denken und dem Ergebnis steht.