Resumen Técnico: SCARFBENCH

Enunciado del Problema

Java empresarial sigue siendo una fuerza dominante en la infraestructura de software, con muchas aplicaciones que sobreviven más allá de sus supuestos arquitectónicos originales. Si bien la modernización a menudo es impulsada por presiones de obsolescencia y objetivos no funcionales como la reducción de la sobrecarga de memoria y la mejora de la elasticidad en la nube, migrar estas aplicaciones entre frameworks (específicamente entre Spring, Jakarta EE y Quarkus) es una empresa compleja y propensa a riesgos.

Las actuales referencias de ingeniería de software evalúan principalmente la corrección de errores, la implementación de características o las actualizaciones de versiones de lenguaje dentro de una pila de frameworks fija. En gran medida, fallan al medir la refactorización de aplicaciones entre frameworks, una tarea que requiere más que una sustitución local de APIs. Una migración exitosa exige cambios coordinados en las configuraciones de compilación, la inyección de dependencias, la persistencia, el manejo de solicitudes y el despliegue para preservar el comportamiento de la aplicación. Las referencias existentes a menudo asumen que preservar el modelo de programación subyacente es suficiente, una suposición que no se sostiene al moverse entre frameworks con modelos de ejecución e idiosincrasias divergentes.

Metodología: SCARFBENCH

Los autores introducen SCARFBENCH (Referencia de Refactorización de Aplicaciones Autocontenidas), una referencia diseñada para evaluar la capacidad de los agentes de Modelos de Lenguaje Grande (LLM) para realizar migraciones entre frameworks que preservan el comportamiento.

Construcción de la Referencia

• Alcance: La referencia comprende 34 familias de aplicaciones implementadas en tres frameworks: Spring Boot, Jakarta EE y Quarkus.
• Estructura: Se divide en dos niveles:
  1. Nivel Enfocado: 29 aplicaciones autocontenidas que aíslan capas arquitectónicas específicas (Inyección de Dependencias, Persistencia, Presentación, Infraestructura, Dominio de Negocio) ancladas en las Solicitudes de Especificación de Java (JSR).
  2. Nivel de Aplicación Completa: 5 sistemas de código abierto más grandes y realistas que combinan estas capas, probando el acoplamiento entre capas y los flujos de trabajo de extremo a extremo.
• Variantes: Estas aplicaciones generan 102 variantes específicas del framework (aproximadamente 151K líneas de código Java emparejado a través de 1.946 archivos de origen y prueba).
• Tareas: La referencia define 204 tareas de migración dirigidas (por ejemplo, Spring $\to$ Jakarta, Jakarta $\to$ Quarkus). Cada tarea requiere que un agente sintetice una implementación de destino que preserve el comportamiento de origen.
• Verdad Terrenal: Desarrolladores expertos de Java implementaron manualmente las tres variantes del framework para cada familia de aplicaciones, asegurando que existan implementaciones equivalentes en comportamiento para la validación.

Protocolo de Evaluación

• Agentes: Se evaluaron cinco agentes de codificación de vanguardia: Claude Code (Opus 4.6), Gemini CLI (Gemini-3.1 Pro), Codex (GPT-5.4), Opencode (GLM-5.1) y Qwen CLI (Qwen3.5-397B-A17B).
• Entorno de Ejecución: Un entorno de ejecución contenerizado evalúa a los candidatos en tres etapas secuenciales:
  1. Compilación: El candidato debe compilarse con éxito.
  2. Despliegue: La aplicación debe iniciarse dentro de un entorno de ejecución contenerizado y emitir señales de preparación.
  3. Pruebas de Comportamiento: El candidato debe aprobar un conjunto de 1.331 pruebas de comportamiento escritas por expertos.
• Oráculo: La corrección se determina mediante un oráculo de comportamiento neutral al framework. En lugar de pruebas unitarias (que requerirían su propia migración), el oráculo utiliza especificaciones Gherkin concretizadas en scripts de Playwright/pytest. Estas pruebas verifican la equivalencia observable externamente (rutas HTTP, cargas de respuesta, flujos de interfaz de usuario y cambios de estado persistente).
• Métricas: El éxito se mide mediante pass@1 a temperatura 0, requiriendo que el candidato compile, despliegue y apruebe el 100% de las pruebas de comportamiento.

