Spezifikationsgetriebene Entwicklung für KI-Projekte

KI macht es sehr viel leichter, schnell Code zu erzeugen. Sie macht es aber ebenso leichter, schnell den falschen Code zu erzeugen. Genau deshalb ist spezifikationsgetriebene Entwicklung in KI-gestützten Projekten wichtiger und nicht weniger wichtig.

Wenn ein Team ohne klare Spezifikation entwickelt, driftet das Produkt mit der Zeit von seinem Zweck weg. Wenn KI dabei hilft, kann diese Drift an einem einzigen Nachmittag entstehen. Der Code kann kompilieren, die Oberfläche kann gut aussehen, und Tests können sogar bestehen. Das Produkt kann trotzdem falsch sein.

Warum KI das Risikoprofil verändert

KI beschleunigt das Tempo der Interpretation. Ein einziger Prompt kann Architektur, Text, Validierung, Benennung und Benutzerfluss erzeugen. Das ist nützlich, aber gefährlich, wenn die Quelle der Wahrheit nicht klar genug ist.

In der Praxis optimiert KI oft das, was im Moment am sichtbarsten ist:

• den letzten Prompt
• die nächstgelegene Datei
• den einfachsten Implementierungspfad
• das generischste bekannte Muster

Nichts davon bedeutet automatisch die richtige Produktentscheidung.

Das sind nützliche Abkürzungen für die Generierung. Sie sind aber kein Ersatz für Produkturteil.

Was eine gute Spezifikation leistet

Eine gute Spezifikation erfüllt mindestens vier Aufgaben:

• sie definiert den Zweck
• sie setzt Grenzen
• sie bestimmt den Prüfmaßstab
• sie dient als Gedächtnis des Teams

Erstens definiert sie den Zweck. Das Team kann erkennen, ob eine Funktion das eigentliche Produkt unterstützt oder nur zusätzlichen Output erzeugt.

Zweitens definiert sie Grenzen. Sie klärt, was im Umfang liegt, was außerhalb des Umfangs liegt, was optional ist und was selbst dann funktionieren muss, wenn optionale Systeme ausfallen.

Drittens definiert sie den Review-Maßstab. Statt nur zu fragen, ob eine Änderung technisch funktioniert, können Reviewer fragen, ob sie zum beabsichtigten Workflow und zu den Produktzusagen passt.

Viertens wirkt sie als Gedächtnis. KI-Systeme halten keine stabile institutionelle Erinnerung von selbst. Eine Spezifikation im Repository tut es.

Das ist bei Let Books sehr klar. AGENTS.md betont mehrfach, dass der manuelle Ablauf auch ohne kostenpflichtige KI-Dienste funktionieren muss und dass physische Buchexemplare nicht dasselbe sind wie bibliografische Datensätze. Das sind keine technischen Details, sondern Produktgrenzen.

Das sind keine Implementierungsdetails. Das sind Produktgrenzen. Wenn ein KI-Assistent einen Ablauf erzeugt, der die manuelle Eingabe blockiert oder Daten physischer Exemplare in Editionsmetadaten zusammenfallen lässt, ist das Problem nicht Stil. Das Problem ist Produktdrift.

Warum Dokumentation nicht warten darf

Wenn Dokumentation veraltet oder unklar ist, leiten verschiedene Menschen und verschiedene Werkzeuge aus demselben Repository verschiedene Produkte ab. Einer folgt dem Demo, ein anderer einer alten README-Datei, ein dritter der nächstgelegenen Datei.

Ohne aktuelle Dokumentation:

• werden Prompts inkonsistent
• wird Review subjektiv
• beginnen Demos das Produkt versehentlich neu zu definieren
• übernehmen künftige Mitwirkende Verhalten, ohne zu wissen, ob es beabsichtigt war

Deshalb ist Dokumentation nicht nur eine nachträgliche Erklärung. Sie ist Teil des Betriebssystems des Projekts. In diesem Repository beschreibt README.md den aktuellen Stand, AGENTS.md die Produktabsicht, AGENTS-Implementation.md die taktischen Regeln und docs/ die Veröffentlichungs- und Nachweisregeln.

Die Rolle von Demos

Ein Demo ist nützlich, weil es zeigt, was existiert, und Probleme im Benutzerfluss sichtbar macht. Es sollte jedoch nicht stillschweigend zur Produktspezifikation werden.

Die Regeln des Repositories unterscheiden bereits zwischen kanonischen Spezifikationen und Dokumentation einerseits und Implementierungsstatus andererseits. Wenn ein Demo einen besseren Ablauf zeigt, müssen Spezifikation und Dokumentation aktualisiert werden, statt das Demo still gewinnen zu lassen.

Wenn ein Demo einen besseren Ablauf zeigt, ist die Antwort nicht, das Demo stillschweigend gewinnen zu lassen. Die Antwort ist, Spezifikation, Dokumentation und den Review-Maßstab zu aktualisieren, damit der bessere Ablauf absichtlich wird.

Markdown, Tests und CI bilden eine Kette

In einer spezifikationsgetriebenen Entwicklung stehen diese Ebenen nicht für sich allein.

• Markdown speichert die Absicht in überprüfbarer Form.
• Dokumentation erklärt, wie sie zu verstehen ist.
• Tests prüfen ausführbare Erwartungen.
• Validierungsregeln erkennen strukturelle Drift.
• CI setzt die Regeln regelmäßig durch.

Zusammen schaffen sie ein Produktgedächtnis, das die Entwicklungsgeschwindigkeit überlebt.

Jede Ebene ist für sich unvollständig. Zusammen schaffen sie ein Produktgedächtnis, das Geschwindigkeit, Iteration und Teamwechsel überlebt.

Was das für Teams bedeutet, die KI nutzen

Teams, die KI gut einsetzen, entfernen den Prozess nicht. Sie verlagern den Prozess näher an die Quelle der Generierung.

Das bedeutet in der Regel:

• vor der Implementierung klarere Produktspezifikationen zu schreiben
• Implementierungsleitlinien ausdrücklich festzuhalten
• die Dokumentation zu aktualisieren, wenn sich das Produktverhalten ändert
• Demos gegen die Spezifikation zu prüfen, statt Übereinstimmung einfach anzunehmen
• schrittweise Validierungsregeln hinzuzufügen, damit Konsistenz nicht nur vom menschlichen Gedächtnis abhängt

Das ist nicht gegen KI gerichtet. So wird KI verlässlich.

Die dauerhafte Lehre

KI kann schnell Code, Inhalte und Oberflächen erzeugen. Sie kann aber nicht von sich aus garantieren, dass all diese Ausgaben weiterhin dasselbe Produkt beschreiben.

Spezifikationsgetriebene Entwicklung ist die Art, wie ein Team verhindert, dass aus Geschwindigkeit Drift wird.

In KI-gestützten Projekten ist die Spezifikation nicht nachträglicher Papierkram. Sie ist die Grenze, das Gedächtnis und der Prüfmaßstab, die schnelle Lieferung vertrauenswürdig machen.

Weiterführende Seiten

• ../../wiki/spec-driven-development.md
• ../../wiki/validation-layers.md
• ai-as-an-oracle.md
• spec-driven-development-in-let-books.md