So bereiten Sie sich auf KI-gestützte Code-Modernisierungsprojekte vor

In unserer Serie Notes from the Field teilen die Forward-Deployed-Engineers von Anthropic Best Practices, die von echten Kundenimplementierungen inspiriert wurden. In diesem Artikel stellen wir unsere Erfahrungen mit der Verwaltung großer Projekte zur Code-Modernisierung vor.

Code-Modernisierungen, die früher als mehrjährige, umfassende Anstrengungen betrachtet wurden, können jetzt in Monaten (oder Wochen) abgeschlossen werden. Der organisatorische Aufwand auf beiden Seiten bleibt jedoch oft unverändert.

Jede Änderung an einem kritischen Bankensystem muss beispielsweise Änderungsmanagement, Überprüfung und Genehmigung durchlaufen. Es handelt sich hier um einen robusten Prozess, der von Aufsichtsbehörden, Auditoren und Unternehmen verlangt wird.

Diese Prozesse machen kritische Systeme vertrauenswürdig und basieren auf der Annahme, dass jede Änderung von einem Menschen geschrieben und jeder Diff von einem Menschen überprüft wurde. Sobald Agenten das Schreiben der Änderungen beschleunigen, verlagert sich der Engpass von der Erstellung der Änderungen hin zur Mobilisierung der Organisation zum Umgang mit diesen Änderungen.

Dieser Artikel behandelt die Arbeit, die Unternehmen vor der Modernisierung leisten müssen: definieren, was „erledigt“ bedeutet, welche Nachweise für Änderungen erbracht werden müssen, wie zertifizierte Änderungen in die Produktion gelangen und was bereitgestellt werden muss, damit der Betrieb starten kann.

Wir haben diesen Prozess in sechs Schritte unterteilt:

1. Ziel definieren: den Tech-Stack und das Verhalten, das der modernisierte Code aufweisen muss.
2. Zertifikat erstellen: die Bedingungen, die die Änderungen erfüllen müssen, um im Zielstatus als korrekt zu gelten.
3. Promotion-Richtlinie festlegen: den Weg, über den zertifizierte Änderungen in dem Maße, wie sie erstellt werden, in die Produktion übergehen.
4. Voraussetzungen schaffen: Umgebung, CI/CD, Überprüfungskapazität und Genehmigungen.
5. Agentischen Workflow erstellen und verfeinern: den benutzerdefinierten dynamischen Claude Code-Workflow, der die Modernisierung auf viele kleinere, parallele Subagent-Workflows verteilt, die die Änderungen vornehmen. Dies basiert auf der Ziel-, Zertifikats- und Promotion-Richtlinie.
6. Modernisierung durchführen: den End-to-End-Workflow auf einer kleinen Partition der Codebasis testen und dann skalieren.

Schritt 1: Zieldefinition

Das Ziel ist der Endstatus der Modernisierung. Der gewünschte Endzustand bestimmt, welche der drei Modernisierungsarten Sie durchführen, wie in der folgenden Tabelle beschrieben.

Modernisierungstyp bestimmen

Die Frage, welche Art von Modernisierung durchgeführt werden soll, wird oft in Unternehmen diskutiert. Wir haben festgestellt, dass Mitarbeiter, die besonders nah an der Produktion tätig sind, einen Austausch des Stacks bei gleichbleibendem Verhalten wollen, um Risiken zu minimieren (Transformational Modernization). Auf der anderen Seite stehen oft Entwickler, die mit der Codebasis gelebt haben und die Modernisierung nutzen möchten, um technische Schulden abzubauen, sowie andere Business Stakeholder, die die Gelegenheit nutzen möchten, neue Anforderungen zu formulieren (Reimagine Modernization).

Beide Positionen sind nachvollziehbar, aber wenn die Frage ungelöst bleibt, taucht sie später als Diskussion darüber wieder auf, ob eine bestimmte Änderung „richtig“ ist. Die Suche nach einem Konsens darüber, welchen Weg einzuschlagen ist, verursacht zunächst Reibungen, optimiert aber im Endeffekt das Projekt als Ganzes.

Codebasis abbilden und Verhaltensspezifikationen erstellen

