Spec-Driven Development für Software. Bald auch für Hardware?

In den 1990er Jahren galt es als Königsweg, Software vollständig zu spezifizieren, bevor die erste Zeile Code entstand. Erst das Lastenheft, dann das Pflichtenheft, dann die Implementierung. Das Verfahren funktionierte nicht. Die Spezifikationen waren veraltet, bevor das Produkt fertig war, und oft stellte sich später heraus, dass die Anforderungen falsch waren. Aus dieser Erfahrung wuchs die agile Bewegung und später DevOps: kleine Schritte, lauffähiger Code mit Unit Tests als Wahrheit, Dokumentation nur dort, wo sie sich rechnet, oft direkt im Code oder in git abgelegt.

Die Generierung von Code aus Modellen war eine verwandte Idee, die wir allerdings nur in Nischen finden. Der Code selbst war ein Wegwerf-Artefakt, das niemand anfasste. Der Aufwand der Modellerstellung war allerdings ehr hoch. Jetzt kehrt genau dieser Gedanke zurück, angetrieben von KI-Coding. Spezifiziert wird noch, Code entsteht auf Knopfdruck neu, und ein Modell braucht es dafür nicht mehr. Die KI übernimmt die Übersetzung.

Historie

Die Idee, Code aus einer höheren Abstraktionsebene zu erzeugen, ist alt. Die Object Management Group prägte um die Jahrtausendwende den Begriff Model Driven Architecture. Werkzeuge wie Rational Rose versprachen, aus UML-Diagrammen lauffähigen Code zu generieren. Mellor und Balcer beschrieben 2002 mit Executable UML eine Variante, in der das Modell selbst ausführbar war und Codegeneratoren die Zielsprache erzeugten.

In der Praxis blieb davon wenig übrig. Die Diagramme waren zu grob für vollständigen Code oder so detailliert, dass sie selbst zu einer Programmiersprache wurden, nur mit schlechterem Editor. Der generierte Code ließ sich schwer debuggen. Sobald ein Entwickler ihn doch von Hand anpasste, war die Kopplung zum Modell zerstört. Der Aufwand, ein Modell auf dem Stand zu halten, aus dem sich verlässlich Code erzeugen ließ, war oft höher als der Aufwand, den Code direkt zu schreiben.

Durchgesetzt hat sich die Modellgenerierung nur dort, wo die Domäne eng und der Nutzen zwingend war. In der Automobilindustrie modellieren Ingenieure Regelalgorithmen in MATLAB Simulink, simulieren das Verhalten auf Modellebene und generieren daraus zertifizierten C-Code für Steuergeräte. Diesen Code fasst niemand an. Ändert sich die Regelstrategie, ändert sich das Modell, und der Code wird neu erzeugt. Das funktioniert, weil die Zertifizierung nach ISO 26262 eine lückenlose Rückverfolgbarkeit verlangt und handgeschriebener Code diese Anforderung teuer macht.

Vibe Coding: Code wird oft nicht mehr angefasst

Durch KI-Coding werden diese Ideen wieder interessant. Wer heute ein Werkzeug wie GitHub Copilot oder einen agentischen Assistenten nutzt, beschreibt in natürlicher Sprache, was entstehen soll, und bekommt lauffähigen Code zurück. Der Begriff Vibe Coding beschreibt die lose Variante davon: Man promptet, prüft grob das Ergebnis und generiert bei Bedarf neu. Programmierkenntnisse sind dafür kaum noch nötig.

Damit ist die alte Vision der Modellgenerierung auf einem Umweg eingetroffen. Der Code ist wieder ein Wegwerf-Artefakt, nur dass die höhere Abstraktionsebene kein UML-Diagramm mehr ist, sondern ein Text in natürlicher Sprache. Das teure Modell entfällt, weil die KI die Übersetzung leistet.

Der Haken liegt woanders. Beim Vibe Coding entsteht keine gepflegte Spezifikation. Der Prompt wird abgesetzt, der Code entsteht, und der Prompt ist danach vergessen. Wer sechs Monate später fragt, warum eine Funktion sich so verhält, wie sie sich verhält, findet dieselbe Antwort wie in den Zeiten vor der KI: lies den Code. Die Spezifikation existiert nur flüchtig im Chatverlauf, wenn überhaupt. Für einen Prototyp reicht das. Für ein System, das Jahre läuft und von wechselnden Teams gepflegt wird, reicht es nicht.

Treiber: Compliance und Skalierbarkeit

Zwei Gründe machen die gepflegte Spezifikation trotzdem wertvoll, und beide werden durch KI-Coding dringender:

