Alianzas
IBM y Kaggle se asocian para crear una clasificación de migraciones de ScarfBench con actualizaciones continuas
Añade Unite.AI a tus fuentes preferidas en Google
IBM y Kaggle colaboran en una clasificación pública de ScarfBench que se actualiza continuamente. ScarfBench es el benchmark abierto de IBM para evaluar agentes de programación en migraciones de frameworks Java empresariales, según una nota técnica de IBM Research publicada el 27 de octubre de 2026.
ScarfBench, sigla de Self-Contained Application Refactoring Benchmark, evalúa si un agente puede tomar una aplicación Java empresarial que no conoce, migrarla entre Jakarta EE, Quarkus y Spring, y dejarla funcionando. El benchmark comprueba que las aplicaciones generadas se compilen, se inicien y sigan comportándose como se espera, tanto en cargas de trabajo específicas como en aplicaciones completas. IBM presentó ScarfBench a principios de 2026 como un benchmark reproducible para migraciones impulsadas por IA. El anuncio original, fechado el 11 de marzo de 2026, describía siete componentes, entre ellos aplicaciones empresariales de los tres frameworks verificadas por desarrolladores, cargas de trabajo específicas que aíslan aspectos como el comportamiento de la persistencia y la inyección de dependencias, aplicaciones completas que combinan varias capas arquitectónicas, validación automatizada de la compilación y el inicio, y pruebas de comportamiento que verifican el comportamiento en tiempo de ejecución y la equivalencia funcional. Según el anuncio, desarrolladores experimentados implementaron y validaron manualmente cada carga de trabajo para comprobar la equivalencia funcional y el uso idiomático de los frameworks.
La colaboración entre IBM y Kaggle
En el marco de la alianza, Kaggle asesoró a IBM en el diseño del benchmark y la evaluación, reprodujo ScarfBench de forma independiente y lo ejecutó en su propia plataforma, patrocinando los recursos de cómputo, y se encargará de mantener el benchmark a largo plazo. IBM describió las fortalezas de ambos equipos como complementarias: IBM desarrolló ScarfBench en torno a la modernización de Java empresarial, mientras que Kaggle aporta una infraestructura de evaluación independiente y el mantenimiento continuo de la clasificación.
Resultados en 204 tareas de migración
ScarfBench evalúa un sistema agéntico, no un modelo de lenguaje de forma aislada: cada resultado corresponde a un modelo combinado con un entorno de ejecución de agente de programación que determina cómo interactúa el modelo con el repositorio y el entorno de desarrollo. IBM advirtió que las puntuaciones deben interpretarse como resultados del modelo y su entorno de ejecución, no como mediciones del modelo subyacente por sí solo.
En las 204 tareas de migración y las diez configuraciones de modelo y entorno de ejecución evaluadas, Gemini 4 Argon con el entorno Antigravity ocupó el primer puesto en la métrica principal de pruebas de humo, con un 75,2 %, informó IBM. Le siguieron Claude Opus 5.5 con Claude Code, con un 70,5 %, y Claude Opus 5 con Claude Code, con un 69,8 %. La puntuación de las pruebas de humo, que se utiliza como métrica de la clasificación, otorga crédito parcial y da más peso a las suites de pruebas grandes. En la métrica más estricta, que exige superar todas las pruebas, Claude Opus 5.5 con Claude Code obtuvo la tasa más alta, un 72,1 %, apenas por delante de Gemini 4 Argon con Antigravity, que alcanzó el 71,1 %.
Según la publicación, el orden de los primeros puestos se mantuvo en un análisis de sensibilidad. Cuatro de las 204 tareas no recibieron crédito en las pruebas de comportamiento con ninguna configuración. Al excluirlas, aumentaron las puntuaciones absolutas, pero los líderes no cambiaron: Gemini 4 Argon con Antigravity obtuvo un 79,4 %, seguido de Claude Opus 5.5 con Claude Code, con un 74,5 %, y Claude Opus 5 con Claude Code, con un 73,7 %. IBM señaló que incluso la combinación más sólida tenía un margen de mejora considerable: ninguna configuración superó por completo aproximadamente tres cuartas partes de las migraciones.
Dónde tienen éxito y dónde fallan las configuraciones
IBM informó que la mayor brecha de la evaluación se daba entre el código que se compila y el software que se comporta correctamente. Tras excluir las cuatro tareas que obtuvieron cero en todas las configuraciones, Claude Opus 5 con Claude Code, Gemini 4 Argon con Antigravity y Gemini 3.8 Flash con mini-swe compilaron el 100 % de las tareas, y ocho de las diez configuraciones compilaron al menos el 97 %. En cambio, las puntuaciones de las pruebas de humo presentaron una diferencia de más de 50 puntos. Entre las aplicaciones implementadas correctamente, las configuraciones líderes se situaron en torno al 63 %–76 % de pruebas superadas en su totalidad, mientras que Kimi K3 con kimi-code obtuvo un 53 %, Gemini 3.1 Pro con OpenHands, un 42 %, y Gemma 4 26B-A4B con mini-swe, un 26 %.
IBM clasificó 745 ejecuciones fallidas: 535, aproximadamente el 72 %, fueron fallos de comportamiento en tiempo de ejecución, en los que la aplicación se compiló y a menudo llegó a iniciarse, pero no superó la validación del comportamiento. En ese grupo hubo 304 discrepancias de contenido o de aserciones, 210 fallos por rutas perdidas o errores 404, y 21 errores HTTP 500 o 405 explícitos. Los fallos de compilación o empaquetado representaron aproximadamente el 20 % de las ejecuciones fallidas, con 152 casos, mientras que los bloqueos durante el inicio o por la inyección de dependencias supusieron aproximadamente el 8 %, con 58 casos.
La publicación presenta ejemplos de tareas concretas. En concurrency-taskcreator-quarkus-to-jakarta, Claude Opus 5 con Claude Code obtuvo 0/6 después de que el endpoint /taskinfo devolviera «Archivo no encontrado» y fallara una prueba que esperaba HTTP 405. En address-book-jakarta-to-quarkus, GPT-6 Astra con Codex obtuvo 2/10 después de que las páginas de listado y creación devolvieran HTTP 404. En cargotracker-jakarta-to-spring, Gemini 3.8 Flash con mini-swe conservó la configuración de JSF/JoinFaces en el destino Spring Boot y falló durante el inicio al crear un bean facesContext. En cart-spring-to-jakarta, GPT-6 Astra con Codex no pudo implementar la aplicación porque el tipo de empaquetado que dejó la migración no era compatible con el entorno de ejecución Liberty de destino.
IBM informó que la eficiencia también varió según la configuración. En las 200 tareas restantes tras la exclusión por sensibilidad, la mediana de turnos osciló entre 32 para Claude Opus 5 con Claude Code y 79 para Gemini 3.8 Flash con mini-swe; Claude Opus 5.5 con Claude Code registró 64. En las configuraciones cuyos entornos de ejecución informaron los costos —Claude Code, Codex, mini-swe y kimi-code—, el costo por tarea resuelta osciló entre $1.25 para GPT-6.1 Sol con Codex y $10.10 para Claude Opus 5.5 con Claude Code; los entornos de ejecución de Antigravity, qwen-code y OpenHands no proporcionaron cifras de costo por ejecución.
La clasificación de ScarfBench ofrece una vista pública de estos resultados. Al lanzamiento, no estará disponible el envío público de modelos, pero IBM dijo que está previsto en la hoja de ruta.
