Nach dem Livestream zur Legacy-Code-Modernisierung mit Claude Code 2026: Was sollte das Team zuerst prüfen?

Die offizielle Veranstaltungsseite nennt für den Livestream zur Modernisierung mit Claude Code zwei Beispieltypen: eine Migration von COBOL zu Java und ein umfangreiches Upgrade einer Java-Version. Diese Beispiele sind ein Anlass für einen Pilotversuch, aber kein Nachweis, dass Ihr Repository sicher migrierbar ist. Prüfen Sie zuerst Build- und Testbaseline, fachlich bestätigtes Verhalten und eine isolierte Arbeitsumgebung; erst danach sollten Sie über einen größeren Einsatz entscheiden. Anthropic führt diese Beispiele auf der Veranstaltungsseite auf.

Zuletzt geprüft am 24.09.2026. Abgleich der Veranstaltungsangaben mit der offiziellen Anthropic-Veranstaltungsseite und den unten verlinkten Produkt- und Dokumentationsseiten. Für nachträglich veröffentlichte Aufzeichnungen oder Erläuterungen sollten Sie die offiziellen Quellen erneut prüfen.

Dieser Beitrag ist für Sie gedacht, wenn Sie als Entwicklerin oder Entwickler die Demo in einen konkreten Repository-Versuch übersetzen möchten, als Verantwortliche für ein Altsystem den ersten Modernisierungsschritt bestimmen oder als technische Führungskraft Vorführung und eigene Prüfergebnisse sauber auseinanderhalten müssen.

Was die Demo belegt – und was Ihr Team selbst herausfinden muss

Die offizielle Ankündigung beschreibt die genannten Modernisierungsbeispiele. Daraus dürfen Sie ableiten, dass die Veranstaltung solche Aufgaben zeigen soll. Sie dürfen daraus nicht ableiten, dass Claude Code jede COBOL- oder Java-Codebasis ohne zusätzliche Prüfung zuverlässig umstellt. Eine Vorführung kann weder die Abhängigkeiten Ihres Projekts noch interne Datenregeln, betriebliche Schnittstellen oder die Anforderungen Ihrer Zielplattform für Sie bestätigen.

Das ist vor allem bei einer Legacy-Code-Migration wichtig: Zwei Systeme können dieselbe Programmiersprache verwenden und sich trotzdem in Datenformaten, Bibliotheken, Build-Schritten oder historisch gewachsenen Verhaltensregeln stark unterscheiden. Auch ein syntaktisch plausibler Vorschlag kann eine fachliche Sonderbehandlung entfernen, wenn sie im Quellcode nur indirekt erkennbar ist.

Die offizielle Anthropic-Handreichung zur Code-Modernisierung kann als ergänzende Orientierung dienen. Behandeln Sie sie wie die Demo als Prozessmaterial, nicht als Abnahme Ihres konkreten Systems: Die Belege für Eignung und Qualität müssen aus Ihrem Repository und von den dafür verantwortlichen Personen kommen.

Einordnung: Eine überzeugende Erklärung des Agenten ist eine Hypothese über den vorhandenen Code. Sie wird erst dann zur belastbaren Aussage, wenn sie mit Tests, dokumentiertem Verhalten oder einer fachlichen Bestätigung übereinstimmt.

Zuerst eine reproduzierbare Ausgangslage herstellen

Ohne Ausgangslage können Sie nach einer Änderung nicht zuverlässig entscheiden, ob sich das System verbessert, ob ein Fehler neu entstanden ist oder ob schon der ursprüngliche Build nicht reproduzierbar war. Erfassen Sie deshalb vor dem Pilot die verwendete Sprach- und Laufzeitversion, relevante Abhängigkeiten, den Build-Befehl und die tatsächlich ausgeführten Tests. Halten Sie auch fest, welche Tests nicht laufen und warum.