1. Compliance. Regulierte Domänen verlangen Rückverfolgbarkeit von der Anforderung bis zum Code. Regulierte Produkte wie Medizingeräte oder Fahrzeuge brauchen eine prüfbare Spezifikation und den Nachweis, dass die Implementierung sie erfüllt. Wenn der Code jederzeit neu generiert wird, ist die Spezifikation die einzige stabile Bezugsgröße, an der sich Konformität überhaupt festmachen lässt.
2. Skalierbarkeit. Eine präzise Spezifikation lässt sich in nicht überlappende Teile zerlegen, an denen mehrere KI-Agenten parallel arbeiten. Aus einem vagen Prompt entsteht bei jedem Lauf etwas anderes, und je mehr Agenten daran hängen, desto stärker driften die Ergebnisse auseinander. Die Spezifikation ist der gemeinsame Vertrag, der die Teile zusammenhält.

Beide Treiber führen zum selben Schluss: Der Prompt muss vom flüchtigen Chateingang zum dauerhaften, versionierten Artefakt werden. Genau an dieser Stelle setzt Spec-Driven Development an.

Das Paper

Ein technischer Bericht von Deepak Babu Piskala aus dem Januar 2026 fasst den Ansatz für Praktiker zusammen. Spec-Driven Development, kurz SDD, dreht das übliche Verhältnis um. Die Spezifikation ist die Quelle der Wahrheit, der Code ein abgeleitetes Artefakt. Der Bericht ordnet die Praxis in drei Stufen der Strenge ein und beschreibt einen Arbeitsablauf aus vier Phasen: spezifizieren, planen, implementieren, validieren. Jede Phase erzeugt ein Artefakt, das die nächste einschränkt, mit menschlicher Prüfung an jedem Übergang.

Dem Autor ist aufgefallen, dass KI-Modelle stark im Vervollständigen von Mustern sind, aber schwach im Gedankenlesen. Ein Prompt wie „füge Fototeilen zu meiner App hinzu“ zwingt das Modell zu Dutzenden ungenannter Annahmen über Format, Rechte, Größenlimits und Speicherort. Eine präzise Spezifikation nimmt diese Annahmen vorweg. Der Bericht verweist auf frühe kontrollierte Studien, die eine Fehlerreduktion von bis zu 50 Prozent durch von Menschen verfeinerte Spezifikationen messen. Die Zahl ist mit Vorsicht zu lesen, die Datenlage ist dünn, aber die Richtung passt zur Erfahrung.

Bemerkenswert ist die Einordnung des Autors selbst. Er zitiert Bryan Finster mit dem Satz, SDD sei keine Revolution, sondern BDD mit besserem Marketing. Neu sind nicht die Ideen, sondern die Werkzeuge, die ausführbare Spezifikationen praktikabel machen, und die KI als Konsument, für den Spezifikationsqualität direkt über die Ergebnisqualität entscheidet.

SDD ist keine Revolution, sondern BDD mit besserem Marketing

Bryan Finster: 5-Minute DevOps: Spec-Driven Development Isn’t New

Von Vibe Coding zu Spec-as-Source

Der Bericht identifiziert ein Spektrum, mit welchem der Reifegrad von SDD klassifiziert werden kann.An einem Ende steht die code-zentrierte Entwicklung: Code zuerst, Doku später, Drift die Regel. Vibe Coding ohne gepflegte Spezifikation sitzt genau hier. Am anderen Ende steht Spec-as-Source: Die Spezifikation ist das Einzige, was Menschen bearbeiten, Code wird ausschließlich generiert und nie von Hand angefasst. Dazwischen liegen zwei Zwischenstufen.

1. Ad-hoc. Es gibt keine Spezifikation, es gibt nur Prompts, die nicht weiter aufbewahrt werden. Bei Unklarheiten wird die AI befragt, ebenfals ad-hoc.
2. Spec-First. Die Spezifikation entsteht vor dem Code und leitet die erste Implementierung. Danach darf sie driften. Der Nutzen liegt in der anfänglichen Klarheit, der Pflegeaufwand ist gering. Für Prototypen und einmalige Features passt das.
3. Spec-Anchored. Die Spezifikation lebt über den gesamten Lebenszyklus mit dem Code. Jede Verhaltensänderung erfordert eine Änderung an beiden. Tests aus der Spezifikation erzwingen die Kopplung. Driften Code und Spezifikation auseinander, schlägt der Build fehl. Für die meisten produktiven Systeme ist das der sinnvolle Punkt.
4. Spec-as-Source. Die Spezifikation ist der Quellcode, nur auf höherer Abstraktionsebene. Drift ist per Konstruktion ausgeschlossen, weil Code neu generiert statt von Hand geändert wird. Das verlangt reife, vertrauenswürdige Generatoren. Simulink im Automobilbau ist ein etabliertes Beispiel, Werkzeuge wie Tessl zielen auf allgemeine Softwareentwicklung.

Je weiter rechts, desto größer die Autorität der Spezifikation und desto größer die geforderte Disziplin. Die richtige Wahl ist die minimale Stufe, die für den jeweiligen Kontext die Mehrdeutigkeit beseitigt. Spec-First für KI-gestützte Erstentwicklung, Spec-Anchored für langlebige Systeme, Spec-as-Source erst, wenn die Generierung verlässlich ist.

