ScarfBench: lo que pasa cuando le pedís a un agente de IA que migre código Java de verdad

Hay una promesa que se repite mucho en el marketing de IA para desarrolladores: los agentes de código ya pueden modernizar sistemas legacy completos, solos, sin intervención humana. IBM Research decidió medir esa promesa con rigor, en vez de creerle al discurso, y construyó un benchmark específico para eso. Los resultados sirven como recordatorio útil de algo que en Criterio AI repetimos seguido: lo que un agente de IA dice que hizo y lo que realmente hizo no siempre son la misma cosa.

Qué es ScarfBench

ScarfBench (sigla de "Self-Contained Application Refactoring Benchmark") es un conjunto de aplicaciones Java reales, escritas y validadas a mano por desarrolladores con experiencia, diseñado específicamente para medir si un agente de inteligencia artificial puede migrar aplicaciones empresariales entre distintos frameworks —Spring, Jakarta EE y Quarkus, tres de los frameworks más usados en el mundo del software corporativo Java— manteniendo el mismo comportamiento, los mismos patrones de código idiomático, y la misma arquitectura.

Para quien no programa: pensalo como pedirle a alguien que traduzca un libro completo de un idioma a otro, pero exigiendo que la traducción no solo tenga sentido gramatical, sino que también mantenga exactamente el mismo tono, la misma estructura de capítulos, y que cada chiste siga siendo gracioso en el idioma nuevo. Traducir palabra por palabra es relativamente fácil. Preservar el comportamiento completo del sistema original es mucho más difícil.

El benchmark incluye 34 familias de aplicaciones (29 más chicas, enfocadas en una sola capa técnica, y 5 aplicaciones completas que combinan varias capas), lo que da un total de 204 tareas de migración dirigidas, evaluadas contra 1.331 tests escritos por expertos. Una tarea solo se considera exitosa si la aplicación migrada compila, se despliega correctamente, y pasa esos tests de comportamiento — no alcanza con que "parezca" funcionar.

El hallazgo más incómodo: la IA no siempre sabe si hizo bien su trabajo

El dato más importante de todo el estudio no es sobre cuánto código puede escribir un agente de IA — es sobre cuánto podés confiar en lo que el agente te dice sobre su propio trabajo. Los investigadores compararon lo que el agente Claude Code reportaba sobre el resultado de su propia migración contra una verificación independiente y objetiva (si la aplicación realmente compilaba o no).

El resultado: Claude Code reportó que 29 de 30 aplicaciones completas habían compilado exitosamente. Al verificarlo de forma independiente, solo 22 de esas 29 realmente compilaban. Y para agregar una capa más de matiz: la única aplicación que el propio agente había clasificado como fallida, en realidad sí compilaba bien cuando se la verificó.

La conclusión que sacan los propios investigadores de IBM es directa y aplica más allá de este benchmark específico: la autoevaluación de un agente de IA no debería tratarse como una señal confiable de que una tarea de migración está completa. La validación independiente de compilación y de tests sigue siendo indispensable.

Los números completos, para quien quiera el detalle técnico

El paper académico que acompaña al benchmark (publicado también en arXiv) da el panorama completo evaluando cinco agentes de código distintos, cada uno con su modelo de IA más fuerte disponible en el momento de la prueba: Claude Code con Claude Opus 4.6, Gemini CLI con Gemini 3.1 Pro, Codex con GPT-5.4, Opencode con GLM-5.1, y Qwen CLI con Qwen 3.5.

En el escenario de aplicaciones completas (el más difícil y el más representativo de un proyecto real), Claude Code con Opus 4.6 fue el que mejor resultado obtuvo: 87% de las migraciones lograron compilar, pero solo un 40% logró desplegarse correctamente, y apenas un 12% pasó los tests de comportamiento completos. En el escenario de tareas más acotadas (una sola capa de la aplicación), el mejor resultado general de todos los agentes evaluados llegó a un 15,3% de éxito completo en el conjunto agregado de tests — y de las 204 tareas de migración totales del benchmark, solo una logró ser completamente equivalente en comportamiento al original.

Dicho de otra forma: cuanto más grande y más real es el sistema que le pedís a un agente que migre, más se derrumba la tasa de éxito real, aunque la tasa de "parece que compiló" se mantenga engañosamente alta.

Por qué falla, específicamente

Los investigadores no se quedaron en el número — clasificaron los tipos de fallas. Encontraron que las migraciones de framework rara vez afectan un solo archivo o una sola capa del sistema: los cambios en configuración, en servicios, en la capa de base de datos y en los componentes web suelen encadenarse entre sí. Esto los lleva a una conclusión conceptual importante: migrar un sistema no es una simple traducción de código fuente de un formato a otro — es un proceso iterativo de resolución de dependencias, donde arreglar una cosa rompe otra, y hay que iterar.

También encontraron que la dificultad no es pareja entre distintos pares de frameworks: la migración entre Spring y Quarkus resultó ser la más manejable de todas, mientras que migrar hacia Jakarta EE resultó ser consistentemente la más difícil para los cinco agentes evaluados.

Qué significa esto si trabajás con WordPress, PHP o cualquier stack que no sea Java

Aunque el benchmark es específico de Java empresarial, la lección de fondo aplica a cualquier lenguaje o framework, incluido el mundo WordPress y PHP donde probablemente trabajás vos: los agentes de código son genuinamente útiles para acelerar tareas de migración y refactor, pero la magnitud del salto entre "generó código que parece correcto" y "el sistema funciona igual que antes en producción" sigue siendo enorme cuando el proyecto tiene el tamaño y la complejidad de un sistema real, con múltiples capas interconectadas.

Qué podés hacer con esto, en la práctica

• Nunca aceptes el reporte de éxito de un agente de IA como verificación final. Corré vos mismo el build, el deploy y los tests — automatizados, si podés — antes de dar por cerrada cualquier tarea de migración o refactor grande que hiciste con ayuda de IA.
• Cuanto más grande y más interconectado el sistema, más desconfianza aplicá. Los números de este benchmark muestran que el éxito cae drásticamente al pasar de una tarea acotada (una sola capa) a una aplicación completa. Si vas a delegarle a un agente una migración grande, dividila en partes verificables en vez de pedirle todo de una.
• Usá agentes de IA para acelerar el primer borrador de una migración, no para reemplazar la validación humana. El valor real hoy está en que el agente te ahorre las horas de traducción mecánica inicial — la revisión y la verificación de que el comportamiento se preservó siguen siendo trabajo humano indispensable.
• Si estás evaluando herramientas o vendors que prometen "modernización automática con IA", pedí específicamente sus números en benchmarks independientes como este, no solo sus casos de éxito curados — es exactamente la misma lógica de "no confíes en la autoevaluación" que reveló este estudio.

La conclusión más honesta, sin restarle mérito al avance real que representan estos agentes: la IA de código hoy acelera el trabajo de migración de forma genuina, pero está lejos de poder hacerlo sola de punta a punta en sistemas reales — y confiar ciegamente en que "el agente dijo que terminó" es, según este estudio, un error medible y frecuente.

También en Criterio AI

Si este tema te interesa desde una mirada más práctica, también publicamos una guía base sobre cómo usar agentes de código sin romper tu proyecto.