Eine Baseline muss nicht bedeuten, dass Ihr gesamtes Altprojekt bereits umfassend getestet ist. Sie muss aber ehrlich zeigen, was Sie geprüft haben und was offenbleibt. Bewahren Sie vorhandene Build- und Testergebnisse zusammen mit dem verwendeten Commit auf. Für Teams, die eine CI-Pipeline einsetzen, erläutert die GitHub-Dokumentation den Aufbau von Workflows; Informationen zur Ablage und Weitergabe von Build- und Testartefakten helfen dabei, Prüfergebnisse nachvollziehbar verfügbar zu halten.

Wenn die bestehende Testabdeckung schwach ist, ergänzen Sie vor dem Eingriff eine kleine Zahl fachlich relevanter Prüfungen, statt eine scheinbar präzise Abdeckung zu behaupten. Wählen Sie dabei Abläufe, deren Eingaben und erwartete Ergebnisse eine zuständige Person nachvollziehbar bestätigen kann. Unklare Stellen markieren Sie ausdrücklich als offene Risiken.

Vor dem Start abhaken:

• [ ] Build-Befehl und vorhandene Toolchain sind dokumentiert.
• [ ] Der Ausgangsstand lässt sich mit denselben Schritten erneut bauen.
• [ ] Bestehende Tests sind den betroffenen Modulen zugeordnet.
• [ ] Fehlgeschlagene oder nicht ausführbare Tests sind als Ausgangsbefund festgehalten.
• [ ] Build- und Testergebnisse werden dem geprüften Commit zugeordnet.
• [ ] Für nicht automatisierte Abnahmen ist eine verantwortliche Person benannt.

Schlägt der Build schon vor jeder Änderung wechselnd oder aus unbekanntem Grund fehl, verkleinern Sie den Versuch. Sonst riskieren Sie, ein Umgebungsproblem später als Fehler des Agenten oder umgekehrt als Erfolg der Modernisierung zu interpretieren.

Verborgene Geschäftsregeln vor dem Eingriff sichtbar machen

In gewachsenen Systemen steckt Fachlogik nicht immer in einer eindeutig benannten Funktion. Sie kann sich aus Datumsgrenzen, Rundung, Reihenfolgen, Standardwerten, historischen Ausnahmen oder dem Zusammenspiel mit einem Fremdsystem ergeben. Ein Agent kann den Code erklären und mögliche Zusammenhänge herausarbeiten, aber er kann nicht allein entscheiden, welche davon verbindliche Geschäftsregeln sind.

Gehen Sie daher vor der Codeänderung die relevanten Pfade mit einer fachkundigen Person durch. Fragen Sie nach Eingaben, die im Normalbetrieb selten vorkommen, nach zulässigen und unzulässigen Werten sowie nach Situationen, in denen ein System einen Vorgang bewusst nicht ausführt. Prüfen Sie außerdem, welche externen Systeme Daten liefern oder entgegennehmen und welche Nebenwirkungen ein Aufruf auslöst. Dazu können beispielsweise Schreibzugriffe, Benachrichtigungen oder nachgelagerte Abrechnungsprozesse gehören – sofern sie in Ihrem System tatsächlich vorhanden sind.

Die Erläuterung zu „Legacy Seams“ beschreibt, wie sich in bestehendem Code Ansatzpunkte für kontrollierte Änderungen finden lassen. Entscheidend ist nicht, ein Muster mechanisch anzuwenden, sondern eine Grenze zu identifizieren, an der sich Verhalten beobachten und eine Änderung isolieren lässt. Wenn ein kritischer Pfad über mehrere Komponenten hinweg untrennbar wirkt, nehmen Sie ihn nicht als ersten Pilot.

Formulieren Sie für jede wichtige Annahme eine prüfbare Frage: Welche Eingabe löst den Pfad aus? Welches Ergebnis ist fachlich erwartet? Welche Daten dürfen sich ändern? Wer kann diese Aussage bestätigen? So wird aus der Analyse des Claude Code eine Liste offener Punkte, die Sie gezielt verifizieren können. Verwenden Sie die Erklärungen des Agenten nicht als Ersatz für die Person, die den fachlichen Ablauf verantwortet.

