Was versteht man unter spezifikationsgesteuerter Entwicklung?

Durch die Verfügbarkeit von KI-Tools und Codierungsassistenten wie GitHub Copilot von Microsoft, Claude Code von Anthropic oder Bob von IBM sind die Einstiegshürden für die Codegenerierung gesunken. Ein LLM-gestützter KI-Agent , der ausgeklügelte KI-Modelle verwendet, kann eine Reihe von iterativen Aufgaben in Echtzeit ausführen, alles mit einem einzigen Prompt des Benutzers.

Für die Softwareentwicklung bedeutet dies, dass wir den Entwicklungs-Workflow für die Erstellung von Prototypen, neuen Funktionen, Unit-Tests und weiteren Aufgaben optimieren und automatisieren können. Noch nie war es einfacher, Code zu generieren. Es gibt jedoch eine Gefahr, der sich Vibe-Codierer bewusst sein sollten: KI ist nur so gut wie die Anweisungen, die sie erhält. 

Wahrscheinlich sind Sie in der Praxis bereits mit technischer Verschuldung in Berührung gekommen, vielleicht ohne es überhaupt zu bemerken. Technische Schulden gab es schon vor der „Vibe-Codierung“ und sind seit Jahrzehnten ein fester Bestandteil der Softwareentwicklung; sie entstehen, wenn im Namen der Geschwindigkeit Abkürzungen genommen werden. Allerdings beschleunigt die „Vibe-Codierung“ den Aufbau technischer Schulden, da sie die Erstellung großer Mengen an Code erleichtert, ohne dass dieser vollständig verstanden oder überprüft wird. Möglicherweise besteht Druck, das Produkt schnell auf den Markt zu bringen, oder dem „Vibe-Coder“ fehlt schlichtweg das technische Hintergrundwissen, um technische Schulden zu verhindern, bevor sie entstehen.  

Technische Schulden bei der KI-gestützten Entwicklung können verschiedene Formen annehmen: 

• Context drift tritt auf, wenn ein Fix in einem Bereich unbeabsichtigt die Funktionalität in einem anderen Bereich beschädigt – ein Symptom von Code, der ohne vollständiges Verständnis des Gesamtsystems generiert wurde.  
• Fragmentierung ist eine weitere häufige Manifestation, bei der neu generierte Funktionen nicht mit den bestehenden architektonischen Konventionen übereinstimmen, wodurch die Konsistenz und Wartbarkeit der Codebasis allmählich untergraben wird.  
• Es sind auch Betriebskosten zu berücksichtigen. Ohne eine klare Spezifikation, die den Generierungsprozess festlegt, können Entwickler in langwierige Prompt-Zyklen geraten. Dieser Ansatz kann Tausende von Tokens verbrauchen, um Fehler zu beheben, die durch eine klar definierte Spezifikation gänzlich hätten vermieden werden können. 

Stellen Sie sich ein Szenario vor, das vielen Entwicklern in der Branche gut bekannt ist. Sie arbeiten bereits seit mehreren Tagen oder Wochen an einer neuen Funktion, die nun fast bereit für das Release ist. Dann, unter dem Druck einer näher rückenden Frist, führen Sie die letzten Feinabstimmungen in aller Eile durch eine Reihe von durch KI angestoßenen Änderungen durch.

Die Funktionen des generierten Codes, egal ob er in Python oder einer anderen Sprache geschrieben ist, mögen aus der Sicht des Benutzers in Ordnung erscheinen. Dabei wurden jedoch mehrere Sicherheitslücken aufgedeckt, Abhängigkeitskonflikte eingeführt und die Handhabung und das Testen von Edge-Cases völlig vergessen.

Eine im Voraus festgelegte formale Spezifikation gibt dem Team eine gemeinsame Datengrundlage, um jede Phase des Softwareentwicklungslebenszyklus (SDLC) zu steuern, unabhängig davon, wer den Code geschrieben hat. 

Es gibt verschiedene Ansätze und Vorlagen für die spezifikationsgesteuerte Entwicklung, die sich hinsichtlich des Aufwands für die Wartung der Spezifikationen und der damit verbundenen Kompromisse unterscheiden. Die richtige Wahl hängt nicht von einer strikten „besseren“ Vorgehensweise ab, sondern von Ihrer Codebasis, Ihrem Team und dem jeweiligen Problembereich. Berücksichtigen Sie die Bedürfnisse und Einschränkungen Ihres Teams, bevor Sie sich für eine Option entscheiden.

Bei der spezifikationsorientierten Entwicklung werden Spezifikationen erstellt, bevor Code generiert wird, und zwar in Form von Benutzergeschichten, Akzeptanzkriterien oder einem formalen Anforderungsdokument. Sobald die anfängliche Klarheit geschaffen und der Code generiert ist, wird die Spezifikation nicht unbedingt beibehalten. Die Spezifikation könnte im Zuge der Weiterentwicklung der Software veralten. Der Hauptzweck bestand darin, zunächst Klarheit zu schaffen, ohne dass die Spezifikation fortlaufend gepflegt werden musste. Dieser Aspekt gilt als „Einstiegspunkt zu SDD“.¹

