Spezifikationsgetriebene Entwicklung: die Praxis, auf die die Kategorie konvergierte

Jedes ernstzunehmende KI-Werkzeug für Code hat innerhalb von etwa einem Jahr dieselbe Funktion veröffentlicht, und das passiert fast nie zufällig.

2025 war die interessante Frage, wie gut die Modelle wurden. 2026 ist die interessante Frage, was man ihnen übergibt.

GitHub veröffentlichte Spec Kit. AWS veröffentlichte Kiro, eine Entwicklungsumgebung, die um diese Idee gebaut ist. BMAD-METHOD, OpenSpec und Tessl nahmen je einen Anlauf. Cursor kam über Regeldateien dorthin. Martin Fowler hat einen Vergleich der Umsetzungen veröffentlicht. Wenn sechs unabhängige Teams innerhalb von zwölf Monaten auf dieselbe Antwort konvergieren, kopieren sie nicht einander. Sie stoßen alle gegen dieselbe Wand.

Die Wand hat jetzt einen Namen. Die Lösung auch.

Was spezifikationsgetriebene Entwicklung tatsächlich ist

Schreiben Sie die Anforderungen, die Einschränkungen und die Erfolgskriterien, bevor irgendein Code generiert wird. Behandeln Sie dieses Dokument als Quelle der Wahrheit. Lassen Sie den Agenten dagegen bauen.

Das ist alles. Es ist keine neue Idee, es ist Anforderungsanalyse, die die Branche dreißig Jahre lang schlecht betrieben und dann als zu langsam weitgehend aufgegeben hat. Was sich geändert hat, ist nicht das Konzept. Es ist die Wirtschaftlichkeit.

Spezifikationen waren früher teuer zu schreiben und teuer aktuell zu halten, was hieß, dass die meisten Teams die großen Linien schrieben und alles andere im Code-Review entdeckten. Das war ein rationaler Handel, solange eine Person in der Entwicklung für die Funktion ohnehin drei Wochen brauchte. Es hörte auf rational zu sein, als die Generierung schnell wurde, denn jetzt ist die Spezifikation der langsame Teil, und im langsamen Teil wohnt die ganze Urteilskraft.

Das Fehlermuster, gegen das sie erfunden wurde

Werkzeuge, die mit dem Prompt beginnen, überspringen die Spezifikation vollständig. Sie beschreiben ein Ergebnis, das Werkzeug erzeugt etwas, das ihm ähnelt, und jede Entscheidung, die die Beschreibung nicht abdeckte, trifft der Generator stillschweigend.

Welche Entscheidungen? Diejenigen, die sich als wichtig erweisen. Ob eine E-Mail-Adresse eindeutig ist, und eindeutig innerhalb welcher Menge. Was ein gekündigtes Konto noch sehen darf. Was passiert, wenn zwei Menschen denselben Datensatz bearbeiten. Ob diese Liste eine Seitennavigation braucht, bevor sie zehntausend Zeilen enthält.

Niemand hat diese Fragen gestellt, also hat niemand sie beantwortet, aber die Anwendung hat auf jede eine Antwort, gewählt durch Schlussfolgerung aus einem Kontext, der Ihr Geschäft nie enthielt.

Dieselbe Dynamik zeigt sich in jedem Werkzeug, das den Definitionsschritt überspringt. Es ist der Mechanismus hinter dem 70-Prozent-Problem: der Fortschritt stockt nicht, weil die verbleibende Arbeit schwer ist, sondern weil sie von einer architektonischen Entscheidung blockiert wird, die Hunderte Generierungen früher implizit getroffen wurde und nicht mehr geändert werden kann, ohne das System auseinanderzuziehen.

Die Daten dazu, was ohne sie passiert

DORAs Bericht zum Stand der KI-unterstützten Softwareentwicklung 2025 ist die klarste verfügbare Lesart. 90 Prozent der Fachleute in der Technologie nutzen inzwischen KI bei der Arbeit, und mehr als 80 Prozent glauben, dass sie ihre Produktivität erhöht hat. Und eine höhere KI-Nutzung geht mit einer Zunahme des Liefer-Durchsatzes und mit einer Zunahme der Liefer-Instabilität einher, gleichzeitig.

