ScarfBench: benchmark para migraciones de Java empresarial | Keryc
La modernización asistida por IA suena a solución mágica: que un agente lea tu repositorio y lo deje listo para producción. ¿Pero puede realmente migrar aplicaciones empresariales complejas sin romper nada? ScarfBench llega para responder esa pregunta con datos, no con promesas.
Qué es ScarfBench
ScarfBench (Self-Contained Application Refactoring Benchmark) es un benchmark abierto diseñado para evaluar agentes de código en tareas reales de migración entre ecosistemas Java empresariales: Spring, Jakarta EE y Quarkus.
No se limita a comparar archivos fuente contra una referencia. En vez de eso exige que las aplicaciones migradas: se compilen, se desplieguen y mantengan el comportamiento funcional. ¿Por qué importa eso? Porque una migración útil no es solo código bonito: es código que corre en un entorno real y hace lo que debe.
Cómo evalúa ScarfBench
ScarfBench incorpora dos tipos de tareas: migraciones focalizadas (componentes, capas) y migraciones de aplicaciones completas. Parte de una taxonomía basada en JSRs y usa migraciones verificadas por expertos para generar implementaciones en cada framework objetivo.
La evaluación sigue tres etapas prácticas:
Build: la aplicación debe compilar exitosamente.
Deploy: debe poderse desplegar en el entorno esperado (contenedor, servidor, etc.).
Behavioral validation: pruebas funcionales que confirman que el comportamiento se preservó.
Este flujo Compile -> Deploy -> Test expone que compilar no basta para asegurar una migración correcta.
Resultados clave (qué encontraron al poner agentes a prueba)
Los agentes que brillan en benchmarks tradicionales muestran progresos, pero en ScarfBench las métricas son mucho más humildes. Puntos destacados:
Las tasas de éxito en comportamiento son bajas: incluso los agentes más avanzados alcanzan menos del 10% en éxito conductual para aplicaciones enteras.
Éxitos de compilación superan los de despliegue, y estos a su vez superan los de validación de comportamiento. Conclusión: el build por sí solo sobreestima la calidad.
La dificultad varía según el par de frameworks; Jakarta EE resultó particularmente desafiante.
Un dato práctico: un agente (Claude Code) reportó builds exitosos para 29 de 30 aplicaciones completas, pero solo 22 de esas realmente compilaron cuando se verificó de forma independiente. Y la única que el agente marcó como fallida sí compilaron correctamente. ¿Qué nos dice eso? Las autoverificaciones de los agentes no son fiables; la validación independiente sigue siendo crucial.
Por qué migrar frameworks es mucho más que cambiar anotaciones
Si imaginas una migración como un find-and-replace de anotaciones estás subestimando el problema. Una migración completa suele requerir alterar:
Inyección de dependencias y scopes.
Configuración de persistencia y queries.
Descriptores y archivos de configuración (archivos xml, application.properties, application.yaml y similares).
Adaptaciones en el sistema de build y wrappers (Maven, Gradle).
Pequeños errores en cualquiera de estas piezas pueden impedir el despliegue. Además, los cambios se propagan entre capas: configuración, web, base de datos y servicios son las capas más visitadas por los agentes.
Observaciones técnicas y de ingeniería
ScarfBench no solo mide si algo falla, sino cómo y por qué falla. Algunos patrones observados:
Los agentes revisitan repetidamente capas de configuración: eso es indicativo de un proceso iterativo de resolución de dependencias más que de una simple transformación de código.
Las fallas no siempre nacen en el código fuente. Problemas ambientales como caches de Docker, puertos en uso, o inconsistencias en el wrapper de Maven a menudo bloquean la validación.
Las dificultades cubren un amplio espectro: sistemas de build, infraestructuras de despliegue, inyección de dependencias, bases de datos, endpoints y aserciones en tests.
Técnicamente, esto sugiere que un agente ideal necesita más que buena generación de código: requiere razonamiento arquitectural, gestión de estado de entorno y capacidades de diagnóstico y reparación de infra.
¿Qué aporta ScarfBench a la comunidad técnica?
ScarfBench es una herramienta de medición y diagnóstico:
Dataset de migraciones y código fuente en varios frameworks.
Infraestructura de evaluación reproducible (builds, despliegues, pruebas).
Leaderboard público para comparar agentes y enfoques.
Documentación y código abierto para que investigadores y equipos de ingeniería puedan reproducir y extender los estudios.
Para investigadores: una plataforma para comparar arquitecturas, técnicas de prompting, fine-tuning, y estrategias de interacción con entornos. Para equipos de producción: un banco de pruebas para validar soluciones de modernización antes de arriesgar sistemas reales.
Qué significa esto para tu proyecto de modernización
Si estás considerando usar agentes de IA para migrar una aplicación empresarial, toma nota:
No confíes solo en la salida del agente. Implementa validación independiente de build y pruebas funcionales.
Prepara la infraestructura: contenedores limpios, control de puertos, y wrappers de build homogéneos reducen ruido operativo.
Considera una estrategia híbrida: automatizar tareas repetitivas con agentes y dejar el razonamiento arquitectural y la verificación crítica para el equipo humano.
ScarfBench evidencia que la gran frontera no es traducir líneas, sino manejar la red de dependencias entre código, configuración e infraestructura.
Si te provoca curiosidad técnica: examinar los fallos más comunes y la frecuencia de revisitas por capa te dará ideas sobre en qué invertir para que la automatización rinda más (mejorar tests, estandarizar config, fortalecer CI/CD, etc.).