Bei der spezifikationsorientierten Entwicklung entwickelt sich die Spezifikation parallel zur Software. Wenn sich die Anforderungen ändern und neue Funktionen hinzugefügt werden, wird die Spezifikation aktualisiert, um den aktuellen Stand des Systems widerzuspiegeln. Dies ist besonders nützlich für Projekte, die im Rahmen größerer Initiativen durchgeführt werden.

Automatisierte Tests bilden die Brücke zwischen Dokumentation und Implementierung und werden oft in eine CI/CD-Pipeline integriert, um sicherzustellen, dass beide während des gesamten Entwicklungslebenszyklus synchron und ausführbar bleiben. Dieses Gleichgewicht zwischen Struktur und Flexibilität macht die spezifikationsorientierte Entwicklung für die meisten Ingenieurteams zu einem praktischen und skalierbaren Ansatz.¹

Am äußersten Ende des Spektrums steht die spezifikationsbasierte Entwicklung („Spec-as-Source“) – die Form, bei der der Schwerpunkt am stärksten auf KI liegt. Bei der „Spec-as-Source“-Entwicklung lösen Änderungen an der Spezifikation automatisch Änderungen am Code aus. Kein Mensch führt jemals direkt eine Code-Umgestaltung durch.

Ein derart hohes Maß an Spezifikationshoheit erfordert großes Vertrauen in die Qualität und Konsistenz der Pipeline zur Generierung von KI-Code, die bis heute von Natur aus nichtdeterministisch ist. In der Praxis bedeutet dies, dass sie ohne strenge menschliche Aufsicht weniger streng sein kann. Bevor sie diesen Ansatz umsetzen, sollten Teams den Reifegrad ihres Tech-Stacks und ihres Spezifikations-Kits, die Kritikalität der beteiligten Systeme sowie ihre Fähigkeit zur Validierung von KI-generierten Ergebnissen sorgfältig bewerten.¹

In der Praxis verwenden viele Teams hybride Ansätze:

• Die Behandlung von Spezifikationen als stapelbare versionierte Artefakte, ähnlich wie Architekturentscheidungsdokumente (Architecture Decision Records, ADRs), anstatt sie stets auf dem neuesten Stand zu halten.
• Externe Systeme (zum Beispiel Issue Tracker) als Wahrheitsquelle zu nutzen, um eine intentionale Trennung einzuführen.
• Vermeidung starker Automatisierung bei hochkomplexen oder von der Community betriebenen Projekten, bei denen eine strenge Kontrolle über Änderungen entscheidend ist.

Jeder Ansatz hat seine Stärken und Grenzen; der Kontext ist wichtiger als die strikte Einhaltung eines bestimmten Modells.

Je nach gewünschter Spezifikationsautorität kann eine effektive Spezifikation anders aussehen. Wenn Sie jedoch davon ausgehen, dass Sie sich irgendwo in der Mitte des Spektrums befinden und sich für die spezifikationsgestützte Entwicklung entscheiden, sollte eine Spezifikation klar und in testbaren Begriffen beschreiben, was das System leisten muss. Diese Spezifikation vermeidet eine voreilige Festlegung auf eine konkrete Umsetzungsmethode.

Die Spezifikation sollte so detailliert sein, dass sie Definitionen der Eingabe und Ausgabe, das Datenschema, Edge und Erfolgskriterien enthält. Sie sollte jedoch flexibel genug sein, um sich weiterzuentwickeln, sobald man das Problem besser versteht. Vor allem sollte eine gute Spezifikation die Entwicklung beschleunigen: Wenn sie Ihnen nicht dabei hilft, schneller besseren Code zu schreiben oder Missverständnisse zu vermeiden, ist sie wahrscheinlich detaillierter, als nötig. 

Um zu veranschaulichen, wie eine effektive Spezifikation in der Praxis aussieht, betrachten Sie dieses Beispiel für eine Benutzerauthentifizierungsfunktion: 

Sie implementieren eine Benutzer-Login-Funktion für eine Web-Anwendung.  
Verwenden Sie die folgende Spezifikation als Ihre Single-Source-of-Truth (SSOT).  
Machen Sie keine Annahmen über Anforderungen, die hier nicht aufgeführt sind. 
 
FUNKTION: Benutzeranmeldung 
 
ÜBERBLICK: 
 Ermöglichen Sie registrierten Benutzern die sichere Authentifizierung über ihre E-Mail-Adresse  
 und ihr Passwort. 
 
