ScarfBench: qué revelan los agentes de IA sobre la migración de frameworks Java empresariales

Introducción

La modernización de aplicaciones empresariales es una de las tareas de ingeniería de software más complejas y costosas. En América Latina, donde muchas organizaciones combinan sistemas heredados con iniciativas de nube y digitalización, la capacidad de migrar frameworks de forma eficiente afecta directamente a la mantenibilidad, la productividad de desarrolladores y la preparación para la nube.

En este contexto, ScarfBench surge como un benchmark que prueba si los agentes de IA pueden realmente encargarse de migraciones cross-framework en aplicaciones Java empresariales, evaluando mucho más que la mera generación de código.

Por qué la migración de frameworks es un problema distinto

Migrar de un framework a otro no es solamente reemplazar anotaciones o renombrar paquetes. En aplicaciones empresariales, una migración exitosa exige:

• Preservar el comportamiento de negocio y las pruebas.
• Adaptar sistemas de construcción (builds), dependencias y descriptores de despliegue.
• Ajustes en inyección de dependencias, configuración de persistencia, consultas y demás componentes transversales.

Pequeños errores en cualquiera de estos puntos pueden impedir que la aplicación se despliegue o que su comportamiento sea correcto en producción.

Qué es ScarfBench y cómo funciona

ScarfBench (Self-Contained Application Refactoring Benchmark) es un benchmark abierto diseñado para medir la capacidad de agentes de IA en tareas de migración entre tres ecosistemas claves de Java empresarial: Spring, Jakarta EE y Quarkus.

A diferencia de benchmarks tradicionales que comparan código generado con una implementación de referencia, ScarfBench exige que las aplicaciones migradas:

• Compilen correctamente.
• Se desplieguen sin errores.
• Pasen validaciones de comportamiento (tests expertos).

De esta forma ofrece una medida realista de la calidad de la modernización.

El alcance del benchmark

ScarfBench incluye tanto tareas focalizadas como migraciones de aplicaciones completas. Algunos números clave del benchmark son:

• Aplicaciones: 34
• Implementaciones de frameworks: 102
• Tareas de migración: 204
• Líneas de código aproximadas: 151,000
• Archivos fuente y de prueba: ~2,000
• Tests escritos por expertos: 1,331

La construcción del benchmark parte de una taxonomía JSR de Java empresarial y emplea migraciones verificadas por expertos para generar implementaciones en Spring, Jakarta EE y Quarkus.

Rendimiento de los agentes frontier

Aunque los agentes de código han mostrado progreso en benchmarks tradicionales (corrección de bugs, generación de fragmentos), ScarfBench revela limitaciones claras cuando se trata de migraciones reales:

• Las tasas de éxito de comportamiento son bajas: incluso los agentes más avanzados alcanzan menos del 10% de éxito en pruebas de comportamiento.
• Hay una progresión típica: el éxito de compilación supera al de despliegue, y este último supera al éxito en las pruebas de comportamiento. Construir el artefacto no garantiza que se despliegue ni que mantenga el comportamiento esperado.

Además, la dificultad depende del par de frameworks: ciertas migraciones, como hacia Jakarta EE, resultan particularmente desafiantes.

Lecciones prácticas extraídas del benchmark

ScarfBench no solo mide resultados, también ayuda a entender cómo y por qué fallan los agentes durante la modernización.

1. Autoevaluación de agentes poco fiable

Un hallazgo importante fue la sobreconfianza de algunos agentes. Por ejemplo, un agente reportó compilaciones exitosas en 29 de 30 aplicaciones completas, pero solo 22 de esas compilaciones resultaron correctas tras la verificación independiente. Además, la única aplicación que el agente clasificó como falla sí llegó a compilar correctamente. Esto confirma que la autoevaluación de un agente no reemplaza validaciones independientes en CI/CD.

2. La migración es iterativa, no lineal

Los agentes no realizan una simple transformación archivo a archivo. Las capas más visitadas durante los procesos de migración fueron: configuración, web, base de datos y servicios. Las transiciones frecuentes entre estas capas (por ejemplo, configuración ↔ web o servicio ↔ base de datos) muestran que la migración es un proceso iterativo de resolución de dependencias.

3. Configuración concentra el esfuerzo

El mayor esfuerzo, medido por la frecuencia de revisitas, recayó en archivos de configuración. Resolver diferencias de frameworks y dependencias suele requerir múltiples iteraciones sobre configuración, scripts de build y descriptores de despliegue.

4. Problemas no relacionados con el código fuente

Los agentes también se toparon con cuestiones del entorno y la infraestructura: inconsistencias en caches de Docker, problemas de conectividad de puertos y fallas en wrappers y herramientas de build como Maven. Estos problemas operativos pueden retrasar o bloquear la validación aun cuando el código fuente esté correctamente adaptado.

Implicaciones para equipos y tomadores de decisión en América Latina

Para organizaciones que planean aprovechar agentes de IA en modernización, ScarfBench sugiere varias prioridades:

• No confiar solo en la salida del agente: integrar verificaciones independientes de build y pruebas automatizadas en pipelines es indispensable.
• Preparar la infraestructura: asegurar entornos reproducibles (CI, caches controlados, redes) reduce fricciones durante la validación.
• Enfocar en configuración e infraestructura: muchos problemas aparecen fuera del código fuente; dedicar esfuerzos a infraestructura como código, contenedores y despliegues facilita la migración.
• Considerar la complejidad del objetivo: migrar hacia ciertos frameworks puede ser más costoso; planifiquen pilotos y validaciones progresivas.

En un entorno latinoamericano donde la adopción de nube y plataformas modernas crece, estas recomendaciones ayudan a minimizar riesgos y a aprovechar las capacidades de automatización sin delegar por completo la supervisión humana.

Conclusión

ScarfBench demuestra que la principal barrera en la modernización de aplicaciones Java empresariales no es tanto traducir código, sino manejar la red de dependencias entre configuración, infraestructura y entornos de ejecución. Los agentes de IA prometen automatizar partes importantes del proceso, pero hoy por hoy su éxito real —entendido como compilación, despliegue y preservación del comportamiento— sigue siendo limitado. La validación independiente, la infraestructura reproducible y la atención a la configuración son elementos clave para convertir las capacidades de IA en modernizaciones confiables.