Spec-driven Development: Anforderungen, die eine KI umsetzt

Spec-driven Development bedeutet, ein Software-Vorhaben zuerst präzise zu spezifizieren — und es erst dann implementieren zu lassen. Was nach einer Selbstverständlichkeit klingt, ist im KI-Zeitalter zum eigentlichen Qualitätshebel geworden: KI-Werkzeuge schreiben Code schneller, als ihn jemand Zeile für Zeile prüfen könnte. Damit entscheidet nicht mehr die Tippgeschwindigkeit über das Ergebnis, sondern die Klarheit der Spezifikation, die dem Code zugrunde liegt.

Dieser Beitrag zeigt, was eine gute Spezifikation heute leisten muss, was hineingehört — und warum erfahrene Software-Architekten genau hier den größten Unterschied machen.

Was Spec-driven Development bedeutet

Im Kern dreht der Ansatz die Reihenfolge um, in der viele Projekte arbeiten. Nicht „wir fangen an zu bauen und sehen, wohin es führt”, sondern: Das zentrale Artefakt ist die Spezifikation — sie beschreibt, was entstehen soll, wie es architektonisch aussehen muss und welche Bedingungen gelten. Der Code ist das nachgelagerte Ergebnis dieser Spezifikation, nicht ihr Ersatz.

Das ist keine Rückkehr zum 200-seitigen Pflichtenheft von früher. Eine moderne Spezifikation ist schlank, präzise und lebt neben dem Code — sie wird versioniert, verfeinert und gegen die Realität gehalten. Entscheidend ist nicht ihr Umfang, sondern dass sie genau die Entscheidungen festhält, die später teuer werden, wenn sie offen bleiben.

Warum die Spezifikation im KI-Zeitalter den Ausschlag gibt

Eine KI fragt nicht von alleine nach. Sie nimmt einen Prompt, füllt die Lücken mit plausiblen Annahmen und produziert Code, der oberflächlich funktioniert. Wo die Spezifikation vage ist, rät das Modell — und es rät nach dem Durchschnitt seiner Trainingsdaten, nicht nach den Eigenheiten Ihres Geschäfts.

Die wertvolle Arbeit hat sich dadurch verschoben: weg von der Tastatur, hin zum Entwurf. Wir haben das ausführlicher in Wie KI die moderne Softwareentwicklung verändert beschrieben. Die praktische Konsequenz für jedes Projekt ist dieselbe: Was nicht spezifiziert ist, wird nicht zuverlässig gebaut — es wird geraten. Und geratene Annahmen tauchen selten beim ersten Demo auf. Sie tauchen in Monat neun auf, unter Last, mit echten Daten.

Was in eine tragfähige Spezifikation gehört

Eine Spezifikation, an der eine KI sauber arbeiten kann, benennt die Entscheidungen, die das Modell sonst überspringt:

• Datenmodell mit Wachstums-Horizont. Nicht nur die Tabellen für heute, sondern die Frage, wie sich Datenmengen und Beziehungen über Jahre entwickeln — inklusive Indizes und Skalierungspfad.
• Schnittstellen und ihre Versionierung. Wie sich eine API verändern darf, ohne bestehende Integrationen zu brechen — festgelegt vor dem ersten Endpoint.
• Fehler- und Eckfälle. Was passiert bei Timeout, Retry, Idempotenz, beim Abbruch mitten im Workflow? Diese Pfade gehören in die Spezifikation, nicht in den Hotfix nach Live-Gang.
• Nicht-funktionale Anforderungen. Last, Antwortzeiten, Sicherheit, DSGVO-Footprint, Audit-Logs. Das sind keine Features, die man am Schluss reindrückt — sie prägen Datenmodell und Architektur.
• Akzeptanzkriterien. Eine präzise Definition von „fertig”, idealerweise so formuliert, dass sie sich gegen Tests prüfen lässt.
• Explizite Trade-offs. Modularer Monolith oder Microservices? Server-seitiges Rendering oder SPA? Eine KI hat dazu keine Meinung — sie baut, was der Prompt sagt. Die Entscheidung muss vorher fallen.

