Resumen Técnico: REFINE – Un enfoque de múltiples agentes de LLM para la refactorización de código guiada por evidencia

Declaración del Problema

Si bien los Modelos de Lenguaje de Gran Tamaño (LLMs) demuestran capacidades sólidas en la generación y transformación de código, su aplicación a la refactorización de software enfrenta desafíos significativos. Una refactorización efectiva requiere no solo modificar el código para reducir problemas de calidad (code smells), sino también asegurar que los cambios no introduzcan nuevos defectos, alteren el comportamiento externo o eliminen elementos estructurales críticos (por ejemplo, APIs públicas, aserciones).

Los enfoques actuales de refactorización asistida por LLM carecen a menudo de una verificación rigurosa, lo que conlleva riesgos como sugerencias alucinadas, transformaciones inconsistentes y la eliminación de estructuras de código relevantes para el comportamiento. Existe la necesidad de un enfoque sistemático que:

1. Guíe a los LLMs con evidencia proveniente del análisis estático.
2. Orqueste un flujo de trabajo de múltiples agentes para planificar, generar y verificar cambios.
3. Proporcione evidencia trazable de qué se cambió, qué riesgos permanecen y si el resultado es un candidato de refactorización viable en lugar de una solución aceptada automáticamente.

Metodología: El Flujo de Trabajo REFINE

Los autores presentan REFINE (Refactoring with Evidence-aware Flow for Integrated ageNtic Execution), un marco de trabajo de múltiples agentes, agnóstico a las herramientas y consciente de la evidencia, diseñado para la refactorización a nivel de archivo de Java. El sistema está implementado como un prototipo de investigación utilizando una interfaz Next.js, un backend Java Spring Boot (para análisis estático mediante PMD 7.x) y un servicio de agentes en Python (usando LangGraph v1.1) para la orquestación.

El flujo de trabajo opera a través de tres etapas primarias:

1. Caracterización de la Tarea

• Entrada: Un único archivo Java de un proyecto de código abierto.
• Recopilación de Evidencia: El análisis estático (PMD) identifica code smells a nivel de archivo y evidencia a nivel de regla.
• Contextualización: El sistema extrae firmas de API públicas, contexto del espacio de trabajo y prioriza los smells detectados para formar una tarea de refactorización acotada.

2. Orquestación de la Refactorización

El flujo de trabajo coordina once roles distintos (agentes) para gestionar el proceso:

• Agente de Planificación: Combina la guía determinista basada en reglas con el refinamiento opcional de LLM para crear un plan de refactorización orientado a los smells.
• Agente de Refactorización: Invoca a un LLM para generar una transformación candidata basada en el plan, el código fuente original y las restricciones (por ejemplo, preservar las APIs públicas).
• Agente de Verificación: Analiza el candidato generado contra configuraciones de comprobación de evidencia antes de que sea retenido.

3. Traza de Verificación y Análisis

REFINE no trata la salida del LLM como algo final. En su lugar, reanaliza el archivo transformado para calcular:

• Reducción de Smells: Mejoras absolutas ($\Delta_{smell} = B - A$) y relativas en los code smells detectados.
• Proxies de Preservación Estática: Comprobaciones de preservación de API pública, manejo de excepciones, contratos de framework, lógica condicional y llamadas críticas de assert/fail.
• Diagnóstico de Fallos: Registra razones específicas de rechazo (por ejemplo, eliminación de métodos públicos).
• Trazabilidad: Persiste el código fuente original, el candidato generado, los pasos de los agentes, las métricas y los resultados de la verificación para vincular cada decisión con su evidencia.

Diseño Experimental

• Dataset: 450 archivos Java de 15 sistemas de código abierto (ej. JHotDraw, Apache Ant, Guava, JabRef), seleccionados mediante muestreo aleatorio estratificado basado en el recuento de code smells y Líneas de Código (LOC).
• Configuraciones de LLM: Se evaluaron tres modelos de vanguardia: OpenAI GPT-5.5, Google Gemini 3.1 Pro Preview y Anthropic Claude Opus 4.8.
• Escala: Esto resultó en 1,350 salidas de paso de modelo.
• Línea Base: Se realizó una línea base de prompting directo emparejado sobre un subconjunto de 150 archivos para comparar el flujo de trabajo de múltiples agentes contra el prompting simple.
• Métricas: Reducción de code smells, indicadores de calidad (Complejidad Ciclomática, Índice de Mantenibilidad, etc.), cambios estructurales y riesgos de preservación.