Das aktuelle System zu verstehen, ist oft ein guter erster Schritt für die Zieldefinition. Durch die Erfassung der Funktionen des alten Codes und die Erstellung einer Bestandsaufnahme des aktuellen Verhaltens kann leicht entschieden werden, ob Teile geändert oder entfernt werden sollten und ob die Modernisierung eine Transformation oder eine Neugestaltung ist. Dies führt auch oft zur Aufdeckung von unbekannter Geschäftslogik und von Randfällen.

Claude kann einen Großteil dieser Discovery übernehmen, indem es Abhängigkeiten abbildet und Workflows dokumentiert, an deren Erstellung sich niemand mehr erinnert. Die Befehle des Plugins für die Code-Modernisierung assess, map und extract-rules analysieren die Geschäftsregeln samt Quellenangaben, die Entwickler dann prüfen können.

Die Discovery von Claude allein reicht jedoch möglicherweise nicht aus, um das vollständige Verhalten eines Legacy-Systems zu erfassen. Interviews mit Business Usern und Entwicklern sowie interne Dokumentationen können diese Lücken schließen. Die Kontexterfassung kann im Vorfeld einige Zeit in Anspruch nehmen, aber die Qualität dieses Kontexts beeinflusst jede Entscheidung, die der Workflow später trifft.

Für ein „Reimagine“ erfordert die Definition des Zielzustands zusätzliche Arbeit: Eine detaillierte Verhaltensspezifikation sollte schriftlich festgehalten und mit den Benutzergruppen abgestimmt werden.

Begründung und Ziele des Projekts festlegen

Neben der Definition des Ziels sollte das Unternehmen auch überlegen, warum sich die Modernisierung überhaupt lohnt. Die Modernisierung von Legacy-Systemen kann die laufenden Wartungs- und Betriebskosten senken, doch unserer Erfahrung nach war die Kostensenkung bei den meisten Modernisierungsprojekten nicht das Hauptziel.

Ein System mit ungepatchten Schwachstellen kann beispielsweise bei einem schwerwiegenden Cyberangriff oder Ausfall das Unternehmen selbst gefährden. Eine nicht unterstützte Runtime oder eine schrumpfende Gruppe von Entwicklern, die das System verstehen, verschärft das Risiko.

Agentische Coding-Tools wie Claude Code haben die Modernisierungszeiten verkürzt, aber die Budgets sind immer noch schwer einzuschätzen, und dies führt zu Trägheit. Wir haben wie auch andere die Kosten einiger unserer umfangreichen Modernisierungsprojekte veröffentlicht. Diese können als grobe Grundlage dienen. Ferner bieten wir weitere Tipps zur Budgetprognose am Ende dieses Leitfadens.

Die größte Herausforderung bei der Initiierung dieser Projekte besteht gewöhnlich darin, den internen Konsens und das Engagement der Teams zu erreichen, die für das System verantwortlich sind, sowie der Teams, die davon abhängig sind. Die Erstellung eines Business Case und die Festlegung der Ziele des Projekts, oft auf der Führungsebene, erleichtern diesen Aspekt des Prozesses. Auf diese Weise können auch Kompromisse in der folgenden Zertifikats- und Promotion-Richtlinie verankert werden. Wenn sich die Beteiligten darüber uneinig sind, wie viel Risiko eine Änderung mit sich bringen kann, bildet das Risiko, nicht zu modernisieren, das Gegengewicht.

Schritt 2: Zertifikat definieren

Das Zertifikat ist die Reihe von Bedingungen oder Tests, die jede Modernisierungsänderung erfüllen muss. Wählen Sie die Bedingungen aus, die die stärkste kumulative Evidenz dafür liefern, dass die Änderung im Abgleich mit dem Ziel korrekt ist.

Jede Bedingung sollte ohne menschliches Eingreifen überprüfbar sein, sodass der agentische Workflow eine Änderung so lange überarbeiten kann, bis sie die Zertifizierungskriterien erfüllt, oder sie zur Überprüfung durch einen Menschen markieren kann, falls dies nicht möglich ist.

Was in das Zertifikat aufgenommen wird, hängt vom Ziel ab, wird aber normalerweise aus dieser Liste entnommen:

