Software nicht zweimal schreiben: spezifikationsgetriebene Entwicklung und das Ende der Neuentwicklungen

Warum Software immer zweimal geschrieben wurde, einmal in Spezifikationen und noch einmal als Code, und warum dieser zweite Schreibvorgang endlich verschwindet.

In der Softwareentwicklung müssen wir, wenn es richtig gemacht wird, Software zweimal schreiben: zuerst in detaillierten Spezifikationen, die genau erklären, was die Software tun soll, und dann noch einmal als Code, der diese Spezifikationen zum Leben bringt. Aber hier ist eine harte Wahrheit: es wird beim ersten Mal selten richtig gemacht.

Der Prozess bricht oft zusammen, weil das Erstellen vollständiger Spezifikationen zeitaufwendig ist und Teams selten alle notwendigen Details vorab erfassen. Das führt zu Lücken, Annahmen und teurer Nacharbeit. Im Ergebnis überschreiten Softwareprojekte häufig das Budget, reißen Fristen und lassen alle frustriert zurück.

Die verborgenen Kosten davon, Software zweimal zu schreiben

Um zu verstehen, warum das zweifache Schreiben notwendig ist, aber selten gut gemacht wird, zerlegen wir die zwei Phasen:

1. Der erste Schreibvorgang: Spezifikationen in natürlicher Sprache

Beim ersten Schreiben von Software schreiben wir überhaupt keinen Code. Es entstehen Anforderungen, Nutzergeschichten und Entwurfsdokumente, geschrieben in natürlicher Sprache. Hier beschreiben Teams, wie die Software funktionieren soll, was Nutzer tun können und wie die Erfahrung sein soll.

Aber hier ist das Problem: kein Team hat je den Luxus, alle Details zu schreiben. Menschen im Produktmanagement müssen oft hetzen, um aggressive Zeitpläne zu halten, und in manchen Projekten gibt es nicht einmal professionelles Produktmanagement. Sie skizzieren die großen Linien, aber wichtige Funktionen und Interaktionen fallen durch. Steve Jobs sagte bekanntlich: „Großartige Produkte entstehen aus 5.000 kleinen Entscheidungen.” In den meisten Projekten treffen wir diese Entscheidungen aber nicht vorab. Sie bleiben der späteren Interpretation durch die Entwicklung überlassen, was zum zweiten Schritt führt.

2. Der zweite Schreibvorgang: Spezifikationen in Code übersetzen

Sobald die Spezifikationen übergeben sind, ist die Entwicklung dafür verantwortlich, diese Beschreibungen in funktionierenden Code zu verwandeln. Wenn der erste Schreibvorgang aber unvollständig ist, muss sie ihre Vorstellungskraft nutzen, um die Lücken zu füllen. Annahmen werden getroffen, und auch wenn Menschen in der Entwicklung die Technologie gut beherrschen, haben sie möglicherweise nicht das vollständige Bild der Produktvision.

Hier treten die Probleme an die Oberfläche:

• Fehlende Details führen zu Reibung: wenn Produktteams eine wichtige Funktion oder einen Anwendungsfall nicht festlegen, muss die Entwicklung raten oder improvisieren. Das ergibt oft Funktionalität, die die Erwartungen nicht erfüllt.
• Annahmen führen zu Nacharbeit: wenn die Entwicklung Lücken füllt, baut sie Funktionen möglicherweise auf Weisen, die nicht zur Produktvision passen, was später im Projekt massive Nacharbeit verursacht.
• Schuldzuweisungen werden unvermeidlich: wenn Fristen rutschen und Budgets überzogen werden, schieben Teams die Verantwortung hin und her. Produktteams werfen der Entwicklung vor, „es nicht zu verstehen”, während die Entwicklung auf unklare Spezifikationen zeigt.

