Automatisierte Abhängigkeits-Upgrades & groß angelegtes Refactoring von Codebasen

Jede Organisation mit mehr als wenigen Repositories sammelt veraltete Laufzeitumgebungen, Frameworks und Bibliotheken an. Upgrades sind mühsam, repetitiv und werden stets aufgeschoben, bis eine Schwachstelle oder ein Support-Ende sie erzwingt. Die moderne Antwort verbindet deterministische Code-Transformationsrezepte (Umschreibungen des abstrakten Syntaxbaums) mit LLM-Agenten, die den langen Rest erledigen, und eröffnet Pull Requests, die erst nach bestandener CI gemergt werden. Das Ergebnis: Wartung läuft als kontinuierlicher Hintergrundprozess statt als jährliches Projekt.

Problem & Nutzen

• Heute: Entwickler lesen Migrationsleitfäden, heben Versionen von Hand an, beheben Kompilierfehler und fehlschlagende Tests, wiederholen das für jedes Repository und schieben es oft auf. Bots wie Dependabot und Renovate heben Versionen an, können den Quellcode aber nicht an inkompatible API-Änderungen anpassen.
• KI-Nutzen: Der Agent (oder das Rezept) nimmt die Quellcode-Änderungen vor, die eine Versionsanhebung erfordert, führt Build und Tests aus, iteriert bei Fehlern und dokumentiert das Ergebnis. Zentrale Teams können eine unternehmensweite Änderung (z. B. eine Logging-Bibliothek ersetzen, auf ein neues Auth-SDK umstellen) über hunderte Repositories ausrollen, statt jedes Team darum zu bitten.
• Treiber: Support-Enden von Laufzeitumgebungen (z. B. Java-LTS-Versionen, Python- und Node.js-Releases), verwundbare transitive Abhängigkeiten und in der EU der Cyber Resilience Act, der Hersteller von Produkten mit digitalen Elementen verpflichtet, Schwachstellen zu behandeln und über den Supportzeitraum Sicherheitsupdates bereitzustellen [1].

Varianten

• Abhängigkeitspflege: automatische Versionsanhebungen, Lockfile-Updates, Beseitigung transitiver Schwachstellen, gruppierte PRs.
• Framework- und Laufzeit-Upgrades: Java 8/11 auf 17/21, Spring Boot 2 auf 3 (javax auf jakarta), JUnit 4 auf 5, Python-3.x-Anhebungen, Angular/React-Hauptversionen, .NET Framework auf modernes .NET.
• Flottenweite Kampagnen und Entfernung veralteter APIs: unternehmensweite SDK-/Logging-Änderungen, neue Sprachfunktionen, veraltete Aufrufe ersetzen, neue Sprachfunktionen übernehmen, Test-Frameworks migrieren.

So funktioniert es

1. inventory (all repos, build files, SBOM, dependency graph)
2. select campaign (target version / policy / advisory)
3. deterministic recipes (OpenRewrite-style AST rewrites, codemods) applied per repo
4. LLM agent for residual errors (compile failures, test failures, custom APIs)
5. build + tests + static analysis in CI (sandboxed)
6. PR with change summary, risk notes, link to migration guide
7. human review / auto-merge by policy
8. fleet dashboard, retry failed repos

• Zuerst Rezepte: Deterministische, wiederholbare Transformationen über einen verlustfreien semantischen Baum des Codes (OpenRewrite) sind günstig, prüfbar und halluzinieren nicht. Sie decken den bekannten, mechanischen Teil einer Migration ab [2].
• Danach das LLM: Ein Agent liest Compiler- und Testausgaben, durchsucht das Repository und die Dokumentation und behebt, was Rezepte nicht leisten können (projektspezifische Wrapper, Verhaltensänderungen, instabile Tests). Manche Werkzeuge lassen ein LLM auch einmalig ein neues Rezept verfassen und es dann überall anwenden.
• Prüfschleife: Build und Tests sind das Orakel. Ohne aussagekräftige Tests kann ein Upgrade kompilieren und trotzdem das Verhalten ändern; Testabdeckung (siehe CODE-004) ist daher Voraussetzung.
• Mensch-in-der-Schleife (Human-in-the-Loop): Eine Richtlinie legt fest, welche PRs automatisch gemergt werden (Patch-Anhebungen mit grüner CI) und welche eine Prüfung brauchen (Hauptversionen, sicherheitsrelevante Module, geringe Testabdeckung).

Datenaufbereitung

