Partnerschaften
IBM und Kaggle arbeiten gemeinsam an einer kontinuierlich aktualisierten ScarfBench-Migrationsrangliste
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen
IBM und Kaggle arbeiten an einer kontinuierlich aktualisierten öffentlichen Rangliste für ScarfBench, IBMs offenem Benchmark zur Bewertung von Coding-Agenten bei Migrationen von Enterprise-Java-Frameworks. Das geht aus einer am 27. Oktober 2026 veröffentlichten technischen Notiz von IBM Research hervor.
ScarfBench steht für Self-Contained Application Refactoring Benchmark und prüft, ob ein Agent eine ihm unbekannte Enterprise-Java-Anwendung übernehmen, zwischen den Frameworks Jakarta EE, Quarkus und Spring migrieren und dabei funktionsfähige Software hinterlassen kann. Der Benchmark überprüft anhand sowohl gezielter Workloads als auch vollständiger Anwendungen, ob die generierten Anwendungen erstellt und gestartet werden können und sich weiterhin wie erwartet verhalten. IBM stellte ScarfBench Anfang 2026 als reproduzierbaren Benchmark für KI-gestützte Migrationen vor. Die ursprüngliche Ankündigung vom 11. März 2026 beschrieb sieben Komponenten: von Entwicklern überprüfte Enterprise-Anwendungen für die drei Frameworks, gezielte Workloads zur isolierten Untersuchung von Aspekten wie dem Verhalten der Persistenz und der Dependency Injection, vollständige Anwendungen, die mehrere Architekturebenen verbinden, eine automatisierte Überprüfung von Build und Start sowie Verhaltenstests zur Überprüfung des Laufzeitverhaltens und der funktionalen Gleichwertigkeit. Jeder Workload wurde laut der Ankündigung von erfahrenen Entwicklern manuell implementiert und im Hinblick auf funktionale Gleichwertigkeit und idiomatische Verwendung des Frameworks überprüft.
Die Zusammenarbeit zwischen IBM und Kaggle
Im Rahmen der Partnerschaft beriet Kaggle IBM bei der Konzeption des Benchmarks und der Evaluierung, reproduzierte ScarfBench unabhängig auf der eigenen Plattform und führte ihn dort aus, wobei Kaggle die Rechenleistung finanzierte. Außerdem wird Kaggle den Benchmark langfristig betreuen. IBM bezeichnete die Stärken der Teams als einander ergänzend: IBM entwickelte ScarfBench mit Blick auf die Modernisierung von Enterprise-Java-Anwendungen, während Kaggle eine unabhängige Evaluierungsinfrastruktur und die laufende Pflege der Rangliste beisteuert.
Ergebnisse für 204 Migrationsaufgaben
ScarfBench bewertet ein agentenbasiertes System und nicht ein Sprachmodell für sich allein: Jedes Ergebnis bezieht sich auf ein Modell in Verbindung mit einem Coding-Agent-Harness, das festlegt, wie das Modell mit dem Repository und der Entwicklungsumgebung interagiert. IBM wies darauf hin, dass die Ergebnisse als Resultate der jeweiligen Modell-Harness-Kombination und nicht als Messwerte für das zugrunde liegende Modell allein zu verstehen sind.
Bei 204 Migrationsaufgaben und zehn bewerteten Modell-Harness-Konfigurationen belegte Gemini 4 Argon mit dem Antigravity-Harness laut IBM mit 75,2 % den ersten Platz bei der primären Smoke-Test-Kennzahl. Dahinter folgten Claude Opus 5.5 mit Claude Code mit 70,5 % und Claude Opus 5 mit Claude Code mit 69,8 %. Der Smoke-Test-Wert, der als Kennzahl für die Rangliste dient, vergibt Teilpunkte und gewichtet größere Testsuiten stärker. Bei der strengeren Kennzahl, die nur zählt, wenn alle Tests bestanden werden, erzielte Claude Opus 5.5 mit Claude Code mit 72,1 % die höchste Quote und lag damit knapp vor Gemini 4 Argon mit Antigravity mit 71,1 %.
Laut dem Beitrag blieb die Rangfolge an der Spitze auch bei einer Sensitivitätsanalyse bestehen. Vier der 204 Aufgaben erhielten von keiner Konfiguration Punkte für Verhaltenstests. Ohne diese Aufgaben stiegen die absoluten Werte, die führenden Modelle änderten sich jedoch nicht: Gemini 4 Argon mit Antigravity erzielte 79,4 %, gefolgt von Claude Opus 5.5 mit Claude Code mit 74,5 % und Claude Opus 5 mit Claude Code mit 73,7 %. Selbst die stärkste Kombination hatte laut IBM noch deutliches Verbesserungspotenzial: Keine Konfiguration bestand alle Tests bei mehr als etwa drei Vierteln der Migrationen.
Wo die Konfigurationen erfolgreich sind und wo sie scheitern
Die größte Lücke in der Evaluierung bestand laut IBM zwischen Code, der sich erstellen lässt, und Software, die sich korrekt verhält. Nach dem Ausschluss der vier Aufgaben, bei denen alle Konfigurationen null Punkte erhielten, konnten Claude Opus 5 mit Claude Code, Gemini 4 Argon mit Antigravity und Gemini 3.8 Flash mit mini-swe jeweils 100 % der Aufgaben kompilieren. Acht der zehn Konfigurationen erreichten eine Kompilierungsquote von mindestens 97 %. Die Smoke-Test-Ergebnisse hingegen unterschieden sich um mehr als 50 Punkte. Bei den erfolgreich bereitgestellten Anwendungen lagen die führenden Konfigurationen bei etwa 63 % bis 76 % vollständig bestandener Tests. Kimi K3 mit kimi-code erreichte dagegen nur 53 %, Gemini 3.1 Pro mit OpenHands 42 % und Gemma 4 26B-A4B mit mini-swe 26 %.
IBM ordnete 745 fehlgeschlagene Durchläufe ein: 535 davon, rund 72 %, waren Laufzeitfehler bei Verhaltenstests. Dabei ließ sich die Anwendung erstellen und oft auch starten, bestand aber die Verhaltensprüfung nicht. Zu dieser Gruppe gehörten 304 Fehler aufgrund nicht übereinstimmender Inhalte oder Assertions, 210 Fehler wegen verlorener Routen oder 404-Fehler sowie 21 explizite HTTP-500- oder HTTP-405-Fehler. Fehler beim Kompilieren oder Verpacken machten rund 20 % der fehlgeschlagenen Durchläufe aus, insgesamt 152. Auf Abstürze beim Start oder bei der Dependency Injection entfielen rund 8 %, insgesamt 58.
Der Beitrag führt Beispiele auf Aufgabenebene an. Bei concurrency-taskcreator-quarkus-to-jakarta erzielte Claude Opus 5 mit Claude Code 0/6 Punkte, nachdem der Endpunkt /taskinfo „File not found“ zurückgegeben hatte und ein Test, der HTTP 405 erwartete, fehlgeschlagen war. Bei address-book-jakarta-to-quarkus erreichte GPT-6 Astra mit Codex 2/10 Punkte, nachdem Listen- und Erstellungsseiten HTTP 404 zurückgegeben hatten. Bei cargotracker-jakarta-to-spring behielt Gemini 3.8 Flash mit mini-swe im Spring-Boot-Zielprojekt die JSF-/JoinFaces-Konfiguration bei und scheiterte beim Start, als eine facesContext-Bean erstellt wurde. Bei cart-spring-to-jakarta kam es mit GPT-6 Astra und Codex zu einem Bereitstellungsfehler, weil der bei der Migration zurückgelassene Verpackungstyp von der Liberty-Laufzeitumgebung des Zielsystems nicht unterstützt wurde.
IBM berichtete außerdem, dass die Effizienz je nach Konfiguration variierte. Bei den 200 Aufgaben, die nach dem Ausschluss im Rahmen der Sensitivitätsanalyse verblieben, lag die mediane Zahl der Interaktionsrunden zwischen 32 bei Claude Opus 5 mit Claude Code und 79 bei Gemini 3.8 Flash mit mini-swe; Claude Opus 5.5 mit Claude Code kam auf 64. In den Konfigurationen mit Claude Code, Codex, mini-swe und kimi-code, für die die Testumgebungen Kosten meldeten, lagen die Kosten pro gelöster Aufgabe zwischen 1,25 $ bei GPT-6.1 Sol mit Codex und 10,10 $ bei Claude Opus 5.5 mit Claude Code. Die Testumgebungen Antigravity, qwen-code und OpenHands gaben keine Kosten pro Durchlauf aus.
Die ScarfBench-Bestenliste bietet einen öffentlichen Überblick über diese Ergebnisse. Zum Start ist die öffentliche Einreichung von Modellen nicht möglich; IBM zufolge steht sie jedoch auf der Roadmap.