Schneller beim Ausliefern. Schlechter darin, Dinge am Laufen zu halten. Beides zusammen.

GitClears Analyse von 623 Millionen Codeänderungen aus dem Jahr 2026 zeigt die Form des Schadens. Gegenüber der Basislinie von 2023: duplizierte Codeblöcke um 81 Prozent gestiegen, Kopieren und Einfügen innerhalb eines Commits von 9,4 Prozent im Jahr 2022 auf 15,7 Prozent im ersten Halbjahr 2026 gestiegen, fehlerverdeckende Konstrukte um 47 Prozent gestiegen. Gleichzeitig Funktionsaufrufe über Dateigrenzen hinweg (der beste verfügbare Näherungswert für Wiederverwendung) um 35 Prozent gefallen, und die Refactoring-Aktivität von 21 Prozent der Änderungen im Jahr 2022 auf 3,8 Prozent im Jahr 2026 eingebrochen.

Menschen in der Entwicklung kopieren und fügen inzwischen etwa fünfmal wahrscheinlicher ein, als dass sie refaktorieren. 2022 lief dieses Verhältnis in die andere Richtung.

Nichts davon ist ein Problem der Modellqualität. Es ist, was passiert, wenn Generierung günstig ist und Struktur ausdrücklich niemandes Aufgabe.

Die drei Grade der Verbindlichkeit

Nicht alle meinen damit dasselbe, und die Unterschiede zählen in der Praxis. Martin Fowlers Rahmung ist die klarste, die ich gesehen habe.

Spezifikation zuerst. Sie schreiben die Spezifikation, generieren daraus und pflegen den Code danach von Hand. Die Spezifikation treibt den ersten Bau an und wird dann allmählich historisch. Am leichtesten einzuführen, mit den schwächsten Garantien: sechs Monate später beschreibt das Dokument ein System, das nicht mehr existiert.

Spezifikation als Anker. Spezifikation und Code entwickeln sich gemeinsam. Spezifikation ändern, die betroffenen Teile neu generieren, beides aktuell halten. Mehr Disziplin, und der Lohn ist, dass das Dokument vertrauenswürdig bleibt.

Spezifikation als Quelle. Die Spezifikation ist das einzige Artefakt, das Sie bearbeiten. Code ist Ausgabe, so wie eine kompilierte Binärdatei Ausgabe ist: Sie flicken sie nicht von Hand. Die stärksten Garantien und der größte Sprung in der Arbeitsweise eines Teams.

Die meisten Teams, die sich spezifikationsgetrieben nennen, betreiben Spezifikation zuerst. Das ist eine echte Verbesserung gegenüber blindem Prompten, und es ist auch die Variante, die leise verfällt.

Was in die Spezifikation gehört

Der nützliche Test: wenn der Generator raten müsste, gehört es in das Dokument.

• Das Datenmodell. Entitäten, Beziehungen, Kardinalität, was einen Datensatz eindeutig macht, was beim Löschen passiert. Das ist der wertvollste Abschnitt und der, der am häufigsten übersprungen wird.
• Nutzertypen und Berechtigungen. Wer existiert, was jeder sehen und tun darf, was an den Grenzen passiert.
• Die Invarianten. Regeln, die niemals verletzt werden dürfen, klar benannt. Nicht „Fehler elegant behandeln”, das ist ein Wunsch und keine Einschränkung.
• Erfolgskriterien. Woran Sie erkennen, dass die Sache funktioniert, in Begriffen konkret genug, dass eine Meinungsverschiedenheit darüber auflösbar ist.

Was nicht dazugehört: Umsetzungsdetails, die der Generator besser wählt als Sie. Eine Spezifikation, die Variablen benennt, ist keine Spezifikation, sie ist Code mit schlechterem Werkzeug.

Der Teil, den alle falsch machen

Eine Spezifikation hilft nur, wenn sie irgendwo anders als in Prosa durchsetzbar ist.