Die Zielumgebung von der Agentenleistung trennen

Ein Modernisierungsschritt kann scheitern, weil die Zielumgebung nicht zur Arbeitsumgebung passt. Prüfen Sie, ob Betriebssystem und Laufzeit, Compiler oder SDK, Paketquellen, Build-Skripte und erforderliche Umgebungsvariablen mit dem Zielsystem übereinstimmen. Dokumentieren Sie auch externe Voraussetzungen, etwa einen nicht verfügbaren Dienst oder einen Zugang, der in einer isolierten Testumgebung absichtlich fehlt.

Claude Code benötigt seinerseits eine unterstützte Umgebung. Die offizielle Anleitung zu Installation und Systemanforderungen ist dafür der passende Bezugspunkt. Halten Sie Agentenvoraussetzungen und Projektvoraussetzungen getrennt: Ist der Agent nicht korrekt gestartet, ist das ein anderes Problem als ein fehlgeschlagener Projektbuild. Diese Trennung verhindert, dass Sie Modellverhalten anhand einer unvollständigen oder falsch eingerichteten Umgebung beurteilen.

Bei Projekten mit macOS-spezifischen Build-, Test- oder Signierungsschritten sollten Sie zusätzlich prüfen, ob Ihr bestehender Arbeitsplatz oder Ihre CI diese Aufgaben tatsächlich abbildet. Eine entfernte Mac-Umgebung kann dann eine geeignete Testoption sein, ist aber kein allgemeiner Ersatz für einen reproduzierbaren Build. Wenn Sie eine solche Option erwägen, vergleichen Sie erst die Anforderungen an Zugriff, Datenverarbeitung und Dauer des Versuchs; beziehen Sie Ihre internen Datenschutzvorgaben und die geltenden Anforderungen der DSGVO in die Prüfung der Datenflüsse ein.

Abgrenzung: Ein macOS-spezifischer Prüfschritt rechtfertigt eine Mac-Umgebung. Er ist kein Grund, eine ansonsten plattformunabhängige Migration pauschal auf einem Mac auszuführen.

FAQ: Vom Veranstaltungsbeispiel zum Repository-Pilot

Lässt sich die Modernisierungsdemo direkt auf ein echtes Repository übertragen?

Nein. Die angekündigten Beispiele zeigen, welche Aufgaben in der Veranstaltung demonstriert werden sollen, nicht, dass Ihr Repository dieselben Abhängigkeiten, Eingabevarianten oder Geschäftsregeln besitzt. Übertragen Sie zuerst nur eine abgegrenzte Änderung auf eine isolierte Arbeitskopie. Vergleichen Sie das Ergebnis mit einem reproduzierbaren Build und fachlich bestätigtem Verhalten, bevor Sie den Umfang vergrößern.

Wie wählen Sie nach der Veranstaltung ein geeignetes Pilot-Repository?

Nehmen Sie ein Repository, dessen Zuständigkeit geklärt ist und dessen Build sich reproduzieren lässt. Der erste Versuch sollte eine begrenzte, überprüfbare Änderung betreffen, nicht den kritischsten Ablauf oder eine breite Architekturumschreibung. Benennen Sie eine fachlich verantwortliche und eine technisch prüfende Person. Fehlen diese Rollen oder eine sichere Rücksetzung, wählen Sie ein kleineres Modul.

Was tun Sie, wenn im Altsystem ausreichende Tests fehlen?

Ersetzen Sie fehlende Tests nicht durch Vertrauen in eine plausible Erklärung des Agenten. Sammeln Sie bekannte Eingaben und erwartete Ergebnisse, einschließlich fachlicher Grenzfälle, und lassen Sie sie bestätigen. Wo eine Automatisierung nicht möglich ist, dokumentieren Sie manuelle Abnahmeschritte samt Belegen. Bleibt ein kritischer Ablauf unprüfbar, beschränken Sie den Pilot auf eine risikoärmere Stelle.

