Der meiste Code existiert schon
Spec-Driven Development funktioniert sehr gut, wenn du ein neues Projekt startest. Du schreibst zuerst die Specs, und der KI-Agent setzt sie um. Aber die meisten von uns arbeiten nicht an neuen Projekten. Wir arbeiten an Systemen, die fünf, zehn oder zwanzig Jahre alt sind. Oft gibt es gar keine Specs, oder sie sind veraltet.
Deshalb lautet die erste Frage in vielen meiner Workshops: Wie kommen wir zu Specs für den Code, den wir schon haben?
Die Antwort ist Reverse Engineering. Der KI-Agent liest den bestehenden Code und erstellt daraus die Specs. Dann prüfst du sie, korrigierst sie, und ab dann kannst du spec-driven arbeiten.
In diesem Beitrag zeige ich, was der AI Unified Process dafür bietet und wie andere Spec-Driven-Tools mit bestehendem Code umgehen.
Der Reverse-Engineer-Skill des AI Unified Process
Der AI Unified Process hat einen Skill namens /aiup-core:reverse-engineer. Du führst ihn in einem bestehenden Projekt aus, und er erstellt drei Arten von Artefakten:
- Ein Use-Case-Diagramm in PlantUML mit allen Akteuren und Use Cases des Systems.
- Eine Use-Case-Spezifikation pro Use Case mit Akteuren, Vorbedingungen, Hauptszenario, alternativen Abläufen, Nachbedingungen und Geschäftsregeln.
- Ein Entitätsmodell mit einem Mermaid-ER-Diagramm und Attributtabellen mit Datentypen und Validierungsregeln.
Der Skill liest Controller, Views, Services und das Datenbankschema. Daraus leitet er ab, was die Benutzer mit dem System tun können und welche Daten das System verwaltet.
Das sind dieselben Artefakte, die du in einem neuen Projekt mit dem AI Unified Process erstellst. Nach dem Reverse Engineering gibt es also keinen Unterschied mehr zwischen einem neuen und einem bestehenden Projekt. Für die nächsten Schritte verwendest du dieselben Skills: /aiup-core:spec-review, um die Qualität der Specs zu prüfen, und danach die Skills für Implementierung und Tests.
Natürlich sind die erzeugten Specs nur ein erster Entwurf. Der Code zeigt, was das System tut, nicht warum. Geschäftsregeln, die im Code versteckt sind, müssen von Leuten geprüft werden, die die Domäne kennen.
Was andere Spec-Driven-Tools tun
Ich habe mir die bekannten Spec-Driven-Tools und einige Community-Projekte angesehen. Alle unterstützen bestehenden Code in irgendeiner Form, aber sie erzeugen sehr unterschiedliche Ergebnisse.
Kiro (AWS) hat eine Funktion namens «Generate Steering Docs». Sie analysiert den Code und erstellt drei Dateien: product.md, tech.md und structure.md (Kiro-Blog). Diese Dateien geben dem Agenten Kontext zum Produkt, zum Tech-Stack und zur Codestruktur. Es sind keine Specs der Features.
BMAD Method hat den Workflow document-project. Er scannt das Projekt und dokumentiert den aktuellen Stand, zum Beispiel Architektur und Module. Für kleinere Bedürfnisse gibt es generate-project-context, das Konventionen und Muster festhält (BMad-Doku). Das Ergebnis ist eine Projektdokumentation, die später ins PRD einfliesst.
GitHub Spec Kit macht von sich aus kein Reverse Engineering. Der offizielle Guide sagt, dass specify init keine Specs für bestehendes Verhalten ableitet. Er empfiehlt, Specs nur für die geplanten Änderungen zu schreiben (Spec-Kit-Guide). Für Reverse Engineering gibt es Community-Erweiterungen wie Brownfield Bootstrap mit /speckit.brownfield.migrate (PR #2145).
Dazu kommen kleinere Community-Tools:
- InferSpec erstellt OpenSpec-Specs, eine pro Capability. Es nutzt Code, Git-Historie und Dokumentation und verknüpft jede Anforderung mit Datei und Zeile. Bei Lücken stellt es dem Benutzer Fragen.
- StackShift ist ein Claude-Code-Plugin mit einem Prozess in sechs Schritten. Das Ergebnis ist für Spec Kit oder BMAD gedacht.
- CoDD hat
codd extract, das Designdokumente aus dem Quellcode erstellt. - spec-driven-dev hat einen Befehl
/retrofit, der über Discovery, «Archäologie» und Lücken schliesslich zu Specs führt.
| Tool | Befehl | Was es erstellt |
|---|---|---|
| AI Unified Process | /aiup-core:reverse-engineer | Use-Case-Diagramm, Use-Case-Spezifikationen, Entitätsmodell |
| Kiro | Generate Steering Docs | Kontextdateien zu Produkt, Technik und Struktur |
| BMAD Method | document-project | Projektdokumentation (Architektur, Module) |
| Spec Kit | Community-Erweiterungen | Constitution und Feature-Specs |
| InferSpec | /inferspec-scan | OpenSpec-Capability-Specs |
| CoDD | codd extract | Designdokumente |
Kontext für den Agenten oder Anforderungen für das Team?
Wenn du die Ergebnisse anschaust, siehst du zwei verschiedene Ziele.
Die meisten Tools erstellen Kontext für den KI-Agenten. Die Steering-Dateien von Kiro und die Projektdokumentation von BMAD sagen dem Agenten, welches Framework verwendet wird, wie der Code strukturiert ist und welche Konventionen gelten. Das ist nützlich, aber es beschreibt die Technik, nicht das Geschäft.
Andere Tools erstellen Feature- oder Capability-Specs. InferSpec und die Spec-Kit-Erweiterungen gehen weiter und beschreiben Verhalten. Aber ihr Format ist toolspezifisch, und sie modellieren die Daten nicht.
Der AI Unified Process erstellt Anforderungen, die Menschen lesen und diskutieren können. Use Cases und Entitätsmodelle werden seit Jahrzehnten im Requirements Engineering verwendet. Ein Business Analyst, ein Product Owner oder eine Fachperson kann eine Use-Case-Spezifikation prüfen, ohne den Code zu kennen. Und das Entitätsmodell zeigt die Daten, die oft der wertvollste Teil einer Geschäftsanwendung sind.
Das ist wichtig, weil per Reverse Engineering erzeugte Specs nie beim ersten Mal korrekt sind. Jemand aus dem Fachbereich muss sie prüfen. Sind die Specs für den Agenten geschrieben, können nur Entwickler dieses Review machen. Sind die Specs Use Cases, kann es das ganze Team.
Fazit
Reverse Engineering ist die Tür zu Spec-Driven Development für bestehende Systeme. Viele Tools bieten es an, aber sie beantworten unterschiedliche Fragen. Kiro und BMAD helfen dem Agenten, den Code zu verstehen. InferSpec und die Spec-Kit-Erweiterungen beschreiben Features in ihrem eigenen Format.
Der AI Unified Process erstellt Use Cases und ein Entitätsmodell. Das sind Artefakte, die das ganze Team versteht, und dieselben Artefakte, die du in einem neuen Projekt verwendest. So kannst du mit einem bestehenden System starten und mit genau demselben Prozess weitermachen.
Probier es an einem deiner Projekte aus und sag mir, was du denkst. Den AI Unified Process findest du auf unifiedprocess.ai.
Alle Angaben zu den anderen Tools entsprechen dem Stand von Oktober 2026. Diese Tools ändern sich schnell, bitte prüfe ihre Dokumentation für den aktuellen Stand.