Die „Daten“ sind hier überwiegend Code: Quell-Repositories, Build-Dateien und Lockfiles, CI-Pipelines und Testsuiten. Im Mittelstand liegen sie in GitHub/GitLab/Bitbucket, manchmal auch auf Dateiservern oder alten SVN-Servern; ein Inventar der vorhandenen Repositories fehlt häufig.

Typische Lücken: Repositories ohne automatisierte Tests (das größte Hindernis, weil sich das Upgrade nicht verifizieren lässt), nicht festgelegte oder uneinheitliche Abhängigkeitsversionen, defekte oder langsame CI, vergessene Forks, keine Liste der Verantwortlichen je Repository und Geheimnisse (Secrets) im Code.

Vorbereitungsschritte: 1. Alle Repositories inventarisieren und für jedes eine verantwortliche Person benennen (PREP-004). 2. Builds reproduzierbar machen: Lockfiles, Container-Builds, eine CI-Pipeline je Repository. 3. Vor dem ersten Agentenlauf eine minimale Testbasis (Smoke-Tests) für die kritischsten Repositories ergänzen. 4. Eine Upgrade-Richtlinie (Zielversionen, verbotene Bibliotheken) als maschinenlesbare Konfiguration festlegen. 5. Secrets aus dem Code entfernen und die Token-Rechte des Bots einschränken.

Werkzeuge: SBOM-Generatoren, OSV-Scanner, Renovate-/Dependabot-Konfiguration. Aufwandsanteil: gering, etwa 10 bis 20 Prozent des Projekts, fehlende Tests können daraus aber die Hauptaufgabe machen. Siehe auch GUIDE-003 und PREP-005 für Exporte aus Altsystemen.

Umsetzungswege

Welcher Weg für wen

• smb (A): Renovate, Dependabot oder Upgrade-Agenten im Stil von Copilot sind ausgereift, günstig und brauchen für eine Handvoll Repositories keine eigene Integration.
• enterprise (B): Bei hunderten Repositories, eigenen Richtlinien und eigener CI passt ein individueller Flotten-Orchestrator (Rezepte plus LLM-Agent über API) besser als Produkte mit Lizenz pro Nutzer.
• developer (C): Selbst betriebenes Renovate und OpenRewrite mit einem lokalen Open-Weight-Codemodell halten den Quellcode auf dem eigenen Rechner, ohne Lizenzkosten.
• public (C): Behörden sollten Renovate/OpenRewrite auf dem eigenen GitLab mit einem souveränen oder lokalen Modell betreiben, da Quellcode und Vergaberegeln die Nutzung von SaaS begrenzen.

Weg A — Kaufen (Standardsoftware) (für die meisten Organisationen empfohlen)

• Rezepte plus Plattform: Moderne (Plattform rund um OpenRewrite, Massen-PRs und Wirkungssuche über Repositories hinweg; bietet auch eine Werkzeugschicht für Agenten) [2]. OpenRewrite selbst ist Open Source; die kommerzielle Plattform ergänzt Skalierung, SaaS- oder On-Premises-Betrieb und Dashboards.
• Agenten der Cloud-Anbieter: AWS Transform / Amazon Q Developer Transformation für Java-Versions- Upgrades und .NET-Modernisierung [3]; Google und Microsoft bieten vergleichbare Upgrade-Assistenten (z. B. GitHub Copilot app modernization für Java und .NET).
• Abhängigkeits-Bots: GitHub Dependabot, Renovate (Mend; Open Source) für die Ebene der Versionsanhebung [4].
• Coding-Agenten: Claude Code, Copilot Coding Agent, Codex, Cursor, Devin eignen sich für einzelne Repositories, weniger für gesteuerte Flotten-Kampagnen.
• EU-Optionen: wenige spezialisierte EU-Anbieter; JetBrains (CZ) bietet IDE-Refactoring, GitLab Self-Managed läuft in der EU; Datenresidenz prüfen (EU-Regionen, On-Premises-Runner).

Weg B — Auf Cloud-KI-Diensten aufbauen

• Einen eigenen Agenten orchestrieren: ein führendes Code-Modell (Claude, GPT, Gemini, Mistral Codestral/Devstral über die in der EU gehostete Mistral-API) in einer Sandbox mit Werkzeugen für Checkout, Build, Test und Suche, ausgelöst durch Renovate-/Dependabot-Ereignisse oder einen Kampagnen-Planer.
• Mit OpenRewrite-Rezepten als Werkzeugen kombinieren, die der Agent aufrufen kann, sowie mit einem Repository-Graphen oder Code-Suchindex (Sourcegraph, auf tree-sitter basierend) für die Wirkungsanalyse.
• Anbindung an die APIs von GitHub/GitLab/Bitbucket für das Erstellen von PRs und an die CI als Orakel.

