KI-gestützte Legacy-Modernisierung (v1) 🇩🇪 @BetterCode(Agentic Ai) 2026

KI verändert die Art, wie Legacy-Systeme analysiert und modernisiert werden können. Der Vortrag zeigt ein strukturiertes Vorgehensmodell, das bewährte Prinzipien der Systemanalyse und Architekturarbeit mit aktuellen KI- und agentischen Ansätzen verbindet.

Im Mittelpunkt stehen drei Schritte:

- die fundierte Analyse des bestehenden Systems,
- die Rekonstruktion fachlicher Strukturen und Abhängigkeiten
- die schrittweise, überprüfbare Modernisierung.

Anhand von Erfahrungen aus Industrieprojekten wird eingeordnet, welche Aufgaben KI sinnvoll unterstützt, wo menschliche Entscheidungen unverzichtbar bleiben und wie beide Rollen zusammenspielen.

Transcript

1. KI-gestützte LegacyModernisierung: Von Systemverständnis zu kontrollierter Veränderung Christian Hühn (er/ihm) Richard Gross (er/ihm) 06.10.26 codecharta.com richargh.de in/christian-hühn/ richargh.de in/richargh
2. Kurze Intro zu Coding Agenten mw-add, prj-implement, prj-review Skill laden, dann Prompt /skill:prj-implement Implementier mal feature x/y. Plane die Umsetzung. Feedforward prj-implement Implementiere das Feature an der erst-besten Stelle. $ write SuperFeatureService.java Überprüfe, ob die Tests grün sind. Feedback $ mvn test
3. Kontext-Management zu Agenten Nach der Aktion Vor der Aktion Feedforward (Guides)1 prj-implement/SKILL.md mw-add/SKILL.md ZielArchitektur.md LegacyCode.java Coding Agent Feedback (Sensors)1 Resultat Um das hier bei Legacy Code zu optimieren Muss ich kontinuierlich optimieren was hier reinkommt Test result Lint result ArchUnit result Muss ich kontinuierlich optimieren was hier, wie schnell zurückkommt 1 https://martinfowler.com/articles/harness-engineering.html
4. Legacy Software Unglaublich wertvoll Gefährlich zu verändern Modelliert alte Welt
5. Wie modernisieren wir das denn jetzt mit Agenten?
6. Mit Managed Agentic Evolution zum Ziel
7. Managed Agentic Evolution Die richtige Lösung bauen 2. Abgrenzen 3. Priorisieren 4. Wetten A. Ausrichten B. Absichern 1. Zuhören Die Lösung Richtig bauen 5. Schneiden 6. Entwickeln Bestand sichern 7. Integrieren 8. Ausliefern
8. A. Ausrichten Wissen auf mehreren Ebenen Wie es ist (Code) Wie es sein soll (Mental) Zwischen keinem und N mentalen Modellen ist alles dabei Wie es vielleicht ist/sein soll (Dokumentation)
9. A. Ausrichten Oft laufen diese Welten auseinander Wie es ist (Code) Ziel ist es dieses Wissen zu extrahieren, zu dokumentieren und als Grundlage für die Ausrichtung zu verwenden Wie es sein soll (Mental) Am besten in Wochen anstatt Jahren Wie es vielleicht ist/sein soll (Dokumentation)
10. A. Ausrichten Auf dem Weg zur Fachdokumentation Expertenworkshops Neues extrahiertes Fachwissen wird mit Domänenexperten abgeglichen und Lücken geschlossen Ausarbeitung Das Wissen aus ADD und den Expertenworkshops nutzen wir, um eine Fachdokumentation und Wissen wiederherzustellen. Agentic Domain Discovery Fachwissen aus Code und Dokumentation agentisch wieder explizit machen (sehr viele spezialisierte Agents und Skills)
11. A. Ausrichten Zoom in Agentic Domain Discovery Auf dem Weg zur Fachdokumentation Phase 1: Discovery Phase 2: Deep Analysis Agenten suchen unter anderem nach Fachlichkeit, Kontextgrenzen, Tests und Fachsprache Pro Kontext wird die Fachlichkeit rekonstruiert. Phase 3: Validation Phase 4: Document Generation Jede Aussage wird gegen den Code geprüft. Lücken und Duplikate werden sichtbar. Daraus entsteht Dokumentation mit Diagrammen und Quellen
12. A. Ausrichten Grundstein für die Modernisierung Fachdokumentation Systemübersicht › Alle gefundenen Kontexte und deren Zusammenhang › Domänenarchitektur › Fähigkeiten des Systems Agentic Domain Discovery Kontext › Nutzen › Beziehungen zu anderen Kontexten › Glossar und vorgeschlagene Sprache › Aggregates › Business-Regeln › Entitäten und Objekte › Services › Szenarien › Zustandsänderungen -> 6. Entwickeln Geteilte Logik › Gleicher Kontext › Gleiche Bedeutungen › Gleiche Objekte Aufdecken von Risiken Grenzen › Interne Schnittstellen › Externe Schnittstellen
13. A. Ausrichten Grundstein für die Modernisierung Fachdokumentation Systemübersicht -> 6. Entwickeln Kontext Geteilte Logik Grenzen Als Model to be wrong Gemeinsames Modell Agentic Domain Discovery Als Bestand aus der Analyse Teilungszenarien -> 2. Abgrenzen Charakterisierungstests -> B. Absichern 1000+ Szenarien -> 6. Entwickeln Fachliche Tests -> B. Absichern Ubiquitous Language -> Glossar für Agenten
14. A.B.Sichten Absichern mit einem Sicherheitsnetz Fehlt noch immer überraschend oft Legacy-System Level 1: Versionsverwaltung & Build-Automatisierung Charakterisierungstests Fachliche Tests Level 2: Testumgebung auf Knopfdruck Level 3: Automatische Qualitätsüberwachung Level 4: Fortschrittsvisualisierung Level 5: Release auf Knopfdruck KI vereinfacht das Aufsetzen und senkt die Hürde, Tests zu schreiben CodeCharta
15. All das füttert jetzt unsere Iterationen Die richtige Lösung bauen 2. Abgrenzen 3. Priorisieren 4. Wetten A. Ausrichten B. Absichern 1. Zuhören Die Lösung Richtig bauen 5. Schneiden 6. Entwickeln Bestand sichern 7. Integrieren 8. Ausliefern
16. A.B.1.Sichten Absichern Zuhören um das richtige zu bauen Lernen von den Anwendern Lernen von den Domänenexperten User Interviews Event Storming User Shadowing Domain Storytelling Initiale TraceAnalyse User Tracing Impact Mapping Initialer Vergleich Prd/New-Prd Dark Launches Feature Injection Prototypes CodePrototypen Initialbild, Codeabgleich Abgleich Beispiele mit Code
17. A.B.1.Sichten Absichern Zuhören um das richtige zu bauen Lernen von den Anwendern Lernen von den Domänenexperten User Interviews Event Storming Vorsicht User Shadowing Domain Storytelling Einem Agenten die Generierung und Validierung zu überlassen ist die perfekte Chance nichts zu lernen. User Tracing Impact Mapping “You are absolutely right” ist nur gut für unser Ego. Dark Launches Feature Injection Software für Menschen braucht Feedback von Menschen. Prototypes Siehe auch: https://ashley.rolfmore.com/stop-trying-to-engineer-your-way-out-of-listening-to-people/
18. A.B.1.Sichten Absichern 2. Zuhören Abgrenzen um das richtige zu bauen an vergibt 1 2 schickt an Lieferschein Auftrag Vertrieb gibt Lieferung Lager an bringt zu Lieferung Kunde 3 4 Fahrer Ziel: Kontexte so schneiden, dass sie in sich konsistent sind und ihre Aufgabe mit minimalen Schnittstellen erfüllen können.
19. A.B.1.Sichten Absichern 2. Zuhören Abgrenzen Schnittheuristiken: Agenten bewerten, Experten entscheiden 1) ADD schlägt erste Schnitte vor 2) Experten liefern Input zum Schneiden 3) Abgestimmte Kontexte ? Input sollte von Experten kommen Falls keine Experten mehr existieren, muss der Input während der Entwicklung kommen Sonst bauen wir Software, ohne den Use Case zu verstehen
20. A.B.1.Sichten Absichern 2. Zuhören Abgrenzen Schnittheuristiken: Agenten bewerten, Experten entscheiden Agentisch bewerten Indizien durch Agenten Experten Input Sprachliche Dopplungen Gleiche Begriffe mit unterschiedlicher Bedeutung Schlüsselereignis Events und Statuswechsel im Code Disjunkter Takt Unterschiedliche Rhythmen im Geschäft Unidirektionale Kommunikation Abhängigkeiten und Aufrufrichtungen im Code Fertiges Arbeitsobjekt Objekte, die abgeschlossen übergeben werden Disjunkte Akteure / Experten Wer arbeitet womit und wer nicht Zeitlich entkoppelt Asynchrone Übergaben, Queues, Batches
21. A.B.1.Sichten Absichern 2. Zuhören Abgrenzen Agentische Grundlage kann oft verfeinert werden Auftragsabwicklung an vergibt 1 2 schickt an Lieferschein Auftrag Vertrieb 3 gibt Lieferung Lager an bringt zu Lieferung Kunde Lieferung 4 Fahrer
22. A.B.1.Sichten Absichern 2. Zuhören Abgrenzen Beispiel Disjunkte Akteure Vertrieb an vergibt 1 Auftragsabwicklung 2 schickt an Lieferschein Auftrag Lieferung Vertrieb 3 gibt Lieferung Lager an bringt zu Lieferung 4 Fahrer Kunde Fertiges Arbeitsobjekt
23. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden Priorisieren welchen Kontext wir zuerst angehen High IV II As late as possible Tackle Risks Early III I Not risky Low-Hanging Fruit Migration Complexity Low Low Business Value High
24. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren Wetten dass die Entwicklung das Risiko, Zeit und Kosten es wert ist 1/3 of features are positive and statistically significant 1/3 of features are flat – no significant difference 1/3 of features are negative and statistically significant
25. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren Wetten Unser Vorgehen ist abhängig von der geschätzten Qualität unserer Testsuite in fachliche ✓ Charakterisierungstests Tests umwandeln können Testcases mit ✓ Wir Anforderungen/Tickets abgleichen. dass alles kritische ✓ Verifizieren, Verhalten geprüft wird. Mutation Testing unsere Tests ✓ Mit verbessern. Testing für kritisches ✓ Property-based Verhalten. Sich hier Zeit nehmen ✗ richtig sein. Ein getestetes Verhalten muss nicht Fachliche Probleme Technische Probleme ✗ coverage 100% Branch-Coverage ist nicht 100% Pfad ✗ mathematisch unmöglich 100% Pfad-Coverage ist kombinatorisch bis ✗ Wir haben nur ein Subset der Inputs überprüft und Inputs können nebenläufig, Math.random(), Time.now(), receive(externalDto) sein. Um hier Risiko zu minimieren
26. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren Wetten Eine Testsuite gibt Feedback, ob sich beobachtetes oder spezifiziertes Verhalten verändert hat.
27. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren Wetten Wir dürfen auch unseren Projektkontext nicht vergessen Kritikalität Verlust von Menschenleben Verlust existenziell notwendiger Mittel Verlust frei verfügbarer Mittel Verlust von Komfort Cockburn Scale https://en.wikipedia.org/wiki/Cockburn_Scale
28. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren Wetten je nach Modul, welcher Ansatz der richtige ist Yolo-Rewrite Methodisches Risiko Agentisches Rewrite mit gestärkter Testsuite Komplexe OpenRewrite Rezepte Known-safe Refactorings im Pair/Mob Hohe Sicherheit Hohe Geschwindigkeit
29. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren 5.Wetten Schneiden Schritt für Schritt aus dem Monolithen herauslösen Monolith Kontextzugehörigkeit von Komponenten kann durch die Grundlage von Agentic Domain Discovery, KI und der vorherigen Abgrenzung schneller identifiziert werden
30. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren 5.Wetten Schneiden Schritt für Schritt aus dem Monolithen herauslösen Erkennen Entkoppeln Bündeln & Port Herauslösen Wiederholen Verteilte Komponenten identifizieren Schrittweise durch Tests abgesicherte Komponenten entkoppeln (bspw. Interfaces) Komponenten zusammenziehen, Interfaces zu einem Port bündeln (bspw. Facade Pattern) Der Kontext wird ein eigenständiges Modul. Der Rest bleibt. Kontext für Kontext, bis der Monolith aufgeteilt ist KI hilft in jedem Schritt zu beschleunigen
31. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren 5.6. Wetten Schneiden Entwickeln Spec-driven Development: Die Spec haben wir schon Spec pro Kontext Fachdoku aus ADD • • • Business-Regeln Szenarien Gemeinsame Sprache • • Szenarien werden zu Akzeptanzkriterien Model to be wrong: alter Fehler nicht übernehmen Validieren mit Menschen Agent baut schrittweise Input • Spec und Glossar Feedback • Fachliche und Charakterisierungstests Erkenntnisse fließen zurück in die Spec Die meisten Teams müssen ihre Spec erst schreiben. Wir haben sie aus dem Altsystem zurückgewonnen • • Prototyp mit Experten und Usern besprechen Alt vs Spec? Mensch entscheidet
32. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren 5.6. Wetten Schneiden Entwickeln Vieles haben wir früher schon gebraucht, jetzt ist es noch wichtiger Früher Gute Softwareentwickler haben ihren Code schon immer mit vielen Mitteln abgesichert. Heute Mit KI ist es umso wichtiger, all das im Hinterkopf zu behalten und verstärkt einzusetzen. Was dazugehört • Domänensprache im Code • Entkoppelte Module • Linter & statische Analyse • Testautomatisierung • Unit- & Integrationstests • E2E- & UI-Tests • Architekturtests (z. B. ArchUnit) • Schnittstellen- & Contract-Tests • Mutation-Testing & Coverage • Last- & Performance-Tests • Und vieles mehr…
33. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren 5.6. Wetten 7. Schneiden Entwickeln Integrieren Von einem neu-gebauten Modul, wenn außerhalb ausgeliefert OldUI NewUI API Legacy Backend Database Das neue Modul API New Backend DB
34. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren 5.6. Wetten 7. Schneiden Entwickeln Integrieren Von einem neu gebauten Modul mit UI a) Separate UIs, user clicks a link OldUI b) Embed NewUI in old UI NewUI API Legacy Backend Database API New Backend DB
35. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren 5.6. Wetten 7. Schneiden Entwickeln Integrieren Von einem neu gebauten Modul (Auszug) OldUI NewUI Content-based router c) Route to Legacy or New API Backend Patterns API New Backend Legacy Backend Database Patterns Database DB
36. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren 5.6. Wetten 7. Schneiden 8. Entwickeln Integrieren Ausliefern Ist essentiell um Feedback zu bekommen Aber was, wenn es technisch sehr riskant ist?
37. A.B.1.Sichten Absichern 2. Zuhören 3.Schneiden 4.Priorisieren 5.6. Wetten 7. Schneiden 8. Entwickeln Integrieren Ausliefern Muss nicht bedeuten, dass es der Anwender auch sieht OldUI NewUI Der Anwender sieht nur Alt Wir können aber Neu mit Alt vergleichen Neu muss dafür mit dem s.g. Null-Auftrag umgehen können Content-based router c2) Route some request BOTH to Legacy and New API Legacy Backend Database API New Backend DB Bekannt als Dark Launches. Ein Tool dazu hieß Github Scientist.
38. Und wieder von Vorne Die richtige Lösung planen 2. Abgrenzen 3. Priorisieren 4. Wetten A. Ausrichten B. Absichern 1. Zuhören Die Lösung Richtig bauen 5. Schneiden 6. Entwickeln Bestand sichern 7. Integrieren 8. Ausliefern
39. Der äußere Feedback-Zyklus sagt, ob wir das Richtige bauen Die richtige Lösung planen Die Lösung Richtig bauen
40. Die inneren Feedback-Zyklen verbessern „nur“ die Auslieferung Domain Expert Prototypes Pair working Unit Test Der wahre Cheat Code agentischer Entwicklung: Code-Prototypen mit Experten/Usern diskutieren
41. Falls jemand fragt, warum man nicht schneller ist Äußerer Zyklus: kann nur durch Unternehmens-Orga verbessert werden Innerer Zyklus: Kann mit agenten Verbessert werden
42. Managed Agentic Evolution (Schrittzusammenfassung) Übergreifender Kontext ADD Schritt Methoden Agentische Aktivierung Vision 1. Zuhören 2. Abgrenzen • Domain Storyt. • Nutzerinterviews • User Tracing • Context Mapping • SchnittHeruistiken /trace /extract-ds /context-map Agenten Trace-Agent, Standard CodingAgent Agentische Artefakte (Output) Output AnwenderInsights.md Mensch (review & entscheide) Validierung Insights Standard CodingAgent Struktur 3. Priorisieren Prinzipien 4. Wetten • Effort/Gain Matrix • Cockburn-Matrix • Cost of Delay • Vorgehens-Scala • RICE Ohne KI Team priorisiert & wettet selbst Output ContextMap.md Validierung Context Entscheidung Priorisierung Entscheidung Vorgehen Jira, Confluence 5. Schneiden 6. Entwickeln 7. Integrieren 8. Ausliefern • Dep. Breaking Patterns • Seems/Ports • Charak. Tests • Unit Tests • Team Prog. • IntegrationsPatterns • Dark Launches • Release auf Knopfdruck /research /cut /research /plan /implement /integrate /verify /watch Standard CodingAgent Standard CodingAgent Standard CodingAgent Prod-WatchAgent Output Schnitt.md Output Research.md, Impl-Plan.md Output IntegrationsPlan.md Output ReleaseInsights.md Review Design Validierung Code, Tests Review Integration Entscheidung Release Die richtige Lösung bauen Die Lösung richtig bauen Nächster Zyklus: zurück zu 1. Zuhören
43. Appendix