Wenn eine Einschränkung nur im Dokument lebt, ist sie ein Vorschlag. Der Generator hat sie einmal gelesen und sie in der vierzehnten berührten Datei möglicherweise beachtet oder auch nicht. Einschränkungen müssen dort landen, wo das System prüft: „nicht null” und „eindeutig” in der Datenbank statt in einem Formular-Handler, Typen an den Grenzen statt in einem Kommentar, Autorisierung als Richtlinie, die das System auswertet, statt als Bedingung, an die jemand gedacht hat.

Das ist der Unterschied zwischen spezifikationsgetriebener Entwicklung als Praxis und spezifikationsgetriebener Entwicklung als Dokumentengattung. Das Dokument ist, wie Sie entscheiden. Die Durchsetzung ist, wie Sie die Entscheidung behalten.

Wie Sie erkennen, ob Sie es tatsächlich betreiben

Vier Fragen, und sie sind absichtlich unbequem.

1. Wenn etwas bricht, reparieren Sie den Code oder die Spezifikation? Wenn die Antwort immer der Code ist, betreiben Sie bestenfalls Spezifikation zuerst, und das Dokument ist schon veraltet.
2. Könnte eine neue Person die Spezifikation lesen und vorhersagen, wie das System sich verhält? Wenn sie dafür den Code lesen müsste, ist die Spezifikation eine Zusammenfassung und keine Quelle.
3. Gibt es in der Spezifikation etwas, das das System nicht verletzen kann? Wenn jede Regel Prosa ist, ist keine garantiert.
4. Prüfen Sie die Spezifikation oder das Diff? Tausende Zeilen generierten Codes zu prüfen ist Theater. Streiten Sie über das Dokument, solange Streiten noch günstig ist.

Wo das die Werkzeuge zurücklässt

Die meisten heutigen Umsetzungen sind spezifikationsgetrieben speziell für die Codegenerierung. Sie erzeugen eine Spezifikation und generieren eine Umsetzung dagegen, und das Artefakt, auf dem sie arbeiten, ist eine Codebasis.

Die schwierigere Variante erweitert dieselbe Logik auf die ganze Anwendung (das Datenmodell, die API-Oberfläche, die Authentifizierungsgrenze, die Oberfläche), sodass die Spezifikation nicht nur abdeckt, was der Code tut, sondern was das System ist. Genau das ist Archies Blueprint-Phase, und deshalb beschreibe ich sie als spezifikationsgetriebene Entwicklung, angewandt auf den gesamten Stack statt auf ein Repository. Anderer Umfang, dasselbe Prinzip: definieren, bevor generiert wird.

Vernünftige Menschen sind uneinig darüber, wie weit man das treiben soll. Niemand, der es ernst meint, argumentiert für eine Rückkehr.

Was es kostet

Urteilskraft nach vorn zu ziehen ist in der ersten Woche eines Projekts langsamer und in jeder Woche danach schneller. Diese Kosten sind real, und sie werden genau in dem Moment bezahlt, in dem Schwung am wertvollsten erscheint, während ein Wettbewerber etwas Sichtbares ausliefert. Es wird Sprints geben, in denen das Team, das das übersprungen hat, wie der Gewinner aussieht.

Die Disziplin verfällt außerdem. Einschränkungen aufzuschreiben ist weniger vergnüglich, als eine Oberfläche erscheinen zu sehen, und ein Dokument zu prüfen ist weniger befriedigend, als Code zu prüfen. Diese Gewohnheiten erodieren unter Termindruck, und das ist derselbe Druck, der sie wichtig macht.

Und es gilt wirklich nicht für alles. Wenn Sie dieses Wochenende eine Idee validieren und das Ergebnis wegwerfen wollen, werfen Sie es weg. Für Software mit zwei Tagen Lebensdauer lohnt sich davon nichts.

Der Grund, warum das geblieben ist

Jeder frühere Versuch, Teams dazu zu bringen, zuerst Spezifikationen zu schreiben, scheiterte, und er scheiterte aus einem guten Grund: die Spezifikation war Zusatzaufwand über der eigentlichen Arbeit. Sie schrieben das Dokument und mussten das Ding danach trotzdem bauen.

