Analyse-, Transformations- und KI-Werkzeuge

Analyse-, Transformations- und KI-Werkzeuge

0:00 Zum Abschluss des Seminars sprechen wir über Werkzeuge — und darüber, was sie leisten und was nicht. Der Leitsatz lautet: Werkzeuge nehmen die Fleißarbeit ab, die Verantwortung für das Ergebnis nehmen sie nicht mit. Das gilt für statische Analyse, für automatische Transformation und ganz besonders für KI-gestützte Assistenten.

0:19 Wir sehen uns an, wie eine Migrationsanalyse arbeitet, wie Rezepte Code umbauen, und wir schauen uns Zahlen an, die zeigen, wo autonome Migration heute tatsächlich steht. Diese Zahlen sind ernüchternd — und sie sind ein guter Grund, die Tests aus Modul dreizehn ernst zu nehmen.

Analyse-, Transformations- und KI-Werkzeuge

0:35 Das letzte Modul schließt den Kreis zu Modul zwei. Dort haben wir von Hand inventarisiert und dabei festgestellt, dass eine Suche von Hand nur findet, was man kennt. Jetzt sehen wir uns an, welche Werkzeuge diese Lücke schließen — und an welcher Stelle sie ihrerseits an Grenzen stoßen. Am Ende steht eine Übung, die Werkzeugergebnisse gegen Ihre eigenen Tests prüft.

Analyse und Transformation

0:57 Beginnen wir mit der Analyse. Die Reihenfolge ist dabei kein Zufall: erst prüfen lassen, dann ändern lassen. Die Reihenfolge ist dabei kein Zufall: erst prüfen lassen, dann ändern lassen. Ein Werkzeug, das ändert, bevor jemand die Lage kennt, macht die Sache nicht besser. Das Migration Toolkit for Applications analysiert eine bestehende Anwendung gegen gepflegte Regeln und bewertet sie für einen Zielpfad.

1:23 Es gibt drei Zugänge: ein Kommandozeilenwerkzeug für die Pipeline, eine Weboberfläche für die Übersicht über viele Anwendungen, und Erweiterungen für Visual Studio Code und IntelliJ IDEA, die Befunde direkt im Editor zeigen. Und eigene Regeln lassen sich ergänzen — das ist wichtiger, als es klingt, denn jede gewachsene Anwendung hat Eigenheiten, die in keiner allgemeinen Regelsammlung stehen können.

1:45 Die Logik dieser Tabelle ist eine Zuordnung von Ausgangslage zu möglichen Zielen — und sie enthält eine wichtige Einschränkung. Quarkus ist als Ziel für JBoss EAP 5 und 6 sowie für Spring Boot dokumentiert; für WebLogic und WebSphere führt die Tabelle andere Ziele: JBoss EAP, Open Liberty, aktuelle OpenJDK-Versionen und Cloud-Readiness.

2:05 Das heißt nicht, dass eine Migration von WebSphere nach Quarkus unmöglich wäre — es heißt, dass Sie dafür weniger Werkzeugunterstützung bekommen und mehr selbst prüfen müssen. Gut zu wissen, bevor man die Analyse als Aufwandsschätzung liest. Der erste Punkt ist die Kernaussage: Ein Werkzeug kennt Regeln für Serverfunktionen, die im Code völlig unauffällig aussehen.

2:27 Ein Aufruf einer herstellerspezifischen Klasse sieht aus wie jeder andere Methodenaufruf — nur eine Regelsammlung weiß, dass es ihn woanders nicht gibt. Punkt drei ist der Grund, warum sich der Aufwand über die Zeit auszahlt: Derselbe Maßstab bei jedem Lauf zeigt Fortschritt. Und Punkt vier ist die Antwort auf den häufigsten Einwand, dass generische Werkzeuge die eigene Anwendung nicht kennen: Eigene Regeln lassen sich ergänzen — genau für die Eigenheiten aus Modul zwei.

2:54 Punkt eins ist der folgenreichste: Das Ergebnis wird als Aufwandsschätzung gelesen statt als Fundliste. Ein Analysebericht sagt, was gefunden wurde — er weiß nichts über Ihr Team, Ihre Testabdeckung und Ihre fachlichen Zusammenhänge. Punkt zwei ist der Nutzungsfehler: Der Lauf findet einmal statt und wird nie wiederholt, obwohl gerade die Wiederholung den Wert ausmacht.

3:16 Und Punkt vier ist der organisatorische, der jedem Analyseprojekt droht: Der Bericht wandert ins Ablagesystem, ohne Arbeit auszulösen. Ein Befund, aus dem keine Aufgabe wird, ist kein Befund, sondern Papier.

Automatische Änderungen

