Spezifikation statt Code? – Teil 2: Spec-Driven Development im Praxistest

von  und  | 18. Dezember 2025 | Künstliche Intelligenz, Software Engineering

Sebastian Albrecht

Senior Consultant

Jan Urbansky

Senior Developer

Benedikt Veit

Senior Consultant

Matthias Holzammer

Consultant

Spec-Driven Development: Eine neue Evolutionsstufe der Softwareentwicklung?

Spec-Driven Development (SDD) ist derzeit eines der spannendsten Konzepte im Kontext moderner Softwareentwicklung. Der Begriff taucht zunehmend im Umfeld von Künstlicher Intelligenz auf und verspricht, den bisherigen Entwicklungsprozess grundlegend zu verändern. Statt Code manuell Zeile für Zeile zu schreiben oder wie beim Vibe-Coding das Programmieren auf Basis vager Anweisungen der KI zu überlassen, stellt SDD einen viel weitreichenderen Paradigmenwechsel in Aussicht: Die Spezifikation wird zum zentralen Artefakt der Softwareentwicklung – der Code entsteht daraus als abgeleitetes Ergebnis und rückt im Entwicklungsprozess gegenüber der Spezifikation in den Hintergrund.

In der Theorie klingt dieser Ansatz vielversprechend. Doch wie reif sind die entsprechenden Tools wirklich? Welche Potenziale lassen sich heute schon praktisch nutzen? Und was bedeutet das für den Alltag in der Softwareentwicklung? Um diese Fragen zu beantworten, hat ein Team von Senacor-Berater:innen in einer fünftägigen internen Intermission aktuelle SDD-Werkzeuge auf den Prüfstand gestellt. Der Fokus lag dabei auf einem praxisnahen Use Case, mit dem sich die Leistungsfähigkeit und Reife der Tools konkret erproben ließ.

Im Mittelpunkt der Untersuchung standen drei Werkzeuge: Microsoft Power Platform Plan Designer, Microsoft Power Platform Generative Pages und das hersteller- und programmiersprachen-unabhängige Framework GitHub Spec Kit. Ziel war es, ihre Stärken, Schwächen und jeweiligen Besonderheiten im direkten Vergleich sichtbar zu machen – nicht auf Basis von Marketingversprechen, sondern anhand eines konkreten Entwicklungsprojekts. Das Ergebnis ist ein differenzierter Einblick in eine Technologie, die sich noch in der frühen Phase befindet, aber schon heute produktiv nutzbar ist – vorausgesetzt, die Einsatzszenarien sind gut gewählt.

Dieser Blogartikel gehört zu einer zweiteiligen Serie. Im ersten Teil wurden bereits die theoretischen Grundlagen vorgestellt und erklärt, was SDD eigentlich ist. Im zweiten Teil stellen wir nun einen Erfahrungsbericht aus dem praktischen Umgang mit den drei genannten Tools vor und ordnen ein, welche Rolle SDD heute bereits einnehmen kann und wo langfristiges Potenzial liegt.

Der Senacor-Praxistest: Drei Tools im Vergleich

Im Rahmen einer fünftägigen internen Intermission Ende Oktober 2025 hat ein Team von Senacor-Berater:innen drei Werkzeuge aus dem Umfeld des Spec-Driven Development einem praxisnahen Test unterzogen. Als Anwendungsfall diente ein leichtgewichtiges Tool zum Matching von Tutoren und Tutees innerhalb der Firma. Bisher erfolgte dieses Matching über eine schlichte Excel-Tabelle, in der potenzielle Tutoren einige Basisinformationen hinterlegen konnten. Die Pflege der Daten war jedoch mühsam, die Auswahl für die Suchenden wenig intuitiv, und das Format insgesamt unattraktiv. Ziel war es daher, eine optisch ansprechende, einfach bedienbare Lösung zu entwickeln, die sowohl das Pflegen von Tutor-Profilen erleichtert als auch das Finden passender Kontakte spielerischer gestaltet.

