Viele spezifikationsgetriebene Werkzeuge gehen davon aus, dass zuerst die Spezifikation entsteht und dann der Code. In einem bestehenden System war der Code zuerst da. Der AI Unified Process ist dafür gebaut.
/reverse-engineer liest Code, Konfiguration, Schema und Tests und schreibt das Use-Case-Diagramm, eine Spezifikation pro Use Case und das Entitätsmodell. Es sind dieselben Artefakte, mit denen ein neues Projekt beginnt, also funktioniert jeder weitere Schritt gleich.
Ändert sich ein Use Case, gleicht der Agent den bestehenden Code damit ab. Er wirft den Code nicht weg und generiert ihn neu. Ihr Code, Ihre Konventionen und Ihre Historie bleiben. Werkzeuge, die die ganze Anwendung aus der Spezifikation generieren, können das nicht.
/spec-review prüft die Spezifikationen gegeneinander. Ein altes System hat alte Lücken, darum hält es die heute vorhandenen Befunde als Baseline fest. Ab dann lassen nur neue Probleme den Build scheitern.
Eine grosse Codebasis bekommt ihre Artefakte nach Modulen aufgeteilt. Sie prüfen und übernehmen das Modul, das Sie als Nächstes ändern. Kein Dokumentationsprojekt im Big Bang vor der ersten Änderung.
/stack liest die Build-Dateien und den Quellbaum und hält die Schichten fest, die das Projekt bereits hat. Die Construction-Skills richten sich danach. Für den Start ist keine Migration auf ein neues Framework nötig.
Use Cases in der Sprache des Geschäfts ersetzen das Wissen, das mit den Leuten gegangen ist, die das System gebaut haben. /use-case-coverage zeigt, wo Code und Tests von der Spezifikation abgewichen sind.
Beide Wege beginnen gleich: das Bestehende rückwärts erschliessen, und Requirements Engineer und Software Engineer prüfen das Ergebnis gemeinsam. Danach trennen sie sich.
Das System bleibt auf seinem Stack. Ein neues Feature, eine Änderung oder ein Fehler ändert immer zuerst einen Use Case, und der AI Unified Process ordnet ihn als Bug oder Enhancement ein. Der Agent gleicht den Code mit dem geänderten Use Case ab, schreibt die Tests, die die Spezifikation verlangt, und das Coverage-Audit zeigt, was noch offen ist. Spezifikation und Code laufen nie wieder auseinander.
Das alte System wird zur Anforderungsquelle für das neue. Use Cases beschreiben Verhalten in fachlicher Sprache, nicht Code, und hängen darum nicht an der alten Technologie. /stack hält die neuen Schichten fest, /use-case-implement und /use-case-test bauen sie Use Case für Use Case, und Testfälle und Geschäftsprozesse legen die Abläufe fest, die das neue System bestehen muss. Sie migrieren Modul für Modul statt in einem grossen Rewrite.
Installieren Sie die Open-Source-Plugins in Ihrem Coding-Agenten und öffnen Sie das Repository, das Sie bereits haben.
/reverse-engineer:
Use-Case-Diagramm, Use-Case-Spezifikationen und Entitätsmodell aus dem Code ableiten.
/spec-review:
die Spezifikationen gegeneinander prüfen und die heutigen Befunde als Baseline akzeptieren.
/stack:
die Schichten festhalten, die das Projekt bereits hat (oder die neuen, wenn Sie modernisieren).
/next:
fragen, welcher Befehl als Nächstes kommt. Ab hier beginnt jede Änderung mit einem Use Case.
Das Showcase Spring PetClinic hat zwei Branches: start, direkt nach dem Reverse Engineering, und main, mit jedem Use Case implementiert und durch Tests abgesichert. Der ganze Brownfield-Weg ist ein einziger Diff.
Der AI Unified Process ist für uns bei der WBS GRUPPE die ideale Methode, um bestehende Produkte strukturiert zu analysieren und weiterzuentwickeln. Indem Anforderungen und Use Cases konsequent im Mittelpunkt stehen, behalten wir auch in einer etablierten Codebasis die volle Kontrolle. Besonders bemerkenswert: Durch die präzisen Spezifikationen verlief die anschließende Implementierung überraschend schnell. Ein hocheffizienter Rahmen für die agile Softwareentwicklung im KI-Zeitalter.
Ich habe AIUP sowohl für ein Greenfield- als auch für ein bestehendes Brownfield-Projekt eingesetzt. Beides hat funktioniert, und beide Ansätze waren ebenso effizient wie unterhaltsam. Vor allem hatte ich beim Agentic Engineering zum ersten Mal das Gefühl, dass die Kontrolle an mich als Entwickler zurückgegeben wurde: ein Gefühl, das ich vermisst hatte, seit ich die AI-Prompting-Phase hinter mir gelassen und mich ins 'Vibe-Coding' gewagt hatte. Da der Tech-Stack aiup-vaadin-jooq für mein bestehendes Brownfield-Projekt nicht in Frage kam, trage ich mit dem Plugin aiup-angular-jpa zu AIUP bei.
Ja. Zuerst kommt die Spezifikation, und die Tests entstehen aus der Spezifikation, nicht aus dem Code. /use-case-test nimmt den Use Case als Orakel: Ein Test, der dem Code widerspricht, bleibt rot, statt passend gebogen zu werden. So zeigt Ihnen ein altes System, wo es nicht tut, was das Geschäft erwartet.
Nein. Eine grosse Codebasis bekommt ihre Artefakte nach Modulen aufgeteilt, und Sie prüfen und übernehmen das Modul, das Sie als Nächstes ändern. Die Baseline von /spec-review verhindert, dass alte Befunde den Build blockieren, während Sie den Rest abarbeiten.
Ja. Erschliessen Sie das alte System rückwärts, prüfen Sie die Use Cases und halten Sie die neuen Schichten mit /stack fest. Die Use Cases beschreiben Verhalten, nicht Code, und gelten darum auch für die neue Technologie. /use-case-implement und /use-case-test bauen das neue System dann Use Case für Use Case, und Sie können Modul für Modul migrieren.
Workshops, Beratung und massgeschneiderte Einführungen. Vereinbaren Sie einen Termin, um zu besprechen, wie der AI Unified Process zu Ihrem bestehenden System passt: es zu pflegen, weiterzuentwickeln oder auf einen neuen Stack zu bringen.