Weg C — Selbst betreiben (Open Source)

• Rezepte und Bots: OpenRewrite (Lizenz je Rezeptmodul prüfen), Renovate (selbst betrieben), Dependabot (GitHub Enterprise Server), jscodeshift, Rector (PHP), libcst/pyupgrade und go fix/gopls-Modernizer.
• Modelle: Open-Weight-Codemodelle wie Qwen3-Coder, Devstral, DeepSeek-Coder-V3-Klasse oder gpt-oss, betrieben mit vLLM oder Ollama; Agenten-Rahmen wie OpenHands, Aider, Cline.
• Hardware: HW2 für Modelle der ~30B-Klasse bei Restfehlern; HW3/HW4 für stärkere agentische Modelle. Isolierte CI-Runner sind der größere Betriebsaufwand als die GPU.

Weg D — Eigenes Training

Selten gerechtfertigt; eigene Rezepte und bessere Tests schlagen in der Regel ein Feintuning auf akzeptierte PRs.

Stand der Technik (2026)

• Der Hybrid gewinnt: deterministische Rezepte für den Großteil, LLM-Agenten für den Rest, die CI als Richter. Reine LLM-Upgrades sind teurer, weniger wiederholbar und anfällig für unbemerkte Verhaltensänderungen.
• Agentische Upgrade-Produkte der Cloud-Anbieter bewältigen heute mehrstufige Java- und .NET-Upgrades mit Build-und-Test-Schleifen; die Ergebnisse schwanken stark mit Testqualität und Komplexität der Abhängigkeiten [3].
• Agenten-Werkzeuge für Rezepte: Anbieter stellen Rezeptkataloge und semantische Codesuche für Coding-Agenten Dritter bereit (z. B. über MCP), sodass allgemeine Agenten präzise Werkzeuge im großen Maßstab nutzen können [2].
• Veraltetes Wissen: Modelle erzeugen oft veraltete APIs; das Abrufen aktueller Release Notes hilft.
• Grenzen und Fehlerbilder: Verhaltensregressionen, die Tests nicht abdecken, halluzinierte oder nicht existierende Paketversionen (auch ein Lieferkettenrisiko durch „Slopsquatting“), ungeprüfte transitive Upgrades, instabile Tests, die als Upgrade-Fehler gedeutet werden, PR-Fluten, die Prüfende überlasten, und Lizenzänderungen in neuen Versionen.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (llm-code + agent-framework + isolierte CI): CODE-002 Coding-Agenten, CODE-014 Fehler- behebung und CODE-005 Legacy-Modernisierung teilen sich Agenten-Rahmen und isolierte Runner.
• Vorgelagert: CODE-004 Testgenerierung erhöht die Abdeckung vor einer Upgrade-Kampagne; CODE-006 Dokumentation hilft Agenten, interne Frameworks zu verstehen.
• Nachgelagert: CODE-003 KI-Code-Review für die erzeugten PRs; SEC-004 für schwachstellengetriebene Upgrades; CODE-009 für Upgrades von Terraform-Providern und Kubernetes-Manifesten.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen für einen Piloten mit wenigen Repositories; Lizenz pro Repository oder pro Codezeile bzw. Preise für Cloud-Agenten pro transformierter Zeile (Preisseiten der Anbieter prüfen).
• Weg B: 1-3 Monate für eine gesteuerte Pipeline; Kostentreiber sind Tokens je Repository, CI-Minuten und Prüfzeit.
• Weg C: 2-4 Monate einschließlich isolierter Runner und Modellbetrieb.
• Kennzahlen: Anteil der Repositories auf unterstützten Laufzeit-/Framework-Versionen, durchschnittliches Alter der Abhängigkeiten, Zeit bis zum Patchen einer kritischen Schwachstellenmeldung, Merge-Quote von PRs ohne manuelle Änderungen, CI-Erfolgsquote der erzeugten PRs, Prüfminuten je PR, auf automatisierte PRs zurückgeführte Regressionen.

Menschen & Veränderung

Früh einbinden: Die Geschäftsleitung (Budget, Risikobereitschaft) und die Abteilungsleitung Entwicklung entscheiden über den Umfang. IT und IT-Sicherheit legen Bot-Berechtigungen, Token-Geltungsbereiche und die erlaubten Modell-Endpunkte fest; Recht/Compliance prüft Lizenzregeln für vorgeschlagene Bibliotheken. Endnutzer sind die Entwickler, die die Pull Requests prüfen, binden Sie sie daher ab dem ersten Pilottag ein.