• Die ursprüngliche Testsuite besteht
• Alle von Claude verfassten Tests, die während der Modernisierung geschrieben wurden, bestehen
• Die Testabdeckung erfüllt einen vereinbarten Schwellenwert
• Performance-Benchmarks bleiben innerhalb eines vereinbarten Rahmens
• Unabhängige Adversarial-Reviews durch Claude, jeweils in einem neuen Kontextfenster, finden keine blockierenden Probleme
• Bei Benutzeroberflächen zeigt die Claude-gesteuerte Computernutzung keine Regressionen
• Die aktuelle und die Zielversion erzeugen bei gleicher Eingabe – ob live, aufgezeichnet oder von Claude generiert – die gleiche Ausgabe.
• Persistierter Zustand und Wire-Formate lassen sich verlustfrei zwischen der aktuellen und der Zielversion hin- und zurückkonvertieren
• Änderungen laufen für einen vereinbarten Zeitraum im Staging, ohne dass es zu Regressionen bei Fehlerraten, Latenz oder Warnungen kommt.
• Statische Analysen und Sicherheitsscans zeigen keine neuen Ergebnisse
• Bei kompilierten Zielen ist der Build sauber und die Typprüfung erfolgreich

Ihre Expertise bestimmt, was das Zertifikat misst, und ihre frühzeitige Beteiligung ist es, was ihre Akzeptanz sichert, wenn die Änderungen zur Überprüfung anstehen. Eine guter Test für das fertige Zertifikat ist, ob sie sich damit wohlfühlen, allein auf Basis der Belege des Zertifikats zu mergen. Wenn sie ihre eigenen Maßstäbe wiederfinden, kann die Promotion-Richtlinie in Schritt 3 schlanker ausfallen.

Was das Zertifikat überprüft und wie, hängt vom Modernisierungstyp ab.

• Bei einer Uplift-Modernisierung wird die Parität gegen die ursprüngliche Codebasis geprüft, und die ursprüngliche Testsuite kann den Kern des Zertifikats bilden.
• Bei einer Transform-Modernisierung wird die Parität ebenfalls gegen die ursprüngliche Codebasis geprüft, aber die ursprüngliche Testsuite läuft auf dem neuen Stack nur selten. Stattdessen übernehmen das Replay von Produktionstraffic, Differential Testing zwischen Alt und Neu und ein produktionsparalleles Deployment den Großteil der Arbeit.
• Für eine Reimagine-Modernisierung wird das Zertifikat in der Verhaltensspezifikation verankert. Dies ist der schwierigste Fall. Eine Spezifikation ist weniger objektiv als ein bestehendes System, gegen das man vergleichen kann. Dadurch fließt ein größeres Maß an Modellbewertung ein, was zu variableren Ergebnissen führen kann. Hier basiert das Zertifikat auf Tests, die aus der Spezifikation hervorgehen, unabhängigen gegnerischen Prüfungen durch Claude, die jede Änderung anhand der Spezifikation überprüfen, sowie Differentialtests, bei denen das neue System das Verhalten des alten beibehält. Rechnen Sie damit, dass Sie das Zertifikat überarbeiten müssen, wenn die Spezifikation geklärt wird: Lücken in der Spezifikation werden hier zuerst angezeigt.

Ältere Systeme haben oft eine geringe Testabdeckung, unzuverlässige Tests und wenig Telemetrie. Teil der Definition des Zertifikats ist die Identifizierung dieser Lücken. Wenn es schwierig ist, ein belastbares Zertifikat zu stützen, ist es in diesem Schritt oft am nützlichsten, mit Hilfe von Claude die fehlenden Belege zu erzeugen, sei es durch die Erstellung eines produktionsparallelen Setups, die Entwicklung eines Replay-Harness oder das Schreiben weiterer Tests.

Schritt 3: Promotion-Richtlinie festlegen

Agenten erzeugen Änderungen wesentlich schneller, als ein menschliches Team sie Änderung für Änderung prüfen kann. Die Promotion-Richtlinie ist ein gestufter Prüfpfad, der im Voraus schriftlich vereinbart wird und die Tiefe der menschlichen Prüfung einer Änderung festlegt, damit die Modernisierung in einem akzeptablen Zeitrahmen abgeschlossen werden kann.