Das ist nicht länger der Handel. Jetzt ist das Dokument der größte Teil der Arbeit, und das Bauen ist der günstige Teil. Sechs unabhängige Teams haben das innerhalb eines Jahres bemerkt, weil es die offensichtliche Folge davon war, dass das Modell gut wurde.

Die Praxis hat keinen Streit gewonnen. Die Wirtschaftlichkeit hat sich unter ihr verschoben.

Weiterführende Lektüre

Die ursprüngliche Diagnose: Vibe Coding hat sein Versprechen gebrochen. Wohin die Kategorie als Nächstes ging: was nach dem Vibe Coding kommt. Dasselbe Argument auf ganze Systeme angewandt: AI-first-Softwaredesign aus ersten Prinzipien. Und die ältere Fassung derselben Idee: Software nicht zweimal schreiben.

Häufig gestellte Fragen

Was ist spezifikationsgetriebene Entwicklung? Die Anforderungen, Einschränkungen und Erfolgskriterien zu schreiben, bevor irgendein Code generiert wird, und diese Spezifikation als die Quelle der Wahrheit zu behandeln, gegen die der KI-Agent baut. Sie entstand 2025 und 2026 als direkte Antwort auf Arbeitsabläufe, die mit dem Prompt beginnen und den Definitionsschritt überspringen.

Wie unterscheidet sie sich von klassischen Anforderungsdokumenten? Das Konzept ist dasselbe; die Wirtschaftlichkeit nicht. Klassische Spezifikationen waren teuer genug, dass Teams die großen Linien schrieben und den Rest während der Umsetzung entdeckten. Wenn das Entwerfen Stunden statt Monate dauert und günstig überarbeitet werden kann, wird es lohnend, sie fertigzustellen und aktuell zu halten.

Welche Werkzeuge unterstützen spezifikationsgetriebene Entwicklung? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec und Tessl sind die benannten Umsetzungen, und Cursor unterstützt über Regeldateien eine leichtere Variante. Sie unterscheiden sich vor allem darin, wie fest die Spezifikation an den Code bindet: ob sie die Generierung einmal antreibt, sich neben ihm weiterentwickelt oder das einzige Artefakt ist, das Sie bearbeiten.

Was sind die drei Grade der spezifikationsgetriebenen Entwicklung? Spezifikation zuerst, wo die Spezifikation den ersten Bau antreibt und Sie den Code danach von Hand pflegen. Spezifikation als Anker, wo Spezifikation und Code sich gemeinsam entwickeln. Spezifikation als Quelle, wo die Spezifikation das Einzige ist, das Sie bearbeiten, und Code als Ausgabe behandelt wird. Die meisten Teams, die es betreiben, machen Spezifikation zuerst.

Bremst spezifikationsgetriebene Entwicklung Teams aus? Sie verlagert die Arbeit, statt sie hinzuzufügen. Die Entscheidungen in einer Spezifikation werden entweder bewusst vorab getroffen oder implizit von einem Generator, der später rät, und der zweite Weg ist die Quelle der Nacharbeit. Sie ist in der ersten Woche langsamer und danach schneller.

Was sollte in eine Spezifikation? Alles, was der Generator sonst erraten müsste: das Datenmodell mit Beziehungen und Eindeutigkeitsregeln, Nutzertypen und Berechtigungen, Invarianten, die niemals verletzt werden dürfen, und Erfolgskriterien, die konkret genug sind, um eine Meinungsverschiedenheit zu klären. Lassen Sie Umsetzungsdetails weg, die der Generator besser wählt als Sie.

Ist spezifikationsgetriebene Entwicklung dasselbe wie AI-first-Design? Spezifikationsgetriebene Entwicklung ist die Praxis, vor dem Generieren zu definieren. AI-first-Design ist die breitere Menge architektonischer Folgen, die auch abdeckt, wo Einschränkungen durchgesetzt werden, in welcher Reihenfolge Sie Entscheidungen treffen und wie man neben menschlichen auch für agentische Konsumenten entwirft.