BDD geht in eine ähnliche Richtung, nur ohne AI

Wer die Idee kennt, dass Spezifikation und Test eng gekoppelt sein sollten, hat sie vermutlich unter dem Namen Behaviour-Driven Development getroffen. BDD hält Ziele, Anforderungen und Ergebnisse so fest, dass sie sich später als automatisierte Tests ausführen lassen. Spezifikation und Test sind extrem eng aneinander gekoppelt, sodass sich automatisch prüfen lässt, ob eine Anforderung erfüllt ist. Das ist Spec-Anchored, nur ohne KI im Spiel.

BDD löst dabei genau das Problem, das SDD für die KI löst, nur für Menschen. Entwickler und Product Owner streiten sonst darüber, was „fertig“ bedeutet. Eine ausführbare Spezifikation macht die Definition prüfbar statt strittig. Ein Feature ist fertig, wenn seine Szenarien und dazugehörigen Unit Tests grün sind.

Der Unterschied zwischen BDD und SDD ist kleiner, als das Marketing vermuten lässt. BDD schreibt die Spezifikation für einen Menschen, der den Code danach von Hand implementiert. SDD schreibt sie für ein Modell, das den Code generiert. Die Spezifikation selbst, ihre Rolle als Vertrag und ihre Kopplung an Tests bleiben dieselben. Wer BDD im Systems Engineering ernst genommen hat, ist auf SDD besser vorbereitet als jemand, der bei null anfängt.

Was ist mit Systems Engineering?

Bis hierhin ging es um Software. Der Titel stellt die interessantere Frage: Lässt sich das Verfahren auf Hardware übertragen? Solange Code ein Wegwerf-Artefakt ist, das die KI in Sekunden neu erzeugt, funktioniert das. Doch Mechanik oder Elektronik lassen sich nicht so leicht erzeugen wie Software, trotz 3D-Drucker und anderen Ansätzen des Rapit Manufacturing. Noch extremer ist es, wenn die physikalischen Artefakte bereits beim Kunden im Einsatz sind.

Der Ausweg liegt nicht darin, Hardware wie Software zu behandeln, sondern darin, sie aus dem generierbaren Teil herauszuhalten. Das Mittel dafür ist Plattformdenken. Man definiert eine Hardwareplattform, die über klare Schnittstellen steuerbar ist, und friert sie ein. Solange die Plattform über ihre APIs vollständig ansprechbar ist, wandert sämtliche Variabilität in die Software.

Genau dort greift SDD wieder. Was am Produkt variiert, steckt in der Software und ist damit spezifizierbar und generierbar. Die Hardware bleibt stabil und wird zur Ausführungsumgebung. Teslas Funktionsumfang ändert sich per Over-the-Air-Update auf unveränderter Hardware. Noch deutlicher zeigt sich die Macht der Plattform beim Smartphone. Android liefert völlig neue Funktionen sicher über Apps aus, ohne dass sich am Gerät etwas ändert. In beiden Fällen ist die Hardware die Plattform, und die Wertschöpfung verschiebt sich in die Software.

Damit kommen wir wieder zur anfänglichen Frage zurück. SDD kommt nicht dadurch zur Hardware, dass Bleche und Zahnräder aus Spezifikationen wachsen. Es kommt dadurch, dass eine saubere Plattform mit vollständiger API-Steuerung die Hardware wegabstrahiert und die verbleibende Komplexität dorthin schiebt, wo Spezifikation und Generierung tatsächlich funktionieren.

Fazit

Der Bogen schließt sich zur Vergangenheit. Was in den 1990er Jahren scheiterte, die Spezifikation vor dem Code, kehrt zurück, weil sich die Kosten verschoben haben. Damals war das Erstellen und Pflegen der höheren Abstraktionsebene teurer als der Code. Heute übernimmt die KI die Übersetzung, und der Code wird billig genug, um ihn als Wegwerf-Artefakt zu behandeln. Damit wird die Spezifikation wieder zur lohnenden Investition.

Für die Praxis heißt das dreierlei. Wer Vibe Coding betreibt und die Spezifikation im Chatverlauf verrottet lässt, verschenkt den eigentlichen Hebel und handelt sich die Driftprobleme der 90er neu ein. Wer Compliance oder Skalierung braucht, sollte den Prompt zum versionierten Artefakt machen und die passende Stufe wählen, meist Spec-Anchored. Und wer im Systems Engineering arbeitet, sollte zuerst in Plattformen denken. Erst wenn die Hardware über APIs vollständig steuerbar ist und die Variabilität in der Software sitzt, lässt sich das Verfahren auf physische Produkte übertragen. Die Frage ist dann nicht mehr, ob SDD für Hardware taugt, sondern wie sauber die Plattform geschnitten ist.