Arbeiten Sie diesen Schritt wie das Zertifikat mit den Prüfern aus und fügen Sie ihn, wo immer möglich, in den bestehenden Change-Management-Prozess Ihrer Organisation ein. Die Details variieren je nach Organisation und den Risikoabwägungen, denen sie ausgesetzt ist. Einige Regeln gelten jedoch überall:

• Stufen Sie Änderungen nach Blast Radius und Zuversicht des Agenten ab. Verwenden Sie die Änderungs- oder Risikoklassifizierung Ihrer Organisation, falls vorhanden. Behalten Sie die vollständige menschliche Überprüfung für kritische Pfade bei.
• Beheben Sie wiederkehrende Flags an der Quelle. Gruppieren und analysieren Sie die markierten Änderungen im Laufe der Zeit. Wenn immer wieder dieselbe Art von Flag auftritt, beheben Sie die Ursache im agentischen Workflow oder im Zertifikat, anstatt jedes einzelne Flag zu überprüfen.
• Gestalten Sie das Ausgabeformat gemeinsam mit den Prüfern. Vereinbaren Sie, welche Informationen und welches Format die Prüfung am meisten beschleunigen und welche Signale mehr Vertrauen schaffen als andere. Lassen Sie sie die ersten Beispielausgaben in Schritt 5 prüfen.
• Planen Sie die Zeit der Fachexperten effektiv ein. Fachexperten werden nicht jeden finalen Diff lesen, aber ihr Urteil bleibt die knappe Ressource. Machen Sie es ihnen leicht, direkt zu den Änderungen in den risikoreichsten Stufen zu springen und auf die markierten Entscheidungen des Agenten in jeder Stufe zuzugreifen, ohne sich durch große Diffs kämpfen zu müssen. Eine geringe Anzahl an Expertenstunden deckt dann die Änderungen ab, die das größte Risiko bergen.

Viele dieser Regeln verlagern den Einsatz der Fachexperten nach vorn, indem sie diese frühzeitig in das Projekt einbinden. Deren Feedback passt das Zertifikat und den agentischen Workflow an, bevor die vollständige Modernisierung beginnt.

Ihre Freigabe der Stichproben ist auch eine weitere Rechtfertigung für einen leichtgewichtigeren Prüfpfad, wo die Konfidenz hoch ist. Dies ist das Gegenteil des herkömmlichen, nicht-agentischen Musters, bei dem die Prüfung am Ende erfolgt.

Die Promotion-Richtlinie sollte auch widerspiegeln, wo die Modernisierung im Spektrum zwischen Geschwindigkeit und Prüfungstiefe liegt. Eine Modernisierung, die auf eine feste Frist zusteuert, etwa weil eine Laufzeitumgebung aus dem Support fällt, erfordert eine schnellere Richtlinie mit weniger menschlichen Prüfungen und eine ausdrückliche Vereinbarung, pro Änderung ein höheres Risiko in Kauf zu nehmen.

Eine Modernisierung mit längerem Zeithorizont kann sich eine tiefere menschliche Prüfung und eine langsamere Umstellung leisten. Da die Stakeholder je nach Risikobereitschaft und Rahmenbedingungen an verschiedenen Punkten dieses Spektrums landen werden, lohnt es sich, dies vor Beginn der Arbeiten verbindlich festzulegen.

In einem regulierten Umfeld kann die Wahl eines weniger aufwendigen menschlichen Prüfverfahrens für Änderungen echtes Unbehagen auslösen. Einzelne Genehmiger zögern, ihre Zustimmung zu erteilen, da sie das Risiko einer schlechten Änderung tragen, während die Führung das größere Risiko eines veralteten Systems trägt.

Unserer Erfahrung nach ist es am besten, wenn die Anweisungen für die Promotion-Richtlinien von der Spitze des Unternehmens kommen. Es ist auch besser, sich vorher zu einigen, damit die Verantwortung für einen Fehler, der in die Produktion gelangt, gemeinsam getragen wird und nicht demjenigen zugeschrieben wird, der die Änderung genehmigt hat.

Schritt 4: Voraussetzungen schaffen