Resultados Clave

1. Reducción de Code Smells (RQ1)

REFINE logró reducciones sustanciales en los code smells detectados en las tres configuraciones de LLM:

• Reducción Total: 68.26% (GPT-5.5), 72.79% (Gemini 3.1) y 68.49% (Opus 4.8).
• Smells Mayores: Las mejoras más significativas se dieron en los smells mayores (reducción del 86.51% al 91.60%).
• Indicadores de Calidad: Las mejoras en métricas de calidad más amplias no fueron uniformes. Mientras que Gemini 3.1 mostró reducciones significativas en la Complejidad Ciclomática y LCOM, otras métricas (Mantenibilidad, Testabilidad, esfuerzo de Halstead) mostraron cambios mixtos o adversos dependiendo del modelo.

2. Preservación y Riesgos (RQ2)

• Altas Tasas de Aprobación: La mayoría de los indicadores de preservación estática (firmas de métodos públicos, manejo de excepciones, contratos de framework) pasaron con altas tasas (81.8% a 94.2%).
• Riesgos Críticos:
  • Llamadas Assert/Fail: Solo el 57.1% de las salidas preservaron las llamadas críticas de assert/fail entre todos los modelos, lo que indica un riesgo sistémico.
  • Eliminación de Métodos Públicos: Esta fue la falla de diagnóstico más concreta. Gemini 3.1 exhibió la mayor tasa de eliminación de métodos públicos (71 casos), seguido de GPT-5.5 (41) y Opus 4.8 (34).

3. Comportamiento de Refactorización (RQ3)

Diferentes modelos lograron la reducción de smells mediante perfiles de edición distintos:

• GPT-5.5: Produjo las ediciones más compactas.
• Gemini 3.1: Exhibió un perfil "pesado en eliminaciones", eliminando la mayor cantidad de líneas y métodos.
• Opus 4.8: Mostró un perfil "pesado en extracciones" con el mayor número de extracciones de métodos.
• Correlación: Los volúmenes de edición más grandes se correlacionaron con una mayor reducción absoluta de smells, pero no necesariamente con una mayor reducción relativa.

4. Comparación con el Prompting Directo

En el subconjunto emparejado de 150 archivos, REFINE superó al prompting directo en:

• Reducción de Smells: Reducción total mediana de 100.0% (REFINE) frente a 20.8% (Prompting Directo).
• Huella de Edición: Menor cambio (churn) mediano (14 LOC frente a 65 LOC).
• Seguridad de la API: Menos eliminaciones de métodos públicos (46 casos frente a 112).
• Compromiso (Trade-off): El prompting directo preservó las construcciones críticas de assert/fail con mayor frecuencia (100% frente a 58%).

Significancia y Reivindicaciones

El artículo posiciona a REFINE no como un reemplazo para las herramientas de refactorización que preservan el comportamiento, sino como un mecanismo trazable y consciente de la evidencia para generar y evaluar candidatos de refactorización.

• Conciencia de la Evidencia: La contribución principal es vincular el código generado con la evidencia estática específica (smells) que motivó el cambio y las comprobaciones de verificación que aprobó o falló.
• Generación Controlada: El flujo de trabajo de múltiples agentes proporciona una generación de candidatos más controlada que el prompting directo, resultando en ediciones más pequeñas y menos eliminaciones accidentales de APIs, aunque no elimina todos los riesgos de comportamiento.
• Limitaciones: Los autores declaran explícitamente que los resultados generados son candidatos, no refactorizaciones listas para producción. Las comprobaciones de preservación estática son proxies y no prueban la equivalencia de comportamiento.
• Implicación Práctica: Los candidatos generados requieren compilación, pruebas, análisis de dependencias y revisión humana antes de su adopción, particularmente en entornos con muchas dependencias o de nivel de sistema.

El estudio concluye que, si bien los flujos de trabajo de múltiples agentes conscientes de la evidencia son prometedores para la mitigación dirigida de code smells a nivel de archivo, ni el prompting directo ni el enfoque de múltiples agentes proporcionan actualmente evidencia suficiente de la preservación total del comportamiento para operar de forma autónoma en ecosistemas de software complejos.