ZULASSUNGSKRITERIEN: 
1. Das Anmeldeformular muss die Eingabe einer E-Mail-Adresse und eines Passworts akzeptieren 
 2. Wenn die Anmeldedaten gültig sind, leiten Sie den Benutzer zum Dashboard weiter 
3. Wenn die Anmeldedaten ungültig sind, zeigen Sie eine generische Fehlermeldung an  
   ohne anzugeben, welches Feld falsch ist 
4. Sperren Sie das Konto für 15 Minuten nach 5 aufeinanderfolgenden fehlgeschlagenen Anmeldeversuchen 
 5. Passwörter nur über HTTPS übertragen – niemals im Klartext speichern 
 

AUSSERHALB DES GELTUNGSBEREICHS: 
- Soziale Anmeldung (OAuth) 
- Zwei-Faktor-Authentifizierung 
- Ablauf zum Zurücksetzen des Passworts 
 
EDGE-FÄLLE: 
- Vor dem Absenden leere Felder clientseitig auffangen 
- Leiten Sie abgelaufene Sitzungen mit einer Informationsnachricht auf die Anmeldeseite um 
- Das Formular muss funktionsfähig bleiben, wenn JavaScript deaktiviert ist 
 
Beginnen Sie erst mit der Implementierung, wenn Sie Ihr Verständnis  
der Akzeptanzkriterien bestätigt haben.

Diese ähneln den funktionalen Spezifikationen, die Produktmanager verfassen, beschränken sich jedoch streng auf das, was die Implementierung umfassen muss, bzw. auf deren Abnahmekriterien, sowie darauf, wie Edge-Fälle elegant gehandhabt werden sollen.

In der Regel würde diese Spezifikation im Projekt-Repository („Repo“) auf GitHub als Markdown-Datei wieSPEC.md oder /docs/auth-login.md gespeichert werden, die zusammen mit dem Quellcode über Git versioniert wird. Der AI Coding Agent kann darauf zugreifen, indem der Benutzer sie in den Prompt einfügt oder, vorzugsweise, indem er über eine Befehlszeilenschnittstelle (CLI) auf die Datei verweist und der Agent sie aus dem Projektverzeichnis liest. Zum Beispiel: „Implementieren Sie die in /docs/auth-login.md beschriebene Funktion.“

In stärker automatisierten Pipelines wird die Spezifikationsdatei zu Beginn der Aufgabe als Teil des System-Prompts oder des Kontextfensters übergeben, wodurch der Agent seine Anweisungen erhält, bevor er mit der Arbeit beginnt.

So viel Zeit und technische Schulden Ihnen die spezifikationsgesteuerte Entwicklung auch ersparen mag, so ist es doch wichtig, sich vor Augen zu halten, dass man möglicherweise zu viel Zeit mit „Over-Engineering“ verbringt. Wenn Sie drei Wochen lang über den Namen eines einzelnen JSON-Schlüssels oder über bestimmte API-Endgeräte für eine Funktion diskutieren, die möglicherweise schon in einem Monat wieder entfernt wird, verfehlt dies den Zweck der spezifikationsgesteuerten Entwicklung.  

Konzentrieren Sie sich nicht zu sehr darauf, jede nur denkbare Zukunft zu modellieren. Bevorzugen Sie übersichtliche, sich weiterentwickelnde Spezifikationen gegenüber erschöpfenden, „endgültigen“ Spezifikationen. Schreiben Sie das, was Sie benötigen, um voranzukommen, validieren Sie es zügig im Code und passen Sie es an, sobald sich die Gegebenheiten ändern. Als allgemeiner Grundsatz gilt, dass die Kosten für die Präzisierung der Spezifikation stets geringer sein sollten als die Kosten für die Behebung von Missverständnissen bei der Umsetzung. Wenn sich dieses Verhältnis umkehrt, ist dies ein Signal, mit der Feinabstimmung aufzuhören und mit der Umsetzung zu beginnen.

Mit dem Aufkommen von AI Coding lösten testgetriebene Entwicklung (Test-Driven Development, TDD) und verhaltensgesteuerte Entwicklung (Behavior-Driven Development, BDD) eine neue Welle aus: die spezifikationsgesteuerte Entwicklung. Während TDD von den Entwicklern verlangt, erwartete Ergebnisse anhand von Tests zu definieren, und BDD von ihnen verlangt, das Verhalten im Rahmen einer Zusammenarbeit zu definieren, stellt die spezifikationsgesteuerte Entwicklung zunächst eine grundlegendere Frage: Haben wir klar definiert, was wir entwickeln und für wen?^{2, 3}

Da KI-Agenten einen immer größeren Teil der Umsetzungsarbeit übernehmen, steht die Qualität dieser Arbeit in direktem Verhältnis zur Qualität der Anweisungen, die sie erhalten. Eine gut verfasste Spezifikation schränkt den Entwicklungsprozess nicht ein, sondern beschleunigt ihn vielmehr im Rahmen moderner Softwaresysteme.