Spec-Driven Development: Warum die Zukunft der Software in Beschreibungen liegt und nicht in Code

Software wird künftig nicht programmiert, sondern beschrieben. GitHub, Amazon und Thoughtworks arbeiten bereits an genau dieser Zukunft. Der Fachbegriff: Spec-Driven Development.

Ich bin Geschäftsführer eines Softwareunternehmens. Kein Entwickler. Letzte Woche saß ich mit einem Kunden zusammen, der ein halbes Jahr auf die Fertigstellung einer Anwendung gewartet hatte – nicht wegen fehlender Ideen, sondern weil sein React-Team kein Angular konnte und das Zielsystem Angular verlangte. Solche Situationen erlebe ich regelmäßig. Gerade weil ich von der Business-Seite komme, sehe ich etwas, das vielen Technikern entgeht: Die häufigste Bremse in Softwareprojekten ist nicht fehlende Technologie. Es ist die Abhängigkeit davon.

Software ist an Technologie gefesselt – und das kostet

Jedes Softwareprojekt beginnt mit einer Entscheidung, die niemand gerne trifft: Welche Programmiersprache? Welches Framework? Cloud oder eigene Server? Diese Entscheidung fällt in den ersten Wochen und bindet das Projekt für Jahre.

Die gewählte Technologie bestimmt, welche Entwickler man braucht, wie die Architektur aussieht, was später noch möglich ist. Ein Technologiewechsel bedeutet oft einen Teamwechsel. Was vor drei Jahren modern war, ist heute veraltet – aber die Software läuft noch darauf. Laut einer Studie von Stripe (2023) verbringen Entwickler im Schnitt 42 % ihrer Arbeitszeit mit Wartung statt mit neuen Features.

Was wäre, wenn die Technologie keine Rolle mehr spielen würde?

Spec-Driven Development: Beschreibung statt Code

Spec-Driven Development stellt eine einfache These auf: Nicht der Code ist das zentrale Artefakt – sondern die Spezifikation. GitHub formuliert das in der Dokumentation ihres Open-Source-Toolkits Spec Kit so:

„Maintaining software means evolving specifications. The lingua franca of development moves to a higher level, and code is the last-mile approach.“

Software wird als strukturierter Text beschrieben – was sie tun soll, welche Regeln gelten, wie Bestandteile zusammenhängen. Die KI übernimmt die Implementierung. Immer wieder neu: für verschiedene Plattformen, Tech-Stacks und Zielumgebungen.

Das ist kein Gedankenexperiment. Kiro (AWS), Tessl und GitHub Spec Kit setzen diesen Ansatz heute um. Martin Fowler und Thoughtworks haben SDD analysiert und sehen darin einen der relevantesten Trends der KI-gestützten Softwareentwicklung.

Ideen zählen mehr als Code

Hier wird es unbequem für manche.

Wenn Software durch Beschreibungen definiert wird, verschiebt sich eine Grenze: Wer Software gestalten kann, ist nicht mehr an technisches Know-how gebunden. Bisher übergeben Fachexperten Anforderungen an Entwicklerteams. Das dauert. Es entstehen Missverständnisse. Die Übersetzung von „das brauche ich“ zu „so funktioniert es technisch“ frisst Wochen.

In einer Welt des Spec-Driven Development wird die Beschreibung selbst zum Werkzeug der Umsetzung. Die Frage „Kann jemand im Team React?“ wird irrelevant, wenn die KI dieselbe Beschreibung in jeder Technologie umsetzen kann.

Werden Entwickler überflüssig? Nein. Aber ihre Rolle verändert sich – hin zu Architekten und Qualitätsprüfern, die sicherstellen, dass KI-generierte Lösungen robust und sicher sind. Für mich als Geschäftsführer ist das eine Befreiung.

Modulare Prompt-Architektur: Software als Baukasten

Eine Softwarebeschreibung als ein einziger, riesiger Textblock? Funktioniert nicht.

Statt einer monolithischen Beschreibung zerlegt man Spezifikationen in wiederverwendbare Bausteine. Ein Baustein beschreibt die Nutzeranmeldung. Ein anderer die Anbindung an eine Zahlungsschnittstelle. Ein dritter regelt die DSGVO-Konformität. Diese Bausteine lassen sich projektübergreifend wiederverwenden – und für verschiedene Kunden anpassen.

Der kontraintuitive Effekt: Änderungen werden einfacher, nicht schwieriger. Ändert sich eine Anforderung, tauscht man den betreffenden Baustein aus. Die KI generiert die aktualisierte Software. Kein manuelles Refactoring an hundert Stellen. Wer erlebt hat, wie eine kleine Änderung an einer Stelle drei andere Systeme lahmlegt, weiß, wie viel das wert ist.

