Entwicklungsprozesse gesteuert durch Spezifikationen mit KI-Programmieragenten: Ein praktischer Leitfaden
Entwicklung gesteuert durch Spezifikationen mit KI-Code-Agenten: ein vierphasiger Arbeitsablauf, AGENTS.md- und SPEC.md-Dateien, Rollen mehrerer Agenten, Reifegradstufen sowie Methoden zur Erkennung von Abweichungen.
Quellen: Spec-Driven Development with AI Coding Agents: The Definitive Guide
Tools wie Claude Code, GitHub Copilot, Cursor und Windsurf erzeugen, strukturieren und testen Code nun viel schneller als ein Mensch es könnte. Geschwindigkeit ohne Präzision wird jedoch oft zu einem Nachteil. Viele Teams, die diese Tools nutzen, arbeiten in einem Teufelskreis aus Anfragen stellen, Ergebnisse erhalten, Fehler beheben und erneut anfragen – dieser Kreislauf verschlechtert sich mit der Größe der Codebasis. Die Ursache liegt in der Regel nicht am Modell, sondern daran, dass niemand eine disziplinierte Methode hat, dem Agenten klarzumachen, was gewünscht wird.
Spezifikationsgetriebene Entwicklung (SDD) ist eine Lösung. Dabei wird eine strukturierte Spezifikation als Hauptprodukt des Entwicklungsprozesses betrachtet: das Dokument, aus dem der Code abgeleitet, überprüft und gesteuert wird.
Die konzeptionelle Grundlage
Warum Vibe Coding versagt
„Vibe Coding“ bedeutet, das gewünschte Ergebnis auf conversative Weise zu beschreiben und die Ausgabe mithilfe informeller Nachfragen zu steuern. Es eignet sich gut für isolierte Aufgaben, schnelle Prototypen und Experimente in einer einzigen Sitzung. Bei größeren Skalen versagt es jedoch stark, und der Grund dafür ist verständlich.
Kontextverfall
Jede Sitzung findet innerhalb eines Kontextfensters statt – also der begrenzten Menge an Informationen, über die der Agent zur gleichen Zeit nachdenken kann. Beim Vibe Coding existiert der Zustand des Projekts nur im Chatverlauf. Wenn das Gespräch länger dauert, geraten frühe architektonische Entscheidungen, Sicherheitsbeschränkungen sowie Bibliothekswahl außer Acht. Der Agent ersetzt sie dann oft durch plausibel erscheinende Alternativen, ohne dies explizit zu erwähnen. Das ist der Kontextverfall.
Das typische Symptom ist die Implementierungsverschiebung: eine allmähliche Trennung zwischen dem, was der Agent für seine Entwicklung hält, und dem, was das Unternehmen ursprünglich verlangt hat. Der Code besteht seine Tests, funktioniert eigenständig und sieht in Ordnung aus, bricht jedoch später strukturelle oder geschäftliche Regeln, die zuvor festgelegt wurden. In Unternehmenssystemen ist dies die Art von Defekt, die am schwierigsten zu diagnostizieren und am teuersten zu beheben ist.
Die Kernidee
SDD basiert auf einem architektonischen Prinzip: Die Spezifikation ist das primäre Dokument, und die Implementierung leitet sich daraus ab. Das geht über eine einfache Anpassung des Arbeitsablaufs hinaus. Es kehrt das traditionelle Modell um, bei dem zunächst der Code entsteht und die Dokumentation erst folgt.
Bei diesem Ansatz ist die Spezifikation maschinenlesbar, versioniert, dynamisch und ausführbar. Sie dient als Vertrag zwischen der Absicht des Menschen und der Ausführung durch den Agenten, wodurch der Agent innerhalb der Grenzen dieses Vertrags arbeitet anstatt zu raten. Ein präziser Vertrag führt zu vorhersehbarem Output, während ein unklarer Vertrag zu Abweichungen führt. Kurz gesagt: Man kann nicht kontrollieren, was ein Agent erstellt, bevor man genau definiert hat, was erstellt werden soll.
Sechs Elemente einer maschinenlesbaren Spezifikation
Eine für einen Agenten bestimmte Spezifikation muss die Unklarheiten der natürlichen Sprache überwinden. Die sechs Elemente, die in der Regel als notwendig angesehen werden, um zu verhindern, dass ein Agent unerwünschte Annahmen trifft, sind:
- Ergebnisse, die Ergebnisse, die die Arbeit erzielen soll.
- Ausmaß, einschließlich dessen, was ausdrücklich weggelassen wird.
Der SDD-Arbeitsablauf
Vier Phasen mit menschlichen Kontrollpunkten
Der Arbeitsablauf umfasst vier aufeinanderfolgende Phasen, wobei in jeder Phase ein Punkt vorhanden ist, an dem eine Person eingreifen muss. Diese menschlichen Kontrollpunkte sind keine Bürokratie. Sie verhindern, dass Fehler weitergegeben und verschärft werden, und das Überspringen eines solchen Punkts, um „schneller voranzukommen“, hat in der Regel das Gegenteil zur Folge.
Phase 1: Genauisierung. Der Entwickler formuliert die Überlegungen auf hohem Niveau, und entweder der Agent oder der Entwickler selbst entwickelt diese weiter zu einer strukturierten funktionalen Spezifikation – mit Nutzerprozessen, Geschäftszielen, Akzeptanzkriterien sowie klaren Umfangsgrenzen. Die Aufgabe hier besteht darin, eine architektonische Überprüfung durchzuführen, um vor Beginn jeder Planung mögliche Fehlvorstellungen, Auslassungen oder Missverständnisse im Ergebnis zu erkennen. Mit Phase 2 sollte erst begonnen werden, wenn Phase 1 frei von Unklarheiten ist: Eine vage Spezifikation führt selten zu einer vagen Umsetzung, sondern eher zu einer selbstsicheren, aber falschen Umsetzung.
Phase 2, Planung. Sobald die Spezifikation genehmigt wurde, erstellt der Agent einen technischen Plan, der Architekturentscheidungen, Datenmodelle, API-Verträge sowie Technologieauswahl umfasst. Der Plan enthält außerdem organisatorische Einschränkungen wie „Daten in PostgreSQL speichern“ oder „jeder API-Endpunkt erfordert JWT-Authentifizierung“. Eine menschliche Überprüfung zu diesem Zeitpunkt erkennt architektonische Fehler, bevor sie in die tausenden generierten Zeilen eingefügt werden.
Phase 3, Aufteilung der Aufgaben. Der genehmigte Plan wird in kleine Aufgaben unterteilt, die jeweils unabhängig getestet werden können. Die Granularität ist vermutlich die am meisten unterschätzte Variable bei SDD. Eine Aufgabe sollte in einem einzigen Agentenaufruf umsetzbar und überprüfbar sein; wenn sie den Agenten zwingt, mit mehr als etwa drei verschiedenen Aspekten gleichzeitig umzugehen, ist sie zu groß. Eine gut aufgeteilte Liste dient außerdem als Grundlage für die testgetriebene Entwicklung, da jede Aufgabe vor Beginn der Arbeit eine klare Erfolgsbedingung hat und das Projekt häufig Überprüfungspunkte bietet.
Phase 4, Implementierung und Überprüfung. Der Agent schreibt den Code Aufgabe für Aufgabe, wobei die Ergebnisse so strukturiert sind, dass sie geprüft und auf eine bestimmte Anforderung zurückgeführt werden können. In dieser Phase wird ein Verifizierermuster verwendet, bei dem ein Agent Code erzeugt und ein zweiter Agent oder ein automatisiertes Testframework diesen gegen die Akzeptanzkriterien überprüft.
Aktualisierung der Spezifikation in beide Richtungen
Eine der wichtigsten Praktiken, die jedoch oft missachtet wird, ist die bidirektionale Aktualisierung. Angenommen, in Phase 4 trifft der Agent eine Entscheidung, die von der Spezifikation nicht abgedeckt wird – beispielsweise die Wahl einer Bibliothek aus Leistungsgründen oder die Handhabung eines Randfalls auf ungewöhnliche Weise. Diese Entscheidung sollte umgehend in die Spezifikation zurückgeschrieben werden.
Falls dem nicht so ist, entsteht ein „Spezifikationsverschuldung“: Die dokumentierte Absicht weicht vom tatsächlichen Verhalten ab. Diese Abweichung verwandelt eine aktuelle Spezifikation in eine veraltete Datei, der niemand mehr vertraut und die letztendlich niemand mehr liest – sie wird genau dann nutzlos, wenn sie am meisten gebraucht wird, nämlich bei späteren, von KI unterstützten Änderungen. Die Regel ist einfach: Wenn die Implementierung von der Spezifikation abweicht, muss die Spezifikation sofort aktualisiert werden, nicht im nächsten Sprint. Die Spezifikationsverschuldung wächst schneller als die technische Verschuldung, da sie das Ausgangsmaterial für jede nachfolgende Generation beeinträchtigt.
Persistenzartefakte und die Projektverfassung
Warum Agenten eine Verfassung benötigen
Ein Programmieragent hat zwischen den Sitzungen kein Gedächtnis. Jede neue Sitzung beginnt nur mit dem, was Sie in seinen Kontext eingeben. Da es keinen Persistenzmechanismus gibt, ist jede Sitzung wie eine leere Tafel – ohne Kenntnis Ihrer Sicherheitsstandards, Namenskonventionen, verbotener Bibliotheken oder architektonischer Entscheidungen.
Die „Projektverfassung“ ist eine Sammlung persistenter Artefakte, die dieses Problem löst. Dabei handelt es sich um strukturierte Dateien, die zusammen mit dem Quellcode im Repository gespeichert werden und dem Agenten das notwendige institutionelle Wissen verleihen, damit er wie ein informierter Teammitglied und nicht wie ein Außenstehender arbeiten kann.
Die Kernartefakte
AGENTS.md oder CLAUDE.md, die Bedienungsanleitung. Dies ist das Wichtigste: ein README für den Agenten, das zu Beginn jeder Sitzung gelesen wird, um zu erfahren, wie dieses spezielle Projekt funktioniert. Es sollte zunächst für die maschinelle Verarbeitung geschrieben werden, bevor es für Menschen lesbar ist. Eine effektive Datei enthält drei Arten von Informationen:
- Operative Details, die der Agent nicht selbst ableiten kann: genaue Build-Befehle mit Flags, wie Tests ausgeführt werden, Konfigurationen des Linters sowie Namen von Umgebungsvariablen.
- Namens- und Strukturkonventionen: wofür jeder Ordner dient, wie Dateien benannt werden und wie Module organisiert sind.
.env-Dateien bearbeiten oder die Authentifizierungslogik ohne Überprüfung ändern.SPEC.md – die lebende Spezifikation. Dies ist die autoritative Beschreibung dessen, was das System tun soll. Es handelt sich dabei nicht um eine historische Aufzeichnung. Es spiegelt das aktuelle beabsichtigte Verhalten wider, einschließlich jeder während der Implementierung getroffenen Entscheidung. Wenn sich der Code von SPEC.md unterscheidet, wird die Datei aktualisiert, und wenn sich die Anforderungen ändern, wird zunächst SPEC.md geändert und anschließend die Implementierung angepasst.
PLAN.md – das Architekturprotokoll. Es enthält architektonische Entscheidungen, Technologieauswahlen sowie systemweite Einschränkungen. Es beantwortet die Frage „Warum wurde es auf diese Weise gebaut?“, indem es die Begründungen liefert, die verhindern, dass spätere Agenten und Ingenieure sorgfältig getroffene Entscheidungen rückgängig machen.
Tool-spezifische Konfigurationsdateien. Jedes Tool hat seine eigene Konvention für Regeldateien. Das .mdc-Format von Cursor verdient eine Erwähnung, da es Markdown mit YAML-Frontmatter kombiniert, um Regeln an Dateimuster anzuhängen. Backend-Regeln, wie Authentifizierungsanforderungen und Datenbankzugriffsweisen, können somit nur dann angewendet werden, wenn der Agent mit Backend-Dateien arbeitet, wodurch irrelevanter Kontext während der Arbeit am Frontend aus dem Arbeitsspeicher entfernt wird.
Mehr-Agent-Orchestrierung
Warum ein Agent nicht ausreicht
Ein einzelner Agent, der für die gesamte Codebasis eines Unternehmens verantwortlich ist, stößt an eine harte Grenze: das Kontextfenster. Ein großes System mit 100.000+ Dateien, mehreren Diensten, komplexen Datenflüssen sowie einer vollständigen Testsuite passt nicht in den Kontext eines einzigen Agents. Der Agent muss entscheiden, was er berücksichtigen will, und diese Entscheidungen erzeugen Blindstellen.
Die Idee hinter der Multi-Agent-Orchestrierung besteht darin, das Vorgehen eines starken menschlichen Teams nachzuahmen – mit definierten Rollen, klaren Übergaben sowie einer Spezifikation, die alle als Wahrheit betrachten.
Drei Rollen
Koordinator. Dieser Agent übernimmt die Rolle des Projektmanagers und Architekten. Er behält das Gesamtbild im Auge, also die vollständige Spezifikation, die Aufgabenliste sowie die architektonischen Einschränkungen. Er unterteilt die Spezifikation in Unter-Spezifikationen, gibt sie an die Implementierer weiter, achtet auf Konflikte zwischen parallelen Arbeitsabläufen und stellt sicher, dass die Fertigstellung einer Aufgabe die Architektur insgesamt nicht beeinträchtigt.
Implementierer. Implementierer sind Spezialisten. Jeder erhält eine Unter-Spezifikation, die eine einzelne Aufgabe oder eine kleine Gruppe zusammenhängender Aufgaben umfasst, und arbeitet in einem isolierten Git-Worktree, sodass es zu keiner Kollision auf Dateiebene mit anderen parallel arbeitenden Implementierern kommt. Er weiß nichts über Arbeiten außerhalb seiner Aufgabenstellung und ist dafür nicht verantwortlich. Diese Isolation ist keine Einschränkung – sie sorgt dafür, dass das Ergebnis deterministisch, testbar und überprüfbar ist.
Prüfer. Der Prüfer verfolgt das gegenteilige Ziel. Während der Implementierer versucht, die Aufgabe abzuschließen, versucht der Prüfer herauszufinden, an welcher Stelle das Ergebnis den Spezifikationen nicht entspricht. Diese konträre Herangehensweise stammt aus der formalen Verifikation und der Sicherheitsforschung und gehört zu den stärksten Qualitätsmechanismen, die SDD bietet. Der Prüfer überprüft die Ausgabe anhand von Akzeptanzkriterien und sucht nach funktionalen Mängeln, Verstößen gegen Sicherheitsrichtlinien, Überschreitungen von Leistungsbeschränkungen sowie Abweichungen von den Spezifikationen. Bei der Entdeckung einer Abweichung korrigiert er den Code nicht. Stattdessen gibt er dem Koordinator eine strukturierte Beschreibung zurück, in der der Fehler auf eine bestimmte Anforderung zurückgeführt wird.
Für Produktivsysteme sollte dieser adversäre Verifier nicht optional sein. Ein Agent, der seinen eigenen Code schreibt und überprüft, wird fast immer sein Werk als akzeptabel einstufen, und der Wert des Verifers liegt darin, unabhängig vom Implementierenden zu sein und diesem entgegenzustehen.
Parallelausführung mit Worktrees
Eine der wertvollsten Fähigkeiten von multi-agentenbasierten SDD-Systemen ist der Parallelismus: Mehrere Implementierende arbeiten gleichzeitig an verschiedenen Funktionen oder Diensten, jeweils in ihrem eigenen Worktree. Bei großen Projekten mit wenigen Abhängigkeiten zwischen den Aufgaben kann die Lieferzeit erheblich verkürzt werden.
Git-Worktrees machen dies möglich. Jeder Agent verfügt über einen eigenen Arbeitsverzeichnis, das an denselben Repository angehängt ist, wodurch Dateikonflikte vermieden werden, während der Koordinator den Fortschritt aller Arbeitsstränge an einem Ort überwacht. Nach der Freigabe durch den Verifier fügt der Koordinator die abgeschlossenen Worktrees zusammen und hält den Hauptzweig sauber.
Diagramme als Code
Warum Diagramme in der Spezifikation gehören
Architekturdiagramme wurden traditionell nachträglich erstellt, um bereits vorhandenen Code zu dokumentieren. Bei SDD kommen sie bereits in der Frühphase hinzu, als Teil der Spezifikation und des Plans, noch vor jeder Implementierung.
Der Grund dafür ist diagnostischer Natur. Wenn ein Agent aufgefordert wird, aus einer Spezifikation ein gültiges Mermaid-Diagramm zu erstellen, muss er explizit über Datenflüsse, Service-Abhängigkeiten und Zustandsübergänge nachdenken, bevor er Code schreibt. Ein unübersichtliches oder incoherentes Diagramm in dieser Phase ist ein zuverlässiges Zeichen dafür, dass die Spezifikation unklar oder strukturell fehlerhaft ist, und das Beheben solcher Probleme in einem Diagramm kostet weitaus weniger als in bereits implementiertem Code.
Formate
Textbasierte Formate, insbesondere Mermaid und D2, sind zu diesem Zweck den binären Bildern überlegen. Sie können versioniert und verglichen werden, und Agenten können sie direkt lesen. Zudem können sie mit der Weiterentwicklung der Spezifikation aktualisiert werden, wodurch die strukturelle Dokumentation und die Implementierung im Einklang bleiben.
Drei Reifegradstufen
Die Praktiker haben drei Ebenen von SDD festgelegt. Es handelt sich dabei nicht um eine Leiter, die jedes Team in dieser Reihenfolge erklimmen muss. Es sind unterschiedliche Kompromissprofile für verschiedene Kontexte – zu wissen, welches für Ihre Situation am besten geeignet ist, steht vor jeder Einführung an erster Stelle.
Level 1, Spezifikation zuerst. Für eine Aufgabe wird eine ausführliche Spezifikation verfasst. Sobald die Implementierung abgeschlossen und überprüft ist, gilt die Spezifikation als verwendbar bis zum Ende: Sie kann zur Referenz aufbewahrt werden, wird aber nicht weiter gepflegt. Sie eignet sich für isolierte Funktionen, einmalige Migrationsvorgänge sowie Experimente, bei denen eine Wartung auf Level 2 nicht gerechtfertigt ist. Befürworter behaupten, dieses Niveau erzeuge etwa 60 % des Wertes von SDD zu einem Bruchteil der Kosten, was es zu einem sinnvollen Ausgangspunkt für Anfänger macht. Verwenden Sie es für neue Funktionen mit klaren Akzeptanzkriterien, ohne Abhängigkeiten zu anderen Diensten, deren Lieferzeit in Tagen gemessen wird.
Level 2, spezifikationsbasiert (die empfohlene Standardoption). Die Spezifikation ist während der gesamten Lebensdauer des Projekts ein gleichwertiger Partner zum Code, und beide werden gepflegt. Wenn sich die Anforderungen ändern, wird zunächst die Spezifikation geändert, und wenn die Implementierung abweicht, wird die Spezifikation umgehend aktualisiert, um das tatsächliche Verhalten sowie die Begründung festzuhalten. Das mag wie doppelte Wartung erscheinen, reduziert in der Praxis jedoch die Gesamtkosten: Es verhindert einen Kontextverlust über verschiedene Sitzungen hinweg, ermöglicht neuen Teammitgliedern (menschlich und künstlich intelligent) ein zuverlässiges Einarbeiten und macht spätere, von KI unterstützte Änderungen deutlich zuverlässiger. Es handelt sich dabei um die Grundlage für Produktivsysteme, Teamprojekte sowie alles, was weiterhin weiterentwickelt werden soll.
Level 3, spec-as-source (experimentell). Die Spezifikation ist das einzige primäre Dokument. Der Code wird wie kompilierte Ausgabe behandelt, nach Bedarf neu erzeugt und niemals manuell geändert. Es handelt sich um das theoretische Endziel von SDD, wobei Ingenieure die Spezifikationen pflegen und KI die Implementierungen übernimmt. Es gibt ein ungelöstes Problem: den Determinismus. Identische Spezifikationen können von Lauf zu Lauf syntaktisch unterschiedlichen, jedoch funktional äquivalenten Code erzeugen, was Vergleiche, Debugging und Überprüfungen erheblich erschwert. Betrachten Sie dies als experimentell. Es könnte sich für Greenfield-Projekte mit hochgradig vollständigen Spezifikationen, strenger KI-Steuerung und Toleranz gegenüber unzureifen Werkzeugen eignen, wird aber für kritische Produktionsysteme Stand 2026 nicht empfohlen.
Playbooks nach Rolle
Ingenieure und Architekten
Die Hauptfähigkeit des Ingenieurs verschiebt sich auf Kontextengineering. Die korrekte Syntax zu schreiben, erledigen Agenten in Maschinengeschwindigkeit, weshalb der Wert des Ingenieurs darin liegt, einen präzisen architektonischen Kontext zu definieren, zu bestimmen, was der Agent sehen kann, und zu überprüfen, ob seine Ausgabe der strukturellen Absicht des Systems entspricht. Dazu gehören das Erstellen guter AGENTS.md- und SPEC.md-Dateien, das Festlegen von Regeln zur Verwaltung von Bibliotheken (eine explizite Liste der erlaubten und verbotenen Abhängigkeiten), die Angabe von Sicherheits- und Konformitätsanforderungen in maschinenlesbarer Form sowie die Strukturierung von Aufgaben, damit verschiedene Aspekte getrennt bleiben.
Eine Einstiegsroutine für Ingenieure:
- Vor der Entwicklung jeder mit KI unterstützten Funktion sollten SPEC.md erstellt oder aktualisiert werden, sodass die zuvor beschriebenen sechs Elemente enthalten sind.
- AGENTS.md sollte überprüft werden, um sicherzustellen, dass die Build-Befehle, Testmuster, Namensregeln sowie die Schwerehierarchie weiterhin der Realität entsprechen.
Ein Constraints-Block ist ein nützliches Template, das in jeder Spezifikation enthalten werden kann. Er listet den Technologiestack (jede erforderliche Technologie), verbotene Bibliotheken (ausführlich aufgeführt), Sicherheitsanforderungen (wie Benutzer sich authentifizieren, welche Verschlüsselung erwartet wird, wie mit Daten umgegangen werden darf), Leistungsbeschränkungen (Ziellatenz und Durchsatz), Testanforderungen (Abdeckungsschwellenwert und erforderliche Testarten) sowie Architekturmuster (die erforderlichen und die zu vermeidenden).
Technische Produktmanager
Von PRDs zu Verhaltensbeschreibungen. Ein klassisches Produktanforderungsdokument geht davon aus, dass menschliche Ingenieure es lesen, darüber diskutieren und mit eigenem Urteilsvermögen umsetzen werden. Bei SDD muss die Ausgabe eines TPM eine Verhaltensbeschreibung sein: eine maschinenlesbare Beschreibung davon, wie das Produkt auf spezifische Benutzerbedürfnisse reagieren soll, unter Berücksichtigung der Präzision, die die Agentenausführung erfordert.
Der Unterschied liegt nicht nur im Stil. Ein PRD kann „die Zahlungserfahrung verbessern“ besagen. Eine Verhaltensbeschreibung muss jedoch genau angeben, was der aktuelle Zahlungsablauf bewirkt, welche Schmerzpunkte bei den Nutzern er verursacht, welche Verhaltensänderungen als Verbesserung gelten, wie Erfolg gemessen wird, welche Randfälle berücksichtigt werden müssen und was das System auf keinen Fall tun darf.
Der Prototypen-Zyklus. SDD ermöglicht es einem TPM, den üblichen Übergang vom Entwurf zur Ingenieurarbeit zu verkürzen. Anstatt auf Mockups eines Designers zu warten und anschließend darauf, dass ein Ingenieur sie umsetzt, kann der TPM interaktive Prototypen direkt aus einer Beschreibung des gewünschten Verhaltens erstellen und das funktionierende Verhalten statt statischer Bildschirme bewerten. Wenn der Prototyp nicht der Vision entspricht, wird die Spezifikation aktualisiert und der Agent generiert die Implementierung erneut, sodass der Feedbackzyklus auf der Spezifikation und nicht auf dem Code beruht. Dadurch entfallen mehrere Übersetzungsschritte (PRD, anschließend Übergang zum Design und dann zum Engineering), bei denen die ursprüngliche Absicht oft verloren geht.
CTOs und Engineering-Leiter
Steuerung. Die Priorität eines CTOs in einer agentenbasierten Organisation ist ein Steuerungsrahmenwerk, das es der KI ermöglicht, die Lieferung zu beschleunigen, ohne Qualität, Sicherheit oder Konformität zu gefährden. SDD stellt die Kontrollschicht bereit – allerdings nur in Kombination mit organisatorischer Disziplin. Bei großem Umfang sind drei Mechanismen entscheidend:
- Versionierung von Spezifikationen. SPEC.md, PLAN.md und AGENTS.md befinden sich im selben Repository wie der Code und durchlaufen dieselben Überprüfungen und Genehmigungsverfahren.
- Auditrückverfolgbarkeit. Jede von der KI erzeugte Änderung sollte auf eine bestimmte Spezifikationsanforderung zurückverfolgt werden, was in regulierten Branchen nicht optional ist.
- Menschliche Kontrollen bei jedem Übergang. Nichts wird ohne Genehmigung in jeder Phase autonom von der Spezifikation zur Planung und schließlich zur Umsetzung weitergeleitet.
CTOs sollten AI-Programmierwerkzeuge ebenfalls anhand dieses Rahmens bewerten und prüfen, wie gut sie dauerhafte Regeldateien, Überprüfungsmechanismen, Nachvollziehbarkeit sowie mehragentige Arbeitsabläufe unterstützen.
Ertragsmessung. Organisationen, die SDD einführen, berichten oft, dass die Entwicklung in den ersten zwei bis vier Wochen langsamer erscheint, weil Ingenieure Zeit mit Spezifikationen verbringen anstatt direkt mit dem Code zu arbeiten. Diese Beobachtung ist richtig, doch die Interpretation irreführt. Die Arbeit an Spezifikationen stellt keine neue Überlast dar. Es handelt sich dabei um Arbeit, die früher informell, inkonsistent und erst nach der Implementierung – also zu einem Zeitpunkt, an dem sie am teuersten war – erledigt wurde. Die Kennzahlen, die den tatsächlichen Ertrag zeigen, liegen weiter im Prozessverlauf:
- die Zeit vom Anforderungsentwurf bis zum für die Produktion bereiten Code, also einem geprüften, überprüften und bereitgestellten Code und nicht nur einem geschriebenen,
- Prozentsatz der Nacharbeiten, der Anteil der fertiggestellten Funktionen, die aufgrund falscher Verständnisse der Anforderungen erneut erstellt werden müssen,
- Zeit zur Wiedereingliederung, wie lange ein Entwickler oder Agent benötigt, um wieder produktiv mit Code zu arbeiten, der seit 30 Tagen unberührt war, und
- Defektrate, der Anteil der Defekte, die bereits bei der Spezifikationsprüfung entdeckt werden, im Vergleich zu denen nach der Bereitstellung.
Teams mit ausgereifter SDD-Praxis weisen nach Angaben einen Rückgang der Nacharbeiten um 40-60 Prozent sowie eine deutliche Verkürzung der Zeit zur Wiedereingliederung auf, da die Spezifikation den Kontext liefert, der sonst stundenlange Analyse des Codes erfordern würde. Diese Zahlen stammen aus Berichten von Praktikern und nicht aus kontrollierten Studien, daher sollten Sie Ihren eigenen Ausgangswert ermitteln.
Intent Drift
Was das ist
Intent Drift ist die allmählich entstehende Kluft zwischen den ursprünglichen Anforderungen des Unternehmens und dem Verhalten des Codes in der Produktion. Dieses Phänomen ist nichts Neues im Bereich der von KI unterstützten Arbeit und gehört zu den ältesten Problemen der Softwareentwicklung – doch Programmieragenten verstärken es gefährlich. Sie optimieren nach Plausibilität und Testbestehen, nicht nach Übereinstimmung mit den Geschäftsanforderungen. Wenn man einen Agenten bittet, ein Zahlungsverarbeitungssystem zu entwickeln, wird er Code schreiben, der alle Tests bestehen und jeden angegebenen Fall abdecken. Sind die Spezifikationen unvollständig oder veraltet, füllt der Agent die Lücken mit statistisch wahrscheinlichen Standardwerten aus seinen Trainingsdaten. Diese eignen sich zwar für allgemeine Systeme, können aber für die spezifischen Geschäftsregeln Ihres Unternehmens katastrophal sein. Die schlimmste Form des Intent Drifts wird erst dann bemerkt, wenn Kunden Schaden erleiden, eine Konformitätsprüfung stattfindet oder ein Produktionsvorfall auftritt – schließlich sind Agenten sehr gut darin, Code zu erzeugen, der auf den ersten Blick korrekt erscheint, aber in Wirklichkeit subtil fehlerhaft ist.
Verteidigungsmechanismen
- Eine lebende Spezifikation. Der erste Verteidigungsmechanismus besteht darin, dass die Spezifikation in Echtzeit aktualisiert wird, sobald Entscheidungen getroffen werden. Jeder Abweichung von SPEC.md, egal wie gering oder gut begründet, wird umgehend erfasst, sodass die Datei stets das aktuelle Verhalten beschreibt und nicht die ursprüngliche Absicht.
- Adversarische Überprüfung. Das Überprüfungsverfahren dient gleichzeitig der Erkennung von Abweichungen. Die Überprüfung der Ausgabe gegenüber der Spezifikation bei jeder Aufgabe ermöglicht es, Abweichungen bereits in sehr frühen Stadien zu erkennen, bevor sie sich über mehrere Implementierungszyklen hinweg verstärken.
- Überwachung der Spezifikationsabdeckung. In fortgeschritteneren Konfigurationen wird der Anteil der Anforderungen erfasst, für die automatisierte, überprüfbare Tests vorhanden sind. Eine Anforderung ohne Test kann unbemerkt abweichen, und das Streben nach vollständiger Abdeckung stellt eine testgetriebene Entwicklung auf der Ebene der Anforderungen dar.
Ein minimales AGENTS.md
Ein für die Produktion bereites AGENTS.md kann kurz sein. Mindestens sollte es eine einzeilige Beschreibung des Projekts, die genauen Befehle zum Kompilieren, Testen und Linten, die Konventionen für Benennung und Verzeichnisstruktur, die Listen „Immer“, „Zuerst fragen“ und „Nie“, Verweise auf SPEC.md und PLAN.md sowie die Regeln zur Verwaltung von Bibliotheken enthalten. Anpassen Sie jeden Teil an Ihren Technologiestack und die Anforderungen Ihrer Organisation.
Was bleibt Ihnen übrig
Entwicklung unter Verwendung von Spezifikationen ist keine vorübergehende Mode oder eine kleine Verbesserung bestehender Gewohnheiten. Sie verändert, aus was sich die Ingenieurarbeit zusammensetzt. Mit Programmier-Agenten liegt das Engpass bei der Lieferung nicht mehr darin, wie schnell die Syntax erzeugt wird, sondern darin, wie präzise die Absichten definiert werden. Die Spezifikation ist das Produkt, der Code ist das, was sie umsetzt, und bei der Entwicklung mit Agenten ist die Spezifikation das wichtigste Ergebnis des Ingenieurs.
Weitere Literatur
- Praktische Hinweise: Ich betreibe einen AI-Code-Agent lokal – und die Leistung ist fast doppelt so hoch – Detaillierte Anleitung zu den Praktischen Hinweisen: Ich betreibe einen AI-Code-Agent lokal – und die Leistung ist fast doppelt so hoch: Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster einsetzen.
- Agentic Engineering in fünf Schichten: Von Spezifikationen und parallelen Agenten bis hin zu Regeln und Überwachung – Karpathy beschreibt den Wandel weg vom reinen Vibecoding. Erfahren Sie die fünf Schichten des Agentic Engineering: Spezifikationen, Orchestrierung, kodifizierte Regeln, menschliche Überprüfung und Überwachbarkeit sowie einen Wochenplan.