Spec Driven Development: Wie wir bei Break mit KI-Agenten Software entwickeln

Software-Projekte scheitern selten an fehlendem Code. Sie scheitern an Missverständnissen. Anforderungen, die nie klar formuliert wurden. Features, die am Bedarf vorbeigehen. Und Entwickler, die erst beim Testen merken, dass die Businesslogik nicht stimmt.

Spec Driven Development (SDD) ist kein neues Konzept. Der Ansatz, Spezifikationen ins Zentrum der Entwicklung zu stellen, ist in der Branche etabliert. Was wir bei Break GmbH gemacht haben: Wir haben SDD konsequent in unseren Workflow integriert und mit KI-Agenten kombiniert. Dieser Blog zeigt, wie wir das in der Praxis umsetzen, von der ersten Kundenanforderung bis zum getesteten Feature.

Was ist Spec Driven Development?

Spec Driven Development stellt die Spezifikation ins Zentrum des gesamten Entwicklungsprozesses. Nicht als statisches Dokument, das einmal geschrieben und dann vergessen wird, sondern als lebendige Quelle der Wahrheit, die sich mit dem Projekt weiterentwickelt.

Das Herzstück bildet ein Business Logic Master File: ein zentrales Dokument, das sämtliche Geschäftslogik, Regeln und Anforderungen enthält. Dieses File lebt: Es wird kontinuierlich gepflegt, erweitert und ist die einzige verbindliche Referenz für alle am Projekt Beteiligten, ob Mensch oder KI.

SDD beginnt nicht beim Code, sondern beim ersten Gespräch

Spec Driven Development startet lange bevor ein Agent eine Zeile Code schreibt. Es beginnt bereits in den ersten Kundengesprächen und Workshops. Dort erfassen wir gemeinsam mit dem Kunden die Geschäftsprozesse, Regeln, Ausnahmen und Prioritäten, oft in Form von Whiteboards, Gesprächsnotizen und strukturierten Fragerunden. Diese Erkenntnisse werden systematisch aufbereitet und fliessen direkt in das Business Logic Master File ein. So entsteht das lebende Dokument nicht aus Annahmen, sondern aus echtem Domänenwissen, getragen von den Menschen, die das Geschäft jeden Tag leben. Je gründlicher diese Phase, desto präziser arbeiten später die Agenten.

Was steht im Business Logic Master File?

Das Business Logic Master File beschreibt die komplette Geschäftslogik eines Projekts, nicht als technische Dokumentation, sondern als fachliche Wahrheit. Hier wird festgehalten, wie Prozesse ablaufen, welche Regeln gelten, welche Ausnahmen es gibt und warum bestimmte Entscheidungen getroffen wurden. Jede Geschäftsregel, jede Bedingung, jeder Sonderfall hat seinen Platz.

Entscheidend dabei: Das File muss immer aktuell sein. Ändert sich eine Geschäftsregel, wird zuerst das Master File angepasst, nicht der Code. Wird im Gespräch mit dem Kunden eine neue Anforderung definiert oder eine bestehende Regel verworfen, wird das sofort dokumentiert. So gibt es zu jedem Zeitpunkt eine einzige, verlässliche Quelle, die den aktuellen Stand der Fachlogik abbildet.

Auch getroffene Entscheidungen werden explizit festgehalten, inklusive der Begründung. Nicht nur was entschieden wurde, sondern warum. Das verhindert, dass Monate später dieselben Diskussionen erneut geführt werden, und gibt den Agenten den nötigen Kontext, um fundierte Vorschläge zu machen.

Unsere Agenten: Spezialisierte Experten für jede Domäne

Um Spec Driven Development in der Praxis umzusetzen, haben wir spezialisierte KI-Agenten entwickelt. Jeder Agent ist ein Experte in seiner Domäne, mit klaren Zuständigkeiten und einem definierten Fokus:

Der Workflow: Von der Idee zum getesteten Feature

Unser SDD-Workflow folgt einer klaren Abfolge, bei der jeder Schritt auf dem vorherigen aufbaut:

1. Anforderungen definieren: Business Analyst Agent

Der Business Analyst Agent erstellt aus dem Master File die gesamte Anforderungsstruktur:

• Epic: Die übergeordnete Initiative
• Feature: Konkrete Funktionalitäten innerhalb des Epics
• User Stories: Detaillierte, testbare Anforderungen aus Nutzersicht