Ein Großteil dieses Schritts läuft über Teams außerhalb der Modernisierung ab: Plattform oder Infrastruktur für den Host, QS oder Release Engineering für die Testkapazität, Sicherheit und Compliance für Freigaben. Jedes dieser Teams hat oft ein eigenes Backlog oder seinen eigenen Freigabeprozess. Beginnen Sie daher frühzeitig mit den Gesprächen, sobald die Anforderungen feststehen, häufig noch während die Schritte 1 bis 3 laufen.

Umgebung

• Ein dedizierter Remote-Host für die Ausführung des Workflows, wobei die Codebasis und andere relevante Quellen für Claude erreichbar sind
• Testkapazität in dem Umfang, die das Zertifikat fordert
• Alles, was das Zertifikat stützt: Produktionstelemetrie, ein Parallelbetrieb in Produktion oder Produktionsdaten für das Replay

Codebasis und CI/CD

• Eine Abhängigkeitskarte der Codebasis basierend auf Build- und Compile-Logs, Importanalysen oder Laufzeit-Traces. Hinweis: Der map-Befehl des Plugins ist ein guter Ausgangspunkt, wobei je nach Größe und Alter der Codebasis möglicherweise umfangreichere Vorarbeiten erforderlich sind.
• Geplanter Umgang mit allen Abhängigkeiten und Paketen, als Teil der Zieldefinition
• Eine Kompatibilitätsprüfung, die bei Bedarf zu CI/CD hinzugefügt werden kann
• Eine vereinbarte Code-Freeze-Richtlinie, falls Sie eine Modernisierung im laufenden Betrieb durchführen
• Ein Kommunikationsplan für aktive Entwickler, der alle Code-Freezes und neue Kompatibilitätsanforderungen abdeckt

Teams und Prüfung

• Zustimmung anderer Teams, die von der Codebasis abhängen, darüber, wie sie sich beteiligen, z. B. die Genehmigung des Zertifikats oder die Prüfung gemäß der Promotion-Richtlinie, wobei Prüferzeit eingeplant ist

Sicherheit und Compliance

• Ein Modellzugriffspfad für Claude Code, der für Quellcode genehmigt wurde
• Zugriff nach dem Least-Privilege-Prinzip für den agentischen Workflow: Schreibzugriff nur auf Modernisierungs-Branches und keine Zugangsdaten für die Produktion
• Secrets und personenbezogene Informationen (PII) aus dem Modernisierungs-Branch entfernt oder maskiert
• Jede Änderung ist nachvollziehbar und jede PR ist mit einem Agenten-Transkript sowie einem Zertifikatsnachweis verknüpft
• Lizenz- und Schwachstellenprüfungen für neue Abhängigkeiten

Schritt 5: Agentischen Workflow entwickeln und verfeinern

Verwenden Sie Claude Code, um einen benutzerdefinierten dynamischen Workflow für die Modernisierung der Codebasis zu entwickeln.

Wir empfehlen, mit dem Plugin für die Code-Modernisierung zu beginnen und alles, was der Workflow benötigt, im Dateisystem oder über MCP zu hinterlegen, wo Claude darauf zugreifen kann. Dazu gehören das Ziel, das Zertifikat, die Promotion-Richtlinie, die Codebasis und die Dokumentation sowie alle Datenquellen oder Tools, die für das Zertifikat erforderlich sind. Sie können Claude auch diesen Artikel als Kontext geben. Dies bildet die zentrale Wissensbasis für das Projekt.

Sobald dies eingerichtet ist, ist die Erstellung des Modernisierungs-Workflows der einfache Teil. Lassen Sie bei Bedarf die Arbeit von Claude von Fachexperten überprüfen, einschließlich codebasenspezifischer Fähigkeiten oder extrahierter Regeln, bevor sich nachgelagerte Prozesse darauf stützen.

Verfeinern Sie Ihre Entwicklungen, indem Sie sie auf kleine Teile der Codebasis anwenden, wobei Fachexperten die dadurch hervorgerufenen Änderungen, den Prozess der Agenten und den Nachweis prüfen, dass die Zertifizierungsanforderungen erfüllt wurden.

Schritt 6: Modernisierung durchführen

Führen Sie zunächst die Modernisierung für einen kleinen Teil der Codebasis vollständig durch, einschließlich der Überprüfung und Übernahme der Änderungen gemäß der Promotion-Richtlinie. Beheben Sie alles, was nicht funktioniert, solange es noch kostengünstig ist, wiederholen Sie den Prozess, bis Sie sich sicher sind, und skalieren Sie dann auf die gesamte Codebasis.