Das Ergebnis ist eine Kaskade von Problemen, die zu gerissenen Zeitplänen, überzogenen Budgets und unbefriedigenden Ergebnissen führt. Die CHAOS-Untersuchung der Standish Group verfolgt seit Jahren, dass die Mehrheit der Softwareprojekte das Budget überschreitet und Liefertermine reißt. Eine Studie von McKinsey mit der University of Oxford fand, dass große IT-Projekte im Durchschnitt 45 Prozent über Budget und 7 Prozent über Zeit laufen und dabei 56 Prozent weniger Wert liefern als vorhergesagt, und dass 17 Prozent der großen IT-Projekte so schlecht laufen, dass sie die Existenz des Unternehmens bedrohen.

Offensichtlich ist in diesem Prozess etwas kaputt.

Die Praxis hat jetzt einen Namen

Die Branche hat sich auf einen Begriff dafür geeinigt, während die meisten Menschen über Prompts stritten: spezifikationsgetriebene Entwicklung. Schreiben Sie zuerst die Anforderungen, die Einschränkungen und die Erfolgskriterien. Behandeln Sie diese Spezifikation als Quelle der Wahrheit. Lassen Sie den Agenten dagegen bauen.

GitHub veröffentlichte Spec Kit. AWS veröffentlichte Kiro. BMAD-METHOD, OpenSpec und Tessl nahmen alle einen Anlauf. Martin Fowler hat darüber geschrieben. Die Konvergenz ist kein Zufall, sie ist das, was passiert, wenn eine ganze Kategorie zur gleichen Zeit dasselbe Fehlermuster entdeckt.

Und das Fehlermuster ist das oben beschriebene. Werkzeuge, die mit dem Prompt beginnen, überspringen den ersten Schreibvorgang vollständig. Sie gehen direkt zum zweiten und raten bei jeder Entscheidung, die die Spezifikation nie getroffen hat. Was für eine Demo in Ordnung ist und für ein Produkt ruinös.

Spezifikationsgetriebene Entwicklung schafft den ersten Schreibvorgang nicht ab. Sie macht ihn zum einzigen, der menschliche Urteilskraft erfordert.

Der neue erste Schreibvorgang: Spezifikationen, die man tatsächlich fertigstellen kann

Hier ist, was sich ändert. Der Grund, warum niemand vollständige Spezifikationen schrieb, war nie, dass man nicht wollte, sondern dass die Arbeit zu langsam war, um sich zu rechtfertigen. Wochen der Erkundung für ein Dokument, das beim ersten Kontakt mit dem ersten Sprint veraltete. Also schrieben Teams die großen Linien und ließen die 5.000 kleinen Entscheidungen später entdecken, eine Interpretation nach der anderen.

Wenn das Entwerfen einer Spezifikation Stunden statt Monate dauert, kehrt sich die Rechnung um. Sie können es sich leisten, vollständig zu sein. Funktionale Anforderungen, visuelles Design, Datenmodell, Randfälle, erfasst bevor irgendwer einen Editor öffnet, und günstig genug, um sie zu überarbeiten, wenn Sie etwas lernen.

Der letzte Teil zählt. Eine Spezifikation, die nicht günstig überarbeitet werden kann, wird zur Lüge, sobald die Realität eintrifft. Das ist derselbe Instinkt hinter dem Bauen API-first: die tragenden Entscheidungen richtig treffen, bevor irgendwer einen Bildschirm schreibt, und der Rest folgt.

Der neue zweite Schreibvorgang: Codegenerierung statt Übersetzung

Sobald die Spezifikation vollständig ist, hört der zweite Schreibvorgang auf, ein Übersetzungsproblem zu sein. Er wird ein Generierungsproblem. Standardsprachen: JavaScript, TypeScript, Python. Standard-Frameworks: React, Next.js. Echter Code, in den Formen, die die Entwicklung schon kennt, abgeleitet aus einem Dokument, das jede Entscheidung schon getroffen hat.