Der Entwickler prüft und verfeinert diese Struktur. Erst wenn sie stimmig ist, geht es weiter.

2. Backend entwickeln: Backend Agent (Planner → Executor)

Der Backend Agent arbeitet in zwei Modes:

Planner Mode: Zuerst analysiert der Agent die User Stories und erstellt einen detaillierten Implementierungsplan, welche Dateien betroffen sind, welche Endpunkte erstellt oder angepasst werden, wie die Datenflüsse aussehen. Dieser Plan wird dem Entwickler vorgelegt.

Executor Mode: Erst wenn der Entwickler den Plan freigegeben hat, implementiert der Agent den Code. Schritt für Schritt, nachvollziehbar, auf Basis des genehmigten Plans.

3. Frontend entwickeln: Frontend Agent (Planner → Executor)

Analog zum Backend arbeitet auch der Frontend Agent in zwei Phasen:

Planner Mode: Der Agent analysiert die User Stories und den bereits implementierten Backend-Code, dann erstellt er einen Implementierungsplan für die Benutzeroberfläche: Komponenten, Routing, State Management, API-Anbindung.

Executor Mode: Nach der Freigabe durch den Entwickler wird der Plan umgesetzt. Da der Frontend Agent den Backend-Code bereits kennt, passt die Integration von Anfang an.

4. Testen: Test Agent

Der Test Agent erstellt und führt Tests auf allen Ebenen aus: Unit Tests, Integrationstests und End-to-End Tests. Er arbeitet direkt gegen die implementierten User Stories und stellt sicher, dass jede Anforderung abgedeckt ist.

5. Sicherheit prüfen: Security Champion Agent

Zum Abschluss analysiert der Security Champion Agent den gesamten Code auf Sicherheitslücken: Injection-Risiken, fehlerhafte Authentifizierung, unsichere Datenverarbeitung, OWASP Top 10 und mehr. Findings werden dokumentiert und müssen behoben werden, bevor das Feature als abgeschlossen gilt.

Der Mensch bleibt im Loop, immer

Das ist kein Sicherheitsnetz, das wir notgedrungen eingebaut haben. Es ist ein bewusstes Designprinzip. KI beschleunigt die Arbeit enorm, aber die Verantwortung für die Qualität und Korrektheit des Codes liegt beim Menschen. Die Agenten sind Werkzeuge, keine autonomen Entscheider.

In der Praxis sieht das so aus:

• Business Analyst erstellt User Stories → Entwickler prüft und bestätigt
• Backend Agent erstellt Implementierungsplan → Entwickler prüft und gibt frei
• Backend Agent implementiert Code → Entwickler reviewed und akzeptiert
• Gleiches beim Frontend, bei Tests, bei Security

Warum Spec Driven Development funktioniert

Klarheit von Anfang an. Durch das Business Logic Master File und die strukturierte Anforderungsanalyse sind Missverständnisse minimiert, bevor die erste Zeile Code entsteht.

Konsistenz über Domänen hinweg. Alle Agenten arbeiten mit derselben Spezifikation. Backend und Frontend sprechen dieselbe Sprache, weil sie aus derselben Quelle arbeiten.

Qualität durch Struktur. Der Planner-Executor-Ansatz verhindert, dass direkt drauflos programmiert wird. Der Plan wird erst geprüft, dann umgesetzt, ein eingebauter Qualitätsgate.

Geschwindigkeit mit Kontrolle. Die Agenten erledigen die Fleissarbeit: Boilerplate, Standardmuster, Testabdeckung. Der Entwickler konzentriert sich auf Architekturentscheide, Edge Cases und Businesslogik.

Sicherheit als fester Bestandteil. Security ist kein Afterthought, sondern ein fixer Schritt im Workflow. Jedes Feature durchläuft eine Sicherheitsprüfung.

Fazit

Spec Driven Development ist keine Revolution. Es ist die konsequente Anwendung eines Prinzips, das in der Softwareentwicklung schon immer galt: Zuerst verstehen, dann bauen. KI-Agenten machen es möglich, dieses Prinzip in einer Geschwindigkeit und Konsistenz umzusetzen, die vorher nicht realisierbar war.

Bei Break nutzen wir SDD bereits in unseren Kundenprojekten. Die Erfahrung zeigt: Der initiale Aufwand, spezialisierte Agenten und ein Business Logic Master File aufzusetzen, zahlt sich schnell aus, durch weniger Missverständnisse, konsistenteren Code und schnellere Iterationen.