Im Mittelpunkt standen folgende drei Tools: Power Platform Plan Designer, Power Platform Generative Pages und GitHub Spec Kit. Alle drei verfolgen den Anspruch, aus Spezifikationen in natürlicher Sprache lauffähige Anwendungen zu erzeugen. In ihrer Reife und Funktionsweise unterscheiden sie sich jedoch erheblich, insbesondere in der Frage, ob am Ende Low-Code-Komponenten oder klassischer Programmcode entsteht.

Der Power Platform Plan Designer ist als Teil der Microsoft Power Platform auf den Low-Code-Bereich ausgelegt. Der Mensch liefert eine kurze Spezifikation, auf deren Basis die KI in mehreren interaktiven Schritten eine vollständige Power Platform Lösung vorschlägt: inklusive Datenmodell, Nutzerrollen, relevanter Technologien (z. B. Model-Driven Apps, Canvas Apps, Flows, Pages und AI Agents). Diese Komponenten können anschließend einzeln generiert und manuell weiterbearbeitet werden. Die ursprüngliche Spezifikation spielt nach der Generierung keine Rolle mehr. Der Plan Designer ist damit ein klassisches Beispiel für Spec-First: Die Spezifikation dient nur als Ausgangspunkt, der erzeugte Low-Code-Output wird anschließend vom Menschen weitergeführt.

Power Platform Generative Pages sind stärker auf Benutzeroberflächen fokussiert und werden nur innerhalb bestehender Model-Driven Apps angeboten. Voraussetzung ist ein bereits angelegtes Datenmodell sowie eine Grundstruktur der App. Die Spezifikation beschränkt sich hier auf konkrete Anweisungen zur Gestaltung einzelner Seiten. Die KI erzeugt daraus React-Code, der bei Bedarf eingesehen und manuell angepasst werden kann. Auch hier wird die Spezifikation nicht erhalten. Die generierten Komponenten werden vom Menschen übernommen; Weiterentwicklung findet durch iteratives Prompting der KI statt. Das Vorgehen entspricht somit ebenfalls einem Spec-First-Ansatz, bei dem die Spezifikation als einmaliger Input dient.

Ganz anders arbeitet das Framework GitHub Spec Kit. Hier beginnt der Mensch mit einer umfangreicheren Spezifikation, die in einem strukturierten Dialog mit der KI schrittweise verfeinert wird. In fünf Phasen – Specify, Clarify, Plan, Tasks, Implement – entsteht so ein präzises, überprüfbares Anforderungsdokument, das als zentrale Quelle für die Codegenerierung dient. Der Mensch legt gemeinsam mit der KI Programmiersprachen und Frameworks fest und begleitet den Prozess aktiv durch und Feedback. Die Spezifikation bleibt erhalten, wird iterativ weiterentwickelt und bildet über den gesamten Projektverlauf hinweg das Leitdokument. Der erzeugte Code ist vollständig les- und ausführbar, aber komplex genug, dass klassisches Entwickler-Know-how weiterhin notwendig bleibt. Spec Kit folgt somit einem Spec-Anchored-Ansatz: Die Spezifikation ist tragendes Artefakt, der Code bleibt aber präsent und wird von Menschen weiterhin bearbeitet.

Toolvergleich im Detail

Die drei getesteten Tools verfolgen unterschiedliche Ansätze und adressieren jeweils spezifische Anwendungsfälle. Ein direkter Vergleich ist daher nicht in allen Punkten sinnvoll – insbesondere, weil sich die Power Platform Werkzeuge klar im Low-Code-/No-Code-Bereich positionieren, während GitHub Spec Kit klassischen Programmiercode erzeugt. Dennoch lassen sich aus dem gemeinsamen Testlauf wichtige Erkenntnisse ableiten; sowohl zur technischen Reife der Tools als auch zu ihrer praktischen Nutzbarkeit im Projektalltag.