Der Unterschied ist nicht, dass die Entwicklung schneller arbeitet. Er ist, dass sie aufhört, den Teil zu tun, der nie Ingenieursarbeit war: das mechanische Nacherzählen von Entscheidungen, die jemand anders schon getroffen hat.

Was sich weiter unten ändert

Drei Dinge ändern sich gleichzeitig:

1. Der erste Schreibvorgang wird fertig: wenn Spezifikationsarbeit Stunden statt Monate kostet, können Teams sich leisten, die kleinen Entscheidungen vorab zu treffen, statt sie im Review zu entdecken.
2. Niemand füllt Lücken: Code, der aus einer vollständigen Spezifikation generiert wird, verlangt von niemandem zu erraten, was das Produktteam meinte. Das Raten war immer die Quelle der Defekte.
3. Nacharbeit hört auf, sich zu verstärken: Absicht und Umsetzung starten deckungsgleich. Was früher eine Neuentwicklung war, wird eine Änderung an der Spezifikation.

Die Zukunft des Softwareschreibens: natürliche Sprache

Solange Menschen Software ausliefern, verlangte die Arbeit, sie zweimal zu schreiben: einmal in natürlicher Sprache, noch einmal als Code. Dieser zweite Vorgang war nie der wertvolle Teil. Er war der Wegzoll, den wir zahlten, weil es keine andere Straße gab.

Das ist der Schritt, um den sich die nächste Generation der KI-App-Builder organisiert: Klarheit vor Code. Die Anwendung als Blueprint beschreiben, die Architektur richtig hinbekommen, den Code dagegen generieren lassen. Keine Abkürzung um die Definitionsarbeit herum, sondern ein Grund, sie endlich richtig zu machen.

Es gibt jetzt einen anderen Weg. Software sollte immer nur einmal geschrieben werden.

Weiterführende Lektüre

Der vollständige Leitfaden zur Praxis: spezifikationsgetriebene Entwicklung. Warum die Generation, die mit dem Prompt begann, diesen Schritt übersprang, behandelt Vibe Coding hat sein Versprechen gebrochen, und was an seine Stelle tritt was nach dem Vibe Coding kommt.

Häufig gestellte Fragen

Was ist spezifikationsgetriebene Entwicklung? Spezifikationsgetriebene Entwicklung heißt, 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 als direkte Antwort auf Arbeitsabläufe, die mit dem Prompt beginnen und den Definitionsschritt vollständig überspringen.

Wie unterscheidet sich spezifikationsgetriebene Entwicklung vom Schreiben eines klassischen Anforderungsdokuments? Das Dokument ist dieselbe Idee; die Wirtschaftlichkeit nicht. Klassische Spezifikationen waren teuer genug, dass Teams die großen Linien schrieben und den Rest im Code-Review entdeckten. Wenn eine Spezifikation Stunden statt Monate dauert und günstig überarbeitet werden kann, wird es lohnend, sie fertigzustellen, und lohnend, sie 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 gebunden ist: ob sie die Generierung einmal antreibt, sich neben dem Code weiterentwickelt oder das einzige Artefakt ist, das Sie bearbeiten.

Bremst spezifikationsgetriebene Entwicklung Teams aus? Sie verschiebt die Arbeit, sie fügt keine hinzu. Die Entscheidungen, die eine Spezifikation erfasst, trifft ohnehin jemand: entweder bewusst vorab oder implizit, indem später eine Person aus der Entwicklung oder ein Modell rät. Der zweite Weg ist die Quelle der Nacharbeit.

Was passiert mit Menschen in der Entwicklung, wenn Code aus Spezifikationen generiert wird? Das mechanische Nacherzählen der Entscheidungen anderer verschwindet. Die Urteilskraft über Architektur, Abwägungen, Korrektheit und darüber, was man nicht bauen sollte, verschwindet nicht. Das waren immer die Teile, die eine Person aus der Entwicklung erforderten.