Während Modernisierungen vom Typ „Transform“ und „Reimagine“ beinhalten, das Zielsystem parallel zum bestehenden System aufzubauen und nach Fertigstellung umzustellen, bietet ein „Uplift“ eine zweite Option: die Modernisierung direkt in der laufenden Codebasis, während die Entwicklung fortgesetzt wird.

Dies ist die übliche Wahl, wenn das System nicht ausfallen kann oder wenn sich die Codebasis so schnell ändert, dass es schwierig ist, eine separate, modernisierte Kopie auf dem neuesten Stand zu halten. Was wir in diesem Fall als erfolgreich erlebt haben, ist die Aufteilung der Codebasis in logische Partitionen von den Leaves nach innen; das Einfrieren und Modernisieren einer Partition nach der anderen; sowie die Absicherung der CI/CD-Pipeline, sodass neue Commits eine Partition nach der Modernisierung nicht rückgängig machen können.

Hinweis zu Kosten

Wir werden oft gefragt, was eine solche Modernisierung in Tokens kosten wird. Jedes Modernisierungsvorhaben ist anders, aber zu den wichtigsten Kostentreibern zählen:

• Welcher Anteil der Codebasis gelesen vs. geändert werden muss;
• Wie aufwendig das Zertifikat ist (in einem regulierten Umfeld macht die Überprüfung, nicht das Schreiben der Änderung, gewöhnlich den größeren Teil aus);
• Wie viel neues Testschreiben und wie viel Testreparatur das Zertifikat erfordert und
• Wie viel Abstimmungsaufwand dadurch entsteht, dass andere Teams während der laufenden Ausführung ihre Änderungen um Sie herum einspielen.

Die Messungen aus dem Pilotprojekt zeigen auch, wo Sie Ihren agentischen Workflow hinsichtlich der Kosten optimieren können. Finden Sie heraus, welche Teile des Workflows die meisten Tokens verbraucht haben, und überlegen Sie, wie Sie diese effizienter gestalten können. Verschieben Sie rechenintensive Verifizierungssignale hinter günstigere Gates, damit sie erst laufen, wenn die einfacheren Prüfungen bestanden sind.

Ziehen Sie Modelle wie Sonnet in Betracht, die ein Gleichgewicht zwischen Kosten und Leistungsfähigkeit für die mechanischen, umfangreichen Arbeiten bieten, die das Zertifikat vollständig abdeckt. Verwenden Sie intelligentere Modelle für schwierige Transformationen sowie für Adversarial Reviews, die die Korrektheit sicherstellen.

Sie können auch auf ein teureres Modell eskalieren, wenn ein günstigeres Modell das Zertifikat nicht erfüllt. Analysieren Sie jedoch die Wiederholungsraten während der Pilotphase sorgfältig, da mehrere günstige Versuche mehr kosten können als ein teurerer Versuch. Wenn Sie Claude Zugriff auf den Workflow und die Pilotdaten gewähren, kann es einen Großteil dieser Analysen mit Ihnen durchführen.

Über die Modernisierung hinaus

Die modernisierte Codebasis ist ein Ergebnis. Die anderen sind der Workflow, der dazu geführt hat, ein schriftliches Zertifikat darüber, was als korrekt gilt, eine Promotion-Richtlinie, die Ihr Change-Management-Prozess bereits akzeptiert hat, sowie eine lückenlose Dokumentation für jede Änderung, die implementiert wurde. Halten Sie das Playbook als wiederverwendbares Asset fest, damit das Muster beim nächsten Upgrade oder Rewrite bereits vorhanden ist.

Unsere Forward Deployed Engineers arbeiten diese Schritte gemeinsam mit den Kunden an deren kritischsten Systemen durch. Wenn Sie eine Modernisierung vorbereiten, sprechen Sie mit unserem Team.

Weitere Ressourcen

• Das öffentliche codemod-Plugin für Claude Code
• Das KI-native SDLC-Playbook
• Playbook zur Code-Modernisierung
• COBOL-Modernisierung mit KI: Die Kostenhürde überwinden