Der Power Platform Plan Designer konnte im Praxistest die hohen Erwartungen, die durch Marketing-Versprechen geweckt wurden, nicht erfüllen. Zwar bietet das Tool eine durchgängige Nutzerführung und generiert aus einer Spezifikation komplette Power Platform Lösungen, doch die Qualität der Ergebnisse war bislang unzureichend. Datenmodelle waren oft unvollständig oder nicht schlüssig, die erzeugten Komponenten wirkten inhaltlich unverbunden und der Bezug zur ursprünglichen Spezifikation ging häufig verloren. Gleichzeitig ist wichtig zu betonen: Der Plan Designer befindet sich derzeit in einem prototypischen Zustand und wird von Microsoft aktiv weiterentwickelt (Stand: Herbst 2025). Die grundsätzliche Idee – eine ganzheitliche, KI-gestützte Orchestrierung von Low-Code-Komponenten – hat viel Potenzial. Entscheidend ist, dass der gewählte Use Case zu den Stärken des Tools passt. Bei komplexen fachlichen Anforderungen oder stark individualisierten Anwendungen stößt das Tool aktuell noch an seine Grenzen.

Power Platform Generative Pages zeigte sich im Vergleich dazu deutlich ausgereifter. Die Fähigkeit, innerhalb bestehender Model-Driven Apps auf Basis kurzer Anweisungen funktionale React-Komponenten zu generieren, machte die Umsetzung spezifischer UI-Ideen besonders schnell und intuitiv. Der Code ließ sich einsehen, anpassen und iterativ verbessern. Einschränkungen gab es vor allem im Zusammenspiel mehrerer generierter Seiten sowie bei der interaktiven Verfeinerung: Die KI reagierte nicht auf Rückfragen und begleitete den User nicht durch einen dialoghaften Austausch. Die generierten Ergebnisse litten dadurch teils unter funktionalen Schwächen, beispielweise klappte das Speichern in der Datenbank nicht auf Anhieb oder einmal gesetzte Filter auf Profile ließen sich nicht mehr entfernen. Anderseits ließen sich durch iterative Prompts diese Schwächen schnell und effektiv beheben. Für unseren Use Case war das Tool überaus hilfreich, insbesondere durch die unmittelbare Sichtbarkeit der Resultate und die schnelle Testbarkeit innerhalb der Power Platform.

GitHub Spec Kit hat uns im direkten Vergleich am meisten überzeugt. Das Tool stellt nicht nur eine KI-gestützte Codegenerierung zur Verfügung, sondern bildet einen vollständigen Entwicklungsprozess ab – von der Anforderungserhebung über die Architekturplanung bis hin zur Umsetzung in produktionsfähigen Code. Besonders beeindruckt hat uns der strukturierte Spezifikations-Workflow, der durch die wohldefinierten Phasen eine saubere, nachvollziehbare Entwicklung ermöglicht. Die Spezifikation bleibt über alle Schritte hinweg das zentrale Artefakt und wird iterativ fortgeschrieben. Zwar erfordert die Nutzung des Tools weiterhin tiefes technisches Know-how, insbesondere bei Testing und Debugging, doch die Qualität und Geschwindigkeit der Ergebnisse waren im Praxistest überzeugend. Dass dabei jede gängige Programmiersprache und jedes Framework unterstützt werden kann, macht Spec Kit äußerst flexibel.

Besonders spannend war das explorative Austesten der Tool-Fähigkeiten: Anweisungen wie „Gestalte das Frontend hübsch und cool“ führten zu verblüffend kreativen Ergebnissen, die in kürzester Zeit visuell ansprechende und funktionsfähige Oberflächen hervorbrachten. Für unseren konkreten Use Case, die Matching-Plattform für das Tutoring, waren sowohl Generative Pages als auch Spec Kit hervorragend geeignet. Beide Tools erlaubten es uns, innerhalb weniger Tage funktionale Prototypen zu erstellen, die nicht nur technisch lauffähig waren, sondern auch fachlich überzeugten. Die Geschwindigkeit, mit der wir zu Ergebnissen kamen, und die Qualität der generierten Oberflächen und Funktionen, haben uns nachhaltig begeistert.

Fazit & Ausblick

Die getesteten Tools haben sehr unterschiedliche Reifegrade und Zielsetzungen. Ein direkter Vergleich ist daher nur bedingt sinnvoll. Für unseren konkreten Anwendungsfall waren insbesondere Generative Pages und GitHub Spec Kit besonders gewinnbringend. Beide Werkzeuge haben durch hohe Umsetzungsgeschwindigkeit, klare Spezifikationsorientierung und überraschend hochwertige Ergebnisse in kurzer Zeit überzeugt.

Aus Sicht von Senacor liegt das kurzfristige Potenzial von Spec-Driven Development klar in der schnellen Erstellung von Prototypen und Proofs of Concept. Wenn es darum geht, in wenigen Tagen eine funktionale Anwendung auf Basis einer grob umrissenen Idee zu erstellen, sind SDD-Tools bereits heute ein echter Produktivitätsbooster. Die Fähigkeit, aus klar beschriebenen Anforderungen sofort nutzbare Anwendungen zu generieren, eröffnet neue Möglichkeiten in der frühen Projektphase – etwa zur Validierung von Ideen, zur Kundenkommunikation oder zur Anforderungsanalyse.

Mittel- und langfristig erwarten wir, dass sich SDD-Ansätze in der Softwareentwicklung auch in größeren und etablierten Projekten zum Einsatz kommen werden – nicht als Ersatz, sondern als Ergänzung klassischer Entwicklungsprozesse. Gerade an klar abgegrenzten, stabilen Komponenten oder bei der Einführung neuer Funktionen sehen wir großes Potenzial SDD-Tools produktiv und effizient einzusetzen. Entscheidend wird dabei nicht nur die Weiterentwicklung der Werkzeuge selbst sein, sondern auch, wie gut sie sich in bestehende Prozesse und Teamstrukturen integrieren lassen. Gleichzeitig wird für den Einsatz in produktionskritischen Umgebungen ein leistungsfähiges, verlässliches Qualitätssicherungssystem unerlässlich sein. Da SDD im Kern ein probabilistischer Ansatz bleibt, braucht es Testautomatisierung, um Reproduzierbarkeit, Stabilität und Softwarequalität auf effiziente Weise sicherzustellen.

Die Geschwindigkeit, mit der sich die Tools derzeit weiterentwickeln, stimmt uns dabei optimistisch. Zwischen dem Marktstart der Tools im Sommer 2025 und unserem Test Ende Oktober desselben Jahres lagen nur wenige Monate und dennoch war bereits ein erstaunlicher Funktionsumfang und praktischer Nutzen erkennbar. Sowohl innerhalb der Microsoft Power Platform als auch rund um GitHub Spec Kit findet eine intensive Weiterentwicklung statt. Wir erwarten daher eine schnelle Professionalisierung der Ansätze.

Gleichzeitig ist klar: Der höchste SDD-Reifegrad Spec-as-Source wird nicht kurzfristig Realität. Nicht weil die Technologie fehlt, sondern weil der notwendige Paradigmenwechsel auf menschlicher Ebene stattfindet. Rollen, Prozesse, Zusammenarbeit und Verantwortlichkeiten müssen neu gedacht werden. Technologische Innovation allein genügt nicht. Es braucht Zeit, bis sich neue Herangehensweisen in der Breite etablieren. Genau deshalb lohnt es sich, jetzt erste Erfahrungen zu sammeln.

SDD klingt spannend?

Den Artikel zu den Grundlagen des SDD gibt es auch auf dem Senacor Blog.