Woran lässt sich die Zuverlässigkeit des Modernisierungsergebnisses erkennen?

Verlangen Sie getrennte Belege für Build, Tests und fachliche Abnahme; ein erfolgreicher Patch oder eine schlüssige Erläuterung reicht nicht. Prüfen Sie außerdem Zielversion, Build-Skript, Abhängigkeiten und Rücksetzbarkeit. Zuverlässigkeit bedeutet hier, dass Ihre vorher festgelegten Kriterien überprüft wurden. Ein einzelner erfolgreicher Demo-Lauf ist kein allgemeines Versprechen für andere Repositories.

Einen Pilot mit klarer Grenze und Abbruchbedingung festlegen

Ein KI-Coding-Agent-Pilot sollte eine Annahme prüfen, keine unbestimmte Modernisierung starten. Schreiben Sie vor dem Eingriff auf, welcher kleine Bereich geändert werden darf, welche Verzeichnisse und Schnittstellen außerhalb des Umfangs liegen und wer eine Ausnahme genehmigt. Legen Sie außerdem fest, wie Sie den Arbeitsstand zurücksetzen, falls Build, Tests oder fachliche Prüfung fehlschlagen.

Nutzen Sie die folgenden Bedingungen als Entscheidungshilfe. Sie sollen Ihnen helfen, einen größeren Schritt zu vermeiden, solange zentrale Voraussetzungen fehlen:

• Wenn Build und betroffene Tests vorab reproduzierbar sind, dann können Sie einen klar abgegrenzten Pilot in einer separaten Arbeitskopie beginnen. Andernfalls stabilisieren Sie zuerst den Build oder verkleinern den Umfang auf einen unabhängig prüfbaren Teil.
• Wenn die betroffenen Geschäftsregeln und Grenzfälle von einer verantwortlichen Person bestätigt wurden, dann können Sie Agentenvorschläge gegen diese Regeln prüfen. Andernfalls lassen Sie den Agenten zunächst Fragen und mögliche Pfade sammeln, ohne Änderungen in den gemeinsamen Entwicklungszweig zu übernehmen.
• Wenn die Testumgebung den tatsächlichen Zielplattformen und Abhängigkeiten entspricht, dann lassen sich Fehler besser der Änderung zuordnen. Andernfalls gleichen Sie die Umgebung ab, bevor Sie Aussagen über die Leistungsfähigkeit des Werkzeugs treffen.
• Wenn Sie Änderung, Prüfergebnisse und Rücksetzung nachvollziehbar festhalten, dann kann das Team den Versuch auswerten. Andernfalls stoppen Sie vor einer Ausweitung und richten erst den Nachweisweg ein.
• Wenn fachliche Abnahme, technische Prüfung und Rücksetzweg geklärt sind, dann können Sie die nächste Änderung anhand derselben Kriterien entscheiden. Andernfalls bleibt der Versuch ein lokales Experiment und wird nicht als freigegebene Migration behandelt.

Ein sinnvoller Stopp ist kein gescheiterter Versuch. Er zeigt, dass eine Voraussetzung fehlt, bevor eine Änderung in einen größeren Bereich gelangt. Halten Sie fest, ob die Ursache ein unklarer Geschäftsablauf, ein Build-Problem, ein fehlender Test oder eine unpassende Umgebung war. So unterscheiden Sie das Risiko Ihres Systems von der Frage, ob sich der gewählte Agent für einen besser vorbereiteten Teil eignet.

Den Erfolg über Belege statt über erzeugten Code beurteilen