Diese Punkte landen entweder vorne in der Spezifikation — oder als teure Lektion später im Betrieb.

Spezifikation ist kein Pflichtenheft von 2005

Der Reflex bei „mehr spezifizieren” ist oft die Angst vor schwerfälliger Dokumentation. Berechtigt — aber Spec-driven Development meint das Gegenteil von Bürokratie. Eine gute Spezifikation ist:

• schlank — sie hält Entscheidungen fest, nicht jede Trivialität;
• lebendig — sie wird mit dem Projekt versioniert und verfeinert, statt einmal abgenommen und vergessen;
• überprüfbar — Akzeptanzkriterien lassen sich gegen automatisierte Tests spiegeln, sodass „erfüllt die Spec” mehr ist als eine Meinung.

Es geht nicht um Seitenzahl, sondern um Präzision an den richtigen Stellen.

Wie wir bei Tech42 spezifikationsgetrieben arbeiten

In der Praxis beginnt das vor der ersten Codezeile. Eine Discovery-Phase zum Festpreis schärft Anforderungen, Architektur und Aufwand und produziert ein belastbares Backlog — die Spezifikation, an der dann gebaut wird. Diese Reihenfolge ist auch der Grund, warum sich auf dieser Basis ein Werkvertrag sauber schneiden lässt: Wer den Scope geklärt hat, kann ihn verbindlich zusagen.

Im Bau selbst trägt die Spezifikation direkt in den KI-Workflow hinein — über projektweite Regeln und wiederverwendbare Vorgaben, die der KI den Kontext mitgeben, den ein Prompt allein nicht transportiert (wie wir es in Claude Code im Team einrichten beschrieben haben). Der entscheidende Schritt am Ende ist die Verifikation gegen die Spezifikation — nicht gegen „sieht plausibel aus”. Verantwortlich für diese Spezifikation ist ein Software-Architekt: jemand, der aus Erfahrung weiß, welche Annahme in zwei Jahren zum Problem wird.

Wie konkret das aussieht, zeigt unsere Arbeit am MOBEX Service Portal: Dass die Plattform von Anfang an KI-ready geschnitten wurde — klare Service-Grenzen, eine event-basierte Architektur, konsistente Datenzugriffe —, war eine bewusste Entscheidung in der Architektur, kein nachträglicher Anbau. Genau solche Vorab-Entscheidungen sind die Spezifikation, an der dann gebaut wird.

Was das für Ihr Projekt bedeutet

Wenn Sie 2026 ein Software-Projekt vergeben, ist die aufschlussreichste Frage an einen potenziellen Partner nicht „Welche KI-Tools nutzt ihr?”. Das tun inzwischen alle. Aufschlussreicher ist: Wer spezifiziert was, und wie wird das Ergebnis gegen die Spezifikation geprüft? Genau hier trennt sich tragfähige Software von Code, der nur beim ersten Hinsehen funktioniert — die andere Seite derselben Medaille beschreiben wir in Vibe Coding ist nicht das Problem — Vibe Spec’ing ist es.

Spec-driven Development ist kein Methoden-Dogma. Es ist die nüchterne Einsicht, dass eine KI nur so gut bauen kann, wie das, was man ihr vorgibt — und dass das Vorgeben die eigentliche Ingenieursleistung ist.

---

Sie stehen vor einem Vorhaben, das von Anfang an tragfähig sein muss — und wollen nicht erst in Monat neun merken, was niemand spezifiziert hat? Wir schärfen Anforderungen, Architektur und Aufwand in einer Discovery-Phase zum Festpreis und bauen daraus individuelle Softwareentwicklung für den Mittelstand, die auf einer Software-Architektur als Fundament steht. Den Rahmen dafür klären wir im kostenlosen Erstgespräch.