Betriebsrat: in der Regel nein. Der Bot ändert Code, nicht das Verhalten von Beschäftigten, und bewertet keine Einzelpersonen. Zeigen Dashboards künftig Merge- oder Review-Statistiken je Entwickler, greift §87(1) Nr. 6 BetrVG. Informieren Sie den Betriebsrat dennoch nach §90(1) Nr. 3 BetrVG, wenn sich Arbeitsabläufe ändern; öffentliche Stellen informieren den Personalrat. Eine(n) Datenschutzbeauftragte(n) bzw. eine DSFA braucht es normalerweise nicht, da über die Namen der Commit-Autoren hinaus keine personenbezogenen Daten verarbeitet werden.

KI-Kompetenz: Fördern Sie die Fähigkeiten der Entwickler (Art. 4 KI-Verordnung) mit einer kurzen Schulung zum Prüfen KI-generierter Diffs und zu Prompt-Injection-Risiken aus Changelogs von Abhängigkeiten (GUIDE-006, GUIDE-013).

Pilot und Kommunikation: Beginnen Sie mit 3 bis 5 risikoarmen Repositories und einem freiwilligen Team; veröffentlichen Sie die Merge-Quote und die Zahl zurückgenommener PRs offen. Typische Sorge: „Der Bot legt die Produktion lahm.“ Antwort: kein Auto-Merge, die CI muss bestehen, ein Mensch genehmigt jeden PR, der Rollback ist ein Klick. Stellen Sie es als Wegfall einer lästigen Pflicht dar, nicht als Ersatz für Menschen (GUIDE-008, GUIDE-009).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko für Entwicklerwerkzeuge; die Pflicht zur KI-Kompetenz (Art. 4) gilt. Code in sicherheitskritischen Produkten bleibt unter den Sektorregimen (z. B. Medizinprodukte, Maschinen), wo Änderungen unabhängig vom Urheber eine dokumentierte Verifikation brauchen.
• Cyber Resilience Act und NIS2: fördern zeitnahe Updates und Schwachstellenbehandlung; automatisierte Upgrades mit nachvollziehbaren PRs und SBOM-Updates stützen die Nachweiskette [1].
• DSGVO: Quellcode kann personenbezogene Daten enthalten (Testdaten, fest einprogrammierte E-Mail-Adressen, Secrets). Nutzen Sie EU-Regionen oder Selbstbetrieb, einen Auftragsverarbeitungsvertrag (AVV) und Secret-Scanning, bevor Code an externe Modelle gesendet wird.
• Sicherheit: Agenten führen nicht vertrauenswürdige Build-Skripte aus - in kurzlebigen Sandboxes ohne Produktionszugangsdaten isolieren; Paketnamen, Hashes und Herkunft festschreiben und prüfen; Prompt-Injection über Release Notes oder READMEs ist möglich.
• Gegenmaßnahmen: nur bei grüner CI mergen, gestufter Rollout (Canary-Repositories), verpflichtende menschliche Prüfung bei Hauptversionen, Audit-Log der Agentenaktionen.

Erste Schritte

1. Ein Inventar erstellen: Repositories, Sprachen, Laufzeit-/Framework-Versionen, SBOM, Testabdeckung.
2. Renovate oder Dependabot mit gruppierten PRs und Auto-Merge für Patch-Updates bei grüner CI aktivieren.
3. Eine Kampagne pilotieren (z. B. Java 17 auf 21 oder Spring Boot 2 auf 3) auf 5-10 Repositories mit OpenRewrite-Rezepten, danach einen LLM-Agenten für Fehlschläge ergänzen.
4. Merge-Richtlinie, Sandbox-Regeln und ein Dashboard für den Flottenstatus festlegen.
5. Kampagne für Kampagne ausweiten; Kennzahlen und den Anteil manueller Arbeit festhalten.

Quellen

1. European Commission - Cyber Resilience Act - https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
2. OpenRewrite documentation - https://docs.openrewrite.org/
3. AWS - AWS Transform / Amazon Q Developer code transformation docs - https://docs.aws.amazon.com/transform/latest/userguide/what-is-service.html
4. Renovate documentation - https://docs.renovatebot.com/
5. GitHub Dependabot documentation - https://docs.github.com/en/code-security/dependabot
6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj