Maya Bennett
IBM Research hat ScarfBench vorgestellt, einen offenen Benchmark zur Bewertung, wie gut KI-Agenten mit der Migration von Enterprise-Java-Frameworks umgehen. Der Benchmark zeigt, dass Konfiguration und Laufzeitabhängigkeiten die größten Hindernisse sind, nicht die Code-Übersetzung.
Jüngste Fortschritte bei Coding-Agenten haben Begeisterung für KI-gestützte Modernisierung ausgelöst. Aber eine wichtige Frage bleibt: Können KI-Agenten zuverlässig reale Unternehmensanwendungen modernisieren?
Bestehende Softwareentwicklungs-Benchmarks haben beeindruckende Fortschritte bei der Fehlerbehebung und Codegenerierung gezeigt, aber Framework-Migration stellt eine grundlegend andere Herausforderung dar. Erfolg erfordert nicht nur das Übersetzen von Code, sondern auch das Bewahren des Verhaltens, das Anpassen von Build-Systemen und das Navigieren durch Laufzeitabhängigkeiten.
Um diese Lücke zu schließen, hat IBM Research ScarfBench (Self-Contained Application Refactoring Benchmark) entwickelt, einen offenen Benchmark zur Bewertung von KI-Agenten bei Framework-übergreifenden Migrationsaufgaben in Enterprise Java. ScarfBench konzentriert sich auf Migrationen zwischen drei großen Java-Ökosystemen: Spring, Jakarta EE und Quarkus.
Im Gegensatz zu traditionellen Benchmarks, die generierten Code mit Referenzimplementierungen vergleichen, bewertet ScarfBench, ob migrierte Anwendungen tatsächlich bauen, bereitgestellt werden und das Verhalten bewahren.
Warum Migration schwierig ist
Framework-Migration ist viel mehr als das Ersetzen von Annotationen. Eine einfache Repository-Migration kann Änderungen an Dependency Injection, Persistenzkonfiguration, Abfragen und Framework-Deskriptoren erfordern. Kleine Fehler in einem dieser Teile können eine erfolgreiche Bereitstellung verhindern.
Abbildung: Spring → Jakarta-Migrationsbeispiel
Framework-Migration erfordert das Übersetzen von Framework-Semantiken, nicht nur von Quellcode.
Einführung in ScarfBench
ScarfBench bietet eine systematische Möglichkeit, KI-Agenten bei Enterprise-Java-Framework-Migrationsaufgaben zu bewerten. Anwendungen müssen erfolgreich bauen, korrekt bereitgestellt werden und Verhaltenstests bestehen. Dies liefert ein viel realistischeres Maß für die Modernisierungsqualität.
Der Benchmark umfasst sowohl fokussierte Migrationsaufgaben als auch Ganzanwendungs-Migrationen.
Abbildung: ScarfBench-Konstruktionspipeline
Ausgehend von einer JSR-basierten Enterprise-Java-Taxonomie erstellen Expertenmigrationen verifizierte Implementierungen über Spring, Jakarta EE und Quarkus hinweg.
Wie schlagen sich führende Agenten?
IBM Research hat mehrere hochmoderne Coding-Agenten auf ScarfBench evaluiert. Trotz starker Leistung bei traditionellen Softwareentwicklungs-Benchmarks bleibt Framework-Migration schwierig. Die Erfolgsraten variieren erheblich zwischen Framework-Paaren, und Ganzanwendungs-Migrationen bleiben besonders herausfordernd.
Abbildung: Aktuelle Bestenliste
Abbildung: Compile → Deploy → Test-Fortschritt
Der Kompilierungserfolg übersteigt durchweg den Bereitstellungserfolg, der wiederum den Verhaltenserfolg übersteigt. Der Build-Erfolg allein überschätzt die Migrationsqualität erheblich.
Abbildung: Migrationsergebnisse nach Zielframework
Die Migrationsschwierigkeit hängt stark vom Zielframework ab, wobei Jakarta EE besonders herausfordernd ist.
Was wir über KI-Agenten für die Java-Modernisierung gelernt haben
Über die Messung von Erfolgsraten hinaus hilft ScarfBench zu verstehen, wie sich Agenten während der Modernisierung verhalten.
Können Agenten zuverlässig sagen, wann eine Migration abgeschlossen ist?
Eine migrierte Anwendung ist nur nützlich, wenn sie tatsächlich baut und läuft. IBM Research verglich von Agenten gemeldete Ergebnisse mit unabhängiger Build-Verifikation.
„Claude Code meldete erfolgreiche Builds für 29 von 30 gesamten Anwendungen. Nur 22 dieser Anwendungen bauten tatsächlich erfolgreich. Gleichzeitig baute die einzige vom Agenten als fehlgeschlagen eingestufte Anwendung letztendlich korrekt.“
— IBM Research
Dies deutet darauf hin, dass die Selbsteinschätzung von Agenten nicht als zuverlässiges Signal für den Abschluss der Migration behandelt werden sollte. Unabhängige Build- und Testvalidierung bleibt unerlässlich.
Wie navigieren Agenten durch Anwendungsabhängigkeiten?
Framework-Migrationen betreffen selten eine einzelne Datei oder Schicht. Änderungen in Konfiguration, Diensten, Datenbanken und Webkomponenten wirken sich oft kaskadenartig auf die gesamte Anwendung aus.
Die am häufigsten besuchten Schichten waren Konfiguration, Web, Datenbank und Dienst. Häufige Übergänge umfassten Konfiguration ↔ Web und Dienst ↔ Datenbank. Dies deutet darauf hin, dass Migration ein iterativer Abhängigkeitsauflösungsprozess ist und keine einfache Quell-zu-Quell-Transformation.
Wo investieren Agenten die meiste Mühe?
Unter Verwendung der Häufigkeit von Schichtbesuchen als Proxy für den Migrationsaufwand fanden Forscher heraus, dass die Konfiguration den Migrationsaufwand dominiert. Anstatt linear vorzugehen, kehrten Agenten wiederholt zu konfigurationsbezogenen Artefakten zurück, während sie Framework-Unterschiede und Abhängigkeitsprobleme lösten.
Welche Herausforderungen betreffen nicht die Code-Transformation?
Nicht jedes Migrationsproblem hat seinen Ursprung im Quellcode. Agenten kämpften häufig mit Umgebungsproblemen, darunter Docker-Cache-Inkonsistenzen, Port-Konnektivitätsproblemen sowie Maven-Wrapper- und Build-Tooling-Problemen. Diese betrieblichen Probleme verzögerten oft die Validierung, selbst wenn die Quellcode-Migration selbst weitgehend abgeschlossen war.
Abbildung: Verteilung der Fehlermodi
Modernisierungsfehler erstrecken sich über Build-Systeme, Bereitstellungsumgebungen, Dependency Injection, Datenbanken, Endpunkte, Assertions und Infrastruktur.
Wichtigste Erkenntnis
Die größte Herausforderung bei der Framework-Modernisierung ist nicht die Übersetzung von Java-Code. Es ist das Management des Netzes von Abhängigkeiten über Konfiguration, Infrastruktur und Laufzeitumgebungen hinweg. Während führende Agenten wesentliche Teile des Migrationsprozesses automatisieren können, bleiben zuverlässige Validierung und architektonisches Denken entscheidend für erfolgreiche Ergebnisse.
ScarfBench hilft, diese Herausforderungen aufzuzeigen und bietet eine standardisierte Möglichkeit, Fortschritte in Richtung wirklich autonomer Anwendungsmodernisierung zu messen.
ScarfBench erkunden
ScarfBench ist als offene Ressource für Forscher und Praktiker konzipiert. Zu den Ressourcen gehören ein Benchmark-Datensatz, Evaluierungsinfrastruktur, öffentliche Bestenliste, Dokumentation und Open-Source-Code. Forscher können Agentenarchitekturen und -techniken vergleichen. Praktiker können ScarfBench nutzen, um Modernisierungslösungen zu evaluieren, bevor sie sie in Produktionsumgebungen einsetzen.
- Website: https://scarfbench.info
- Datensatz: https://huggingface.co/datasets/ibm-research/ScarfBench
- Space: https://huggingface.co/spaces/ibm-research/ScarfBench
- GitHub-Repository: https://github.com/scarfbench/scarfbench
- Bestenliste: https://scarfbench.info/leaderboard
- Paper: https://arxiv.org/abs/2605.06754
Framework-Migration bleibt eines der größten ungelösten Probleme in der KI-gestützten Softwareentwicklung. IBM Research hofft, dass ScarfBench der Gemeinschaft hilft, Fortschritte zu messen und die nächste Generation KI-gestützter Anwendungsmodernisierung zu beschleunigen. Das Team lädt Forscher, Praktiker und Framework-Autoren ein, beizutragen und die Grenzen dessen zu erweitern, was KI-Agenten in der Unternehmenssoftware-Modernisierung erreichen können.
