Maya Bennett
IBM Research wprowadził ScarfBench, otwarty benchmark zaprojektowany do oceny, jak dobrze agenci AI radzą sobie z migracją frameworków w aplikacjach korporacyjnych Java. Benchmark ujawnia, że największymi przeszkodami są konfiguracja i zależności środowiska wykonawczego, a nie tłumaczenie kodu.
Ostatnie postępy w agentach kodowania wzbudziły entuzjazm wokół modernizacji wspomaganej AI. Ale pozostaje ważne pytanie: Czy agenci AI mogą niezawodnie modernizować rzeczywiste aplikacje korporacyjne?
Istniejące benchmarki inżynierii oprogramowania wykazały imponujący postęp w naprawianiu błędów i generowaniu kodu, ale migracja frameworków stanowi zasadniczo inne wyzwanie. Sukces wymaga nie tylko tłumaczenia kodu, ale także zachowania zachowania, adaptacji systemów budowania i nawigacji po zależnościach środowiska wykonawczego.
Aby wypełnić tę lukę, IBM Research stworzył ScarfBench (Self-Contained Application Refactoring Benchmark), otwarty benchmark do oceny agentów AI w zadaniach migracji między frameworkami w Enterprise Java. ScarfBench koncentruje się na migracjach w trzech głównych ekosystemach Java: Spring, Jakarta EE i Quarkus.
W przeciwieństwie do tradycyjnych benchmarków, które porównują wygenerowany kod z implementacjami referencyjnymi, ScarfBench ocenia, czy zmigrowane aplikacje faktycznie się budują, wdrażają i zachowują swoje zachowanie.
Dlaczego migracja jest trudna
Migracja frameworków to znacznie więcej niż zastępowanie adnotacji. Prosta migracja repozytorium może wymagać zmian w iniekcji zależności, konfiguracji trwałości, zapytaniach i deskryptorach frameworków. Małe błędy w którymkolwiek z tych elementów mogą uniemożliwić pomyślne wdrożenie.
Rysunek: Przykład migracji Spring → Jakarta
Migracja frameworków wymaga tłumaczenia semantyki frameworków, a nie tylko kodu źródłowego.
Wprowadzenie do ScarfBench
ScarfBench zapewnia systematyczny sposób oceny agentów AI w zadaniach migracji frameworków w Enterprise Java. Aplikacje muszą pomyślnie się budować, poprawnie wdrażać i przechodzić walidację behawioralną. Zapewnia to znacznie bardziej realistyczną miarę jakości modernizacji.
Benchmark obejmuje zarówno skoncentrowane zadania migracji, jak i migracje całych aplikacji.
Rysunek: Potok budowy ScarfBench
Począwszy od taksonomii Enterprise Java opartej na JSR, eksperckie migracje tworzą zweryfikowane implementacje w Spring, Jakarta EE i Quarkus.
Jak radzą sobie czołowi agenci?
IBM Research ocenił kilka najnowocześniejszych agentów kodowania na ScarfBench. Pomimo silnych wyników w tradycyjnych benchmarkach inżynierii oprogramowania, migracja frameworków pozostaje trudna. Wskaźniki sukcesu znacznie się różnią w zależności od par frameworków, a migracje całych aplikacji pozostają szczególnie wymagające.
Rysunek: Aktualna tabela liderów
Rysunek: Postęp kompilacja → wdrożenie → test
Sukces kompilacji konsekwentnie przewyższa sukces wdrożenia, który z kolei przewyższa sukces behawioralny. Sam sukces budowania znacząco przeszacowuje jakość migracji.
Rysunek: Wyniki migracji według docelowego frameworka
Trudność migracji silnie zależy od docelowego frameworka, przy czym Jakarta EE okazuje się szczególnie wymagająca.
Czego dowiedzieliśmy się o agentach AI do modernizacji Java
Poza mierzeniem wskaźników sukcesu, ScarfBench pomaga zrozumieć, jak agenci zachowują się podczas modernizacji.
Czy agenci mogą niezawodnie stwierdzić, kiedy migracja jest zakończona?
Zmigrowana aplikacja jest użyteczna tylko wtedy, gdy faktycznie się buduje i uruchamia. IBM Research porównał wyniki zgłaszane przez agentów z niezależną weryfikacją budowania.
„Claude Code zgłosił pomyślne budowanie dla 29 z 30 całych aplikacji. Tylko 22 z tych aplikacji faktycznie zbudowały się pomyślnie. Tymczasem pojedyncza aplikacja sklasyfikowana przez agenta jako nieudana ostatecznie zbudowała się poprawnie.”
— IBM Research
Sugeruje to, że samoocena agenta nie powinna być traktowana jako wiarygodny sygnał zakończenia migracji. Niezależna walidacja budowania i testowania pozostaje niezbędna.
Jak agenci nawigują po zależnościach aplikacji?
Migracje frameworków rzadko dotyczą pojedynczego pliku lub warstwy. Zmiany w konfiguracji, usługach, bazach danych i komponentach internetowych często kaskadowo rozchodzą się po aplikacji.
Najczęściej odwiedzanymi warstwami były konfiguracja, sieć, baza danych i usługa. Typowe przejścia obejmowały konfiguracja ↔ sieć oraz usługa ↔ baza danych. Sugeruje to, że migracja jest iteracyjnym procesem rozwiązywania zależności, a nie prostą transformacją źródło-źródło.
Gdzie agenci spędzają najwięcej wysiłku?
Używając częstotliwości ponownych odwiedzin warstwy jako wskaźnika wysiłku migracyjnego, badacze odkryli, że konfiguracja dominuje w wysiłku migracyjnym. Zamiast postępować liniowo, agenci wielokrotnie wracali do artefaktów związanych z konfiguracją, rozwiązując różnice frameworków i problemy z zależnościami.
Jakie wyzwania nie dotyczą transformacji kodu?
Nie każdy problem migracyjny pochodzi z kodu źródłowego. Agenci często zmagali się z problemami środowiskowymi, w tym niespójnościami w pamięci podręcznej Dockera, problemami z łącznością portów oraz problemami z Maven wrapper i narzędziami budowania. Te problemy operacyjne często opóźniały walidację, nawet gdy migracja kodu źródłowego była w dużej mierze zakończona.
Rysunek: Rozkład trybów awarii
Awarie modernizacji obejmują systemy budowania, środowiska wdrożeniowe, iniekcję zależności, bazy danych, punkty końcowe, asercje i infrastrukturę.
Kluczowy wniosek
Największym wyzwaniem w modernizacji frameworków nie jest tłumaczenie kodu Java. Jest nim zarządzanie siecią zależności w konfiguracji, infrastrukturze i środowiskach wykonawczych. Podczas gdy czołowi agenci mogą zautomatyzować znaczące części procesu migracji, niezawodna walidacja i rozumowanie architektoniczne pozostają kluczowe dla osiągnięcia pomyślnych wyników.
ScarfBench pomaga ujawnić te wyzwania i zapewnia ustandaryzowany sposób mierzenia postępu w kierunku naprawdę autonomicznej modernizacji aplikacji.
Poznaj ScarfBench
ScarfBench jest zaprojektowany jako otwarty zasób dla badaczy i praktyków. Zasoby obejmują zestaw danych benchmarku, infrastrukturę ewaluacyjną, publiczną tabelę liderów, dokumentację i kod open-source. Badacze mogą porównywać architektury i techniki agentów. Praktycy mogą używać ScarfBench do oceny rozwiązań modernizacyjnych przed wdrożeniem ich w środowiskach produkcyjnych.
- Strona internetowa: https://scarfbench.info
- Zbiór danych: https://huggingface.co/datasets/ibm-research/ScarfBench
- Space: https://huggingface.co/spaces/ibm-research/ScarfBench
- Repozytorium GitHub: https://github.com/scarfbench/scarfbench
- Tabela liderów: https://scarfbench.info/leaderboard
- Artykuł: https://arxiv.org/abs/2605.06754
Migracja frameworków pozostaje jednym z największych nierozwiązanych problemów w inżynierii oprogramowania wspomaganej AI. IBM Research ma nadzieję, że ScarfBench pomoże społeczności mierzyć postępy i przyspieszyć następną generację modernizacji aplikacji wspomaganej AI. Zespół zaprasza badaczy, praktyków i autorów frameworków do współpracy i przesuwania granic tego, co agenci AI mogą osiągnąć w modernizacji oprogramowania korporacyjnego.