Multi Layer Prompt Engineering: Die KI als Sparringspartner

Die Qualität der Software hängt von der Qualität der Beschreibung ab. Genau hier liegt die eigentliche Herausforderung – die wenigsten Menschen können auf Anhieb eine Spezifikation schreiben, die präzise genug für eine funktionierende Software ist. Ich auch nicht.

Die Lösung: Die KI wird nicht nur genutzt, um Software zu generieren – sie hilft, die Beschreibung selbst zu erstellen. Wir nennen das Multi Layer Prompt Engineering.

Das funktioniert in Schichten. Erste Schicht: Der Mensch formuliert die grobe Vision – was soll die Software leisten, für wen, unter welchen Bedingungen? Zweite Schicht: Die KI strukturiert diese Idee, fragt nach, deckt Lücken auf. Dritte Schicht: Gemeinsam werden die Bausteine präzisiert. Erst dann entsteht Code – automatisch, auf Basis der ausgereiften Beschreibung.

Die KI hilft, die richtigen Fragen zu stellen, bevor die falschen Antworten implementiert werden. In der Praxis heißt das: weniger Nachbesserungen, weniger Reibung zwischen Fachseite und Technik.

Was das für Ihr Unternehmen bedeutet

Die Werkzeuge existieren. Die Frage ist nicht ob, sondern wann Ihr Entwicklungsprozess sich anpasst. Dabei entsteht gerade ein Wettbewerbsfaktor, den viele unterschätzen: Unternehmen, die jetzt Spec-Bibliotheken und Prompt-Architekturen aufbauen, entwickeln eine Beschreibungskompetenz, die sich in zwei Jahren nicht nachholen lässt. Laut Thoughtworks’ Technology Radar (2025) gehören Spec-basierte Ansätze zu den Methoden, die Teams aktiv evaluieren sollten – nicht irgendwann, sondern jetzt.

Ein konkretes Beispiel aus unserer Arbeit: Für einen Kunden haben wir eine bestehende Spezifikation, die ursprünglich für eine Web-App geschrieben war, innerhalb von Tagen auf eine mobile Plattform übertragen – ohne ein einziges Teammitglied auszutauschen. Mit klassischer Entwicklung wäre das ein Projektstart von vorne gewesen.

Was viele noch nicht auf dem Schirm haben: Spec-Bibliotheken werden zum strategischen Asset. Wer seine Geschäftslogik einmal sauber beschrieben hat, kann sie in zwei Jahren gegen eine völlig andere Technologie austauschen – ohne Informationsverlust. Das ist ein Vorteil, den kein Code-Repository bieten kann.

Wir bei esveo setzen diese Ansätze bereits in Projekten ein und begleiten Unternehmen dabei, Spec-Driven Development für ihre eigene Softwareentwicklung nutzbar zu machen. Wenn das ein Thema ist, das Sie beschäftigt: Lassen Sie uns reden.

Häufig gestellte Fragen

Was ist Spec-Driven Development? Ein Entwicklungsansatz, bei dem die strukturierte Beschreibung einer Software – nicht der Code – das zentrale Artefakt ist. KI-Systeme generieren daraus automatisch die technische Implementierung.

Was bedeutet technologieagnostische Softwareentwicklung? Die Softwarebeschreibung ist unabhängig von Programmiersprache, Framework oder Plattform. Dieselbe Spezifikation kann für unterschiedliche Tech-Stacks umgesetzt werden.

Was ist modulare Prompt-Architektur? Software-Spezifikationen werden in wiederverwendbare Bausteine zerlegt, die sich flexibel kombinieren und projektübergreifend einsetzen lassen.

Was ist Multi Layer Prompt Engineering? Eine Methode, bei der KI nicht nur Code generiert, sondern bereits bei der Erstellung und Verfeinerung der Softwarebeschreibung unterstützt – von der groben Idee bis zur präzisen Spezifikation.

Werden Entwickler durch KI ersetzt? Nein. Ihre Rolle verändert sich: von der Implementierung hin zur Architektur und Qualitätssicherung. Technisches Know-how bleibt relevant, ist aber nicht mehr die einzige Voraussetzung, um Software zu gestalten.

Ist Spec-Driven Development praxisreif? Die Grundlagen stehen: GitHub (Spec Kit), AWS (Kiro) und andere bieten bereits produktive Tools. Für den Einsatz in realen Projekten braucht es aktuell noch erfahrene Begleitung – die Entwicklung schreitet aber schnell voran.