SevenTnewS

Agentes de IA

Los agentes de IA no pueden completar una migración de Java sin que el servidor de compilación los detenga

IBM Research presenta ScarfBench, un benchmark abierto para evaluar agentes de IA en la migración de frameworks empresariales Java. Las primeras pruebas revelan que los agentes fronterizos son sistemáticamente demasiado confiados sobre sus propios resultados, que las capas de configuración dominan el esfuerzo y que problemas del entorno como las cachés de Docker desvían regularmente las migraciones incluso cuando las transformaciones de código tienen éxito.

Emmanuel Fabrice Omgbwa Yasse

2026-07-06 · 3 min de lectura

Los agentes de IA no pueden completar una migración de Java sin que el servidor de compilación los detenga

La migración de frameworks es el tipo de tarea que suena perfecta para un agente de codificación de IA: mecánica, repetitiva, regida por reglas bien documentadas. Reemplazar una anotación de Spring por una equivalente de Jakarta, ajustar un descriptor de persistencia, actualizar una dependencia de Maven. Un modelo de lenguaje grande debería manejar esto mientras duerme.

Resulta que no puede, al menos no de manera confiable, y ciertamente no sin una supervisión humana significativa.

IBM Research lanzó hoy ScarfBench (Benchmark de Refactorización de Aplicaciones Autocontenidas), un benchmark abierto diseñado para medir si los agentes de IA pueden migrar realmente aplicaciones empresariales Java reales entre frameworks como Spring, Jakarta EE y Quarkus. El hallazgo principal: los agentes fronterizos compilan código aproximadamente el 70 por ciento de las veces, pero solo alrededor del 50 por ciento de las aplicaciones migradas se implementan realmente y pasan la validación de comportamiento. Los propios agentes sobreestiman consistentemente su propio éxito. cuga-ibms-open-source-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list

Qué hace que la migración de frameworks sea fundamentalmente diferente

ScarfBench se construyó porque los benchmarks existentes de ingeniería de software, que prueban la corrección de errores o la generación de código aislado, no capturan la complejidad estructural de una migración entre frameworks. La modernización de Java a nivel de portafolio implica cambiar la inyección de dependencias, la configuración de persistencia, la sintaxis de consultas, los descriptores de compilación y el empaquetado en tiempo de ejecución. Un error en cualquier capa puede impedir la implementación, y los fallos se propagan en cascada. ifbench-the-new-benchmark-testing-ai-instruction-following

El benchmark incluye tanto tareas de migración enfocadas (traducciones de un solo componente) como migraciones de aplicaciones completas extraídas de una taxonomía Java empresarial basada en JSR. Cada aplicación se evalúa según tres criterios: ¿compila?, ¿se implementa? y ¿preserva el comportamiento? Ese tercer criterio es el que la mayoría de los benchmarks existentes omiten.

Los agentes son demasiado confiados, y eso es un riesgo real

Quizás el hallazgo más preocupante del artículo es la brecha entre el éxito reportado por el agente y el éxito verificado de forma independiente. Claude Code reportó compilaciones exitosas para 29 de 30 migraciones de aplicaciones completas. Solo 22 de esas aplicaciones realmente compilaron. Una aplicación que el agente clasificó como fallida resultó compilar correctamente.

“La autoevaluación del agente no debe tratarse como una señal confiable de finalización de la migración”, escriben los autores. En un entorno empresarial real, la falsa confianza podría llevar a los equipos a implementar aplicaciones rotas, o peor aún, a omitir la validación automatizada por completo bajo la suposición de que el agente ya ha verificado su trabajo. ScarfBench sostiene que la validación independiente de compilación y pruebas no es opcional, es la única señal que importa. why-your-ai-agent-might-ace-the-task-but-flunk-the-process-enter-skillcoach

La configuración es donde las migraciones van a morir

Cuando los investigadores rastrearon qué capas de una aplicación los agentes revisitaban con más frecuencia durante una migración, el patrón fue claro. Los archivos de configuración, application.properties, pom.xml, beans.xml, dominaron el registro de iteraciones. La transición más común en cada migración fue entre la configuración y la capa web, seguida de las transiciones de servicio a base de datos.

Esto no es un proceso lineal. Los agentes no traducen primero los archivos fuente y luego arreglan la configuración. Saltan entre las capas de configuración, web, base de datos y servicio, ajustando repetidamente las dependencias a medida que surgen incompatibilidades de framework. La migración es un ejercicio iterativo de resolución de dependencias, no una transformación de fuente a fuente.

Cachés de Docker, colisiones de puertos y wrappers de Maven

No todos los fallos son sobre código. El equipo de evaluación catalogó una gama de problemas del entorno que descarrilaron las validaciones: inconsistencias en la caché de Docker, problemas de conectividad de puertos, discrepancias de versiones del wrapper de Maven y peculiaridades de las herramientas de compilación. Estos fallos operativos a menudo retrasaron las pruebas mucho después de que el agente hubiera terminado lo que pensaba que era la migración de código. gui-agents-beat-cli-in-desktop-tasks-but-skill-coverage-holds-the-key

En un entorno de producción, un operador humano detectaría una colisión de puertos en segundos. Un agente, a menos que se le indique explícitamente verificar la infraestructura, simplemente reporta un fallo y puede que nunca aísle la causa raíz.

El framework de destino importa

La dificultad de la migración varía significativamente según el framework de destino. Jakarta EE resultó ser el objetivo más difícil, un hallazgo que los investigadores atribuyen a su mayor dependencia de descriptores XML y su modelo de implementación más complejo en comparación con Spring Boot o Quarkus. Las migraciones a Quarkus se situaron en un punto intermedio, con tasas de éxito de compilación notablemente más altas que las tasas de éxito de comportamiento, lo que sugiere que Quarkus compila fácilmente, pero su semántica de tiempo de ejecución reactiva tropieza a los agentes durante la implementación. tcs-and-anthropic-partner-to-bring-claude-to-regulated-industries

El benchmark está diseñado para ser extensible, y el equipo invita a contribuir con nuevos escenarios de migración. El conjunto de datos, la infraestructura de evaluación y la tabla de clasificación son de código abierto.

ScarfBench no será la última palabra sobre la migración asistida por IA, pero proporciona la primera vara de medir confiable. La brecha entre el éxito de compilación y el éxito de comportamiento es la brecha entre un agente que parece productivo y uno que realmente lo es.