Contribuciones Clave

1. Conjunto de Datos SCARFBENCH: Un corpus curado de 34 familias de aplicaciones que generan 102 variantes y 204 tareas de migración dirigidas, verificadas por 1.331 pruebas de comportamiento escritas por expertos en un entorno contenerizado.
2. Evaluación Empírica: Una evaluación exhaustiva de cinco agentes de codificación de vanguardia, que revela brechas significativas en las capacidades actuales para transformaciones a nivel de sistema.
3. Taxonomía de Fallos: Una clasificación de 13 categorías de fallos recurrentes que abarcan las etapas de compilación, despliegue y prueba, derivadas de la adjudicación experta de trazas fallidas.

Resultados Experimentales

La evaluación revela que la migración de frameworks que preserva el comportamiento sigue siendo un desafío significativo para los agentes actuales:

• Tasas de Éxito Bajas: El agente más fuerte (Claude Code con Opus 4.6) logró solo un 15,3% de aprobaciones agregadas en pruebas para migraciones de capas enfocadas y un 12,2% para aplicaciones completas. De las 204 tareas dirigidas, solo una migración producida por un agente aprobó su conjunto completo de pruebas.
• Compilación/Despliegue vs. Comportamiento: Existe una desconexión marcada entre el éxito superficial y la corrección del comportamiento. Los agentes frecuentemente producen código que se compila y despliega pero falla en las pruebas de comportamiento. Por ejemplo, en migraciones de aplicaciones completas, el éxito de compilación puede alcanzar el 87% mientras que el éxito conductual cae al 12%.
• Dificultad Asimétrica: La dificultad de la migración depende altamente del framework de destino:
  • Spring $\leftrightarrow$ Quarkus: El par más manejable.
  • Destinos Jakarta EE: Los más difíciles. Solo el 2% de las migraciones dirigidas a Jakarta EE aprueban las pruebas de comportamiento, con un 57% fallando en la puerta de compilación.
• Ingeniería de Prompts: La formulación de prompts basada en "habilidades" (modularizando la orientación) mejoró las tasas de compilación y despliegue, particularmente para tareas enfocadas, pero no cerró significativamente la brecha en la corrección del comportamiento para aplicaciones completas.

Análisis de Fallos

El análisis de las tareas fallidas identificó que los errores se extienden más allá de la traducción a nivel de origen. Los modos de fallo comunes incluyen:

• Etapa de Compilación: Problemas de resolución de dependencias, referencias a módulos obsoletos y discrepancias en la estructura del proyecto.
• Etapa de Despliegue: Discrepancias en recursos/artefactos (por ejemplo, empaquetado WAR vs. JAR), configuración de ejecución incorrecta (por ejemplo, discrepancias de puertos) y cableado de dependencias roto.
• Etapa de Pruebas: Faltan puntos de conexión, contenido de respuesta incorrecto y problemas de conectividad de infraestructura.
  Los autores señalan que las migraciones dirigidas a Jakarta fallan desproporcionadamente en la puerta de compilación, lo que sugiere una divergencia entre las idiosincrasias de frameworks aprendidas y las convenciones de empaquetado y configuración de servidor de Jakarta.

Significado y Afirmaciones

El artículo afirma que, si bien los agentes actuales pueden traducir con fiabilidad las APIs de frameworks a nivel de origen, luchan por reexpresar el comportamiento de la aplicación a través del modelo de ejecución del framework de destino. Los resultados sugieren que el progreso en referencias a nivel de repositorio (como la corrección de errores o las actualizaciones de versiones) no se transfiere limpiamente a transformaciones a nivel de sistema que requieren la ejecución en un entorno de ejecución de destino.

Los autores posicionan a SCARFBENCH como un paso necesario hacia la evaluación de las capacidades "agentes" de los LLM en escenarios empresariales realistas, destacando que la verdadera modernización requiere más que una sustitución sintáctica; exige una comprensión profunda del acoplamiento arquitectónico, la semántica de la configuración y la preservación del comportamiento. La referencia, el entorno de ejecución y las trazas de los agentes se ponen a disposición para facilitar investigaciones adicionales sobre la modernización automatizada de software.