Bewerten Sie den Versuch nicht danach, wie viel Code erzeugt oder verändert wurde. Beurteilen Sie, ob das Ergebnis im vereinbarten Umfang liegt, ob sich der Build reproduzieren lässt, ob die relevanten automatisierten und manuellen Prüfungen bestanden wurden und ob die verantwortliche Person das erwartete Verhalten bestätigt hat. Ein Diff, der kompiliert, kann fachlich falsch sein; eine ausführliche Begründung ersetzt weder den Test noch die Abnahme.

Für wiederholbare Arbeitsabläufe können Sie die Hinweise zu Prompt-Vorlagen und Variablen als Ausgangspunkt für klar formulierte Anweisungen verwenden. Schreiben Sie darin den erlaubten Änderungsbereich, vorhandene Tests, bekannte Einschränkungen und gewünschte Belege ausdrücklich auf. Wenn eine Anweisung unklar ist, bitten Sie um eine Zusammenfassung der Annahmen, bevor Sie eine Änderung freigeben. So bleibt nachvollziehbar, was das Werkzeug wusste und welche Informationen Ihr Team ergänzt hat.

Wenn die Migration mehrere unabhängig betreibbare Komponenten berührt, kann ein schrittweises Vorgehen risikoärmer sein als ein umfassender Austausch. Das Strangler-Fig-Muster in der Microsoft-Architekturdokumentation beschreibt ein solches Ablösen über klarere Grenzen. Ob das für Ihr System passt, hängt davon ab, ob Sie tatsächlich eine geeignete Schnittstelle und einen kontrollierbaren Übergang haben; die Bezeichnung des Musters allein schafft diese Voraussetzungen nicht.

Achten Sie zusätzlich auf Datenschutz und Zugriff. Eine isolierte Arbeitskopie kann versehentlich vertrauliche Daten, Schlüssel oder Zugangsdaten enthalten. Entfernen oder schützen Sie solche Informationen, bevor Sie Code oder Protokolle in eine Umgebung übertragen, deren Datenverarbeitung Ihr Team noch nicht bewertet hat. Prüfen Sie, wer Zugriff auf Repository, Build-Ausgaben und temporäre Dateien hat und wann diese Daten entfernt werden. Gerade bei älteren Systemen können Testdaten produktionsnah sein, obwohl der Versuch selbst als unkritisch geplant wurde.

Für den ersten Versuch genügt ein belastbarer Befund zu einem kleinen, klar umrissenen Bereich. Wenn dieser Befund positiv ausfällt, kann das Team die nächste Änderung mit denselben Prüfkriterien planen. Wenn er negativ ist, haben Sie früh erfahren, welche Voraussetzung fehlt, ohne den Fehler durch eine breite Änderung schwerer lokalisierbar zu machen.

Der Wechsel von einer vorhandenen CI-Umgebung auf einen Mac ist nur dann sinnvoll, wenn Ihr tatsächlicher Build macOS voraussetzt. Eine bestehende Linux-Umgebung kann für plattformunabhängige Prüfungen stabiler und näher an Ihrem Betrieb sein; sie bildet jedoch macOS-spezifische Builds oder Signierung nicht automatisch ab. Eine Mac-Mietumgebung kann für einen zeitlich begrenzten Vergleich näher am Ziel liegen, bringt aber Fernzugriff, Datenzugriff, Sitzungsverwaltung und zusätzliche Abstimmung mit sich. Wenn Ihr Pilot genau solche Schritte benötigt, prüfen Sie die Bedingungen für einen Mac mini bei ZavCloud erst nach der fachlichen und technischen Eingrenzung. Bei offenen Fragen zu Zugriff und Ablauf können Sie vorab das Hilfezentrum von ZavCloud heranziehen. Für einen dauerhaften, stark ausgelasteten Build-Betrieb oder notwendige lokale Schnittstellen kann eine eigene, stabil betriebene Umgebung geeigneter sein. Als nächstes sollten Sie den Migrationstest auf einen rücksetzbaren Bereich zuschneiden und die Umgebung nur passend zu den nachgewiesenen Build-Anforderungen auswählen.