3:29 Kommen wir zur Transformation. Werkzeuge können Code nicht nur lesen, sondern auch ändern — und das erstaunlich zuverlässig. Werkzeuge können Code nicht nur lesen, sondern auch ändern — erstaunlich zuverlässig, aber niemals vollständig. OpenRewrite wendet Rezepte auf den Quelltext an, etwa für den Wechsel des Namensraums aus Modul drei oder für Versionssprünge.

3:51 Für Quarkus-Projekte fasst der Aktualisierungsbefehl solche Rezepte zusammen. Zwei Angaben sind wichtig: Er verlangt mindestens Quarkus 2.13, und er automatisiert ausdrücklich nur einen Teil der Migration. Diese Ehrlichkeit in der Dokumentation ist bemerkenswert und sollte ernst genommen werden — sie ist die Aufforderung, die Migration Guides zu lesen, statt sich auf einen grünen Werkzeuglauf zu verlassen.

4:15 Drei Zeilen, und wie schon in Modul drei kommt es auf die letzten beiden an. Der Aktualisierungsbefehl macht die Arbeit; der Diff und der Testlauf machen die Aussage. Und die Fußzeile enthält den Rat, der am häufigsten ignoriert wird: Die Migration Guides des Zielstands gehören trotzdem gelesen. Dort stehen die Verhaltensänderungen, die kein Rezept erkennen kann — eine geänderte Voreinstellung, ein anderes Standardverhalten bei Fehlern.

4:41 Der Werkzeuglauf ändert Code; die Guides erklären, was sich sonst noch geändert hat. Beides zusammen ergibt eine Migration. Vier Lücken, und die letzte ist die grundsätzliche: Verhaltensänderungen erkennt kein Rezept, nur ein Test. Ein Rezept arbeitet auf der Struktur des Codes — es kann eine Methode umbenennen, aber es kann nicht wissen, dass die neue Methode bei leerer Eingabe etwas anderes zurückgibt.

5:04 Punkt drei ist der praktische Ärger: Generierter Code fällt beim nächsten Build wieder auf den alten Stand zurück, wenn Sie den Generator nicht mit umstellen. Und Punkt zwei kennen Sie aus Modul drei: Konfigurationsdateien mit eigenem Schema bleiben unangetastet. Punkt eins ist die Grundregel für jeden Werkzeuglauf: nur auf einem eingecheckten Stand starten.

5:24 Sonst können Sie hinterher nicht mehr unterscheiden, was das Werkzeug getan hat und was Sie selbst. Punkt zwei ist die Bequemlichkeit, die teuer wird: Änderungen werden übernommen, ohne den Diff zu lesen — bei tausend geänderten Dateien verständlich, aber dann sollten wenigstens die betroffenen Bereiche stichprobenartig geprüft werden.

5:42 Punkt drei ist der Planungsfehler: zwei Versionssprünge in einem Lauf. Und Punkt vier ist die übersprungene Lektüre der Migration Guides.

KI als Assistent, nicht als Automat

5:50 Und jetzt zum Thema, über das derzeit am meisten geredet wird — mit Zahlen statt mit Erwartungen. Und zwar mit Zahlen statt mit Erwartungen. Die Zahlen sind ernüchternd, und sie sind ein guter Grund für die Tests aus Modul dreizehn. KI-gestützte Werkzeuge lesen Code, erklären Zusammenhänge und schlagen Änderungen vor. Für eine Migration sind sie Assistenten — die Prüfung des Ergebnisses bleibt bei Menschen und bei automatisierten Tests.

6:16 Der letzte Satz ist wichtig und bewusst vorsichtig formuliert: Vollständige Migrationen ohne Aufsicht sind derzeit nicht belegbar. Das ist keine Ablehnung, sondern eine Einordnung — und sie ändert sich vermutlich. Was sich nicht ändert, ist die Notwendigkeit, das Ergebnis zu prüfen. Auch bei einem menschlichen Kollegen prüfen wir ja nicht, weil wir ihm misstrauen, sondern weil Code geprüft gehört.

6:39 Diese Zahlen stammen aus dem 2026 veröffentlichten Forschungsbenchmark ScarfBench zu Migrationen in Enterprise Java. Der stärkste untersuchte Agent erreichte eine aggregierte Testpassrate von 12,2 Prozent, und genau eine von 204 Aufgaben war vollständig verhaltensgleich. Zwei Einordnungen dazu: Erstens ist das ein Forschungsbenchmark, also nicht unmittelbar auf jedes reale Projekt übertragbar.

7:03 Zweitens sagen diese Zahlen nichts über KI als Assistenz — sie sagen etwas über autonome, vollständige Migration. Und für die ist die Botschaft eindeutig: Es braucht automatisierte Verhaltenstests und menschliche Architekturprüfung. Vier Einsatzfelder, und alle vier haben etwas gemeinsam: Das Ergebnis ist überprüfbar oder unkritisch.

7:24 Fremden Code erklären ist ausgesprochen wertvoll — bei einer zwanzig Jahre alten Anwendung, deren Autoren nicht mehr da sind, ist eine gute Erklärung viel wert, und wenn sie falsch ist, merken Sie es beim Nachlesen. Testfälle für unverstandenes Verhalten vorzuschlagen passt hervorragend zu Modul dreizehn: Der Vorschlag wird gegen den laufenden Bestand geprüft, das System selbst korrigiert ihn also.

7:47 Und Punkt vier ist unterschätzt: Entscheidungen und ihre Begründung zu dokumentieren. Der rote Faden: begrenzen, lesen, bauen, vergleichen, dokumentieren. Schritt eins ist der wirksamste — den Umfang begrenzen. Ein Vorschlag über fünf Dateien lässt sich prüfen, einer über fünfhundert nicht. Schritt vier ist der Verhaltensvergleich aus Modul dreizehn, und er ist hier nicht optional.

8:11 Und die Fußzeile enthält den Grundsatz, der dieses ganze Modul trägt: Die Prüfpunkte gelten unabhängig davon, wer die Änderung erzeugt hat. Ob Werkzeug, Assistent oder Kollege — Build, Test und Review sind dieselben. Das entspannt die Diskussion übrigens erheblich. Punkt eins ist der häufigste Trugschluss: Große Änderungen werden übernommen, weil der Build grün ist.

8:34 Ein grüner Build sagt, dass der Code übersetzt und die vorhandenen Tests bestanden wurden — bei dünner Testabdeckung ist das eine schwache Aussage. Punkt zwei ist konkret und passiert regelmäßig: Vorschläge erfinden Bibliotheksfunktionen, die es nicht gibt. Das fällt beim Übersetzen auf, kostet aber Zeit. Punkt drei ist der ausgelassene Vergleich, und Punkt vier ist die fehlende Dokumentation, die dazu führt, dass dieselbe Entscheidung in der nächsten Sitzung erneut geführt wird.

Übung

9:02 Die letzte Übung des Seminars. Sie setzen die Werkzeuge auf Zählwerk an — und Sie prüfen ihr Ergebnis gegen Ihre eigenen Tests. Sie setzen die Werkzeuge auf Zählwerk an — und prüfen ihr Ergebnis gegen Ihre eigenen Tests, nicht gegen ihr Versprechen. Sie lassen eine automatisierte Migrationsanalyse laufen und wenden ein Rezept auf ein Modul an.

9:23 Das Lernziel ist, solche Werkzeuge einzusetzen und ihre Ergebnisse gegen eigene Tests zu prüfen, statt ihnen zu vertrauen. Erfolgreich sind Sie, wenn die Befunde nach Aufwand und Risiko geordnet sind, ein Modul umgebaut ist und jede Stelle, an der Sie dem Werkzeug widersprochen haben, mit Begründung in einer Liste steht.

9:41 Grundlage sind die Characterization Tests aus Modul dreizehn — ohne sie ist kein Ergebnis prüfbar, und die Übung wäre eine Vertrauensfrage. Fünf Schritte, und Schritt zwei ist der, der aus Daten Arbeit macht: Befunde nach Aufwand und Risiko ordnen, statt sie zu zählen. Schritt drei begrenzt bewusst auf ein Modul. Und Schritt fünf ist der interessanteste: Widersprüche zum Werkzeug festhalten.

10:04 Wie die Fußzeile sagt, ist diese Liste die Erfahrung, die das Projekt in den nächsten Modulen trägt — sie zeigt nämlich, wo die Regeln zu Ihrer Anwendung nicht passen. Aus solchen Widersprüchen entstehen die eigenen Regeln, von denen auf Folie sechs die Rede war. Punkt eins ist der Auswertungsfehler: Befunde werden gezählt statt geordnet — dreihundert Befunde klingen dramatisch und sagen nichts.

10:27 Punkt zwei ist der Umfangsfehler: Das Rezept läuft über die ganze Anwendung, und der Diff ist nicht mehr prüfbar. Punkt drei ist die Bequemlichkeit, über die wir gesprochen haben. Und Punkt vier schließt das Seminar mit derselben Haltung, mit der es begonnen hat: Widersprüche werden korrigiert, aber nicht dokumentiert. Aufschreiben, warum entschieden wurde — das ist am Ende der Unterschied zwischen einer Migration, die trägt, und einer, die in einem Jahr neu diskutiert wird.