Resumo Técnico: REFINE – Uma Abordagem de LLM Multi-Agente para Refatoração de Código Guiada por Evidências

Declaração do Problema

Embora os Grandes Modelos de Linguagem (LLMs) demonstrem fortes capacidades em geração e transformação de código, sua aplicação à refatoração de software enfrenta desafios significativos. Uma refatoração eficaz exige não apenas modificar o código para reduzir problemas de qualidade (code smells), mas também garantir que as mudanças não introduzam novos defeitos, alterem o comportamento externo ou removam elementos estruturais críticos (ex: APIs públicas, asserções).

As abordagens atuais de refatoração assistida por LLM carecem frequentemente de verificação rigorosa, levando a riscos como sugestões alucinadas, transformações inconsistentes e a remoção de estruturas de código relevantes ao comportamento. Há uma necessidade de uma abordagem sistemática que:

1. Guie os LLMs com evidências provenientes de análise estática.
2. Orquestre um fluxo de trabalho multi-agente para planejar, gerar e verificar mudanças.
3. Forneça evidência rastreável do que foi alterado, quais riscos permanecem e se o output é um candidato viável de refatoração em vez de uma solução aceita automaticamente.

Metodologia: O Fluxo de Trabalho REFINE

Os autores introduzem o REFINE (Refactoring with Evidence-aware Flow for Integrated ageNtic Execution), um framework multi-agente agnóstico a ferramentas e consciente de evidências, projetado para refatoração de nível de arquivo em Java. O sistema é implementado como um protótipo de pesquisa usando uma interface Next.js, um backend Java Spring Boot (para análise estática via PMD 7.x) e um serviço de agente Python (usando LangGraph v1.1) para orquestração.

O fluxo de trabalho opera através de três estágios primários:

1. Caracterização da Tarefa

• Entrada: Um único arquivo Java de um projeto de código aberto.
• Coleta de Evidências: A análise estática (PMD) identifica code smells de nível de arquivo e evidências de nível de regra.
• Contextualização: O sistema extrai assinaturas de API pública, contexto do workspace e prioriza os smells detectados para formar uma tarefa de refatoração delimitada.

2. Orquestração da Refatoração

O fluxo de trabalho coordena onze papéis distintos (agentes) para gerenciar o processo:

• Agente de Planejamento (Planning Agent): Combina orientação determinística baseada em regras com refinamento opcional por LLM para criar um plano de refatoração orientado a smells.
• Agente de Refatoração (Refactoring Agent): Invoca um LLM para gerar uma transformação candidata baseada no plano, no código original e nas restrições (ex: preservar APIs públicas).
• Agente de Verificação (Verification Agent): Analisa o candidato gerado contra verificações de evidência configuradas antes que ele seja retido.

3. Rastro de Verificação e Análise

O REFINE não trata o output do LLM como final. Em vez disso, ele reanalisa o arquivo transformado para computar:

• Redução de Smell: Absoluta ($\Delta_{smell} = B - A$) e melhorias relativas nos code smells detectados.
• Proxies de Preservação Estática: Verificações para preservação de API pública, tratamento de exceções, contratos de framework, lógica condicional e chamadas críticas de assert/fail.
• Diagnósticos de Falha: Registra razões específicas de rejeição (ex: remoção de método público).
• Rastreabilidade: Persiste o código fonte original, o candidato gerado, as etapas dos agentes, métricas e resultados de verificação para vincular cada decisão à sua evidência.

Design Experimental

• Dataset: 450 arquivos Java de 15 sistemas de código aberto (ex: JHotDraw, Apache Ant, Guava, JabRef), selecionados via amostragem aleatória estratificada baseada na contagem de code smells e Linhas de Código (LOC).
• Configurações de LLM: Três modelos de fronteira foram avaliados: OpenAI GPT-5.5, Google Gemini 3.1 Pro Preview e Anthropic Claude Opus 4.8.
• Escala: Isso resultou em 1.350 outputs de passagens de modelo.
• Baseline: Um baseline de prompting direto pareado foi conduzido em um subconjunto de 150 arquivos para comparar o fluxo de trabalho multi-agente contra o prompting simples.
• Métricas: Redução de code smell, indicadores de qualidade (Complexidade Ciclomática, Índice de Manutenibilidade, etc.), mudanças estruturais e riscos de preservação.

Principais Resultados

1. Redução de Code Smell (RQ1)

O REFINE alcançou reduções substanciais nos code smells detectados em todas as três configurações de LLM:

• Redução Total: 68,26% (GPT-5.5), 72,79% (Gemini 3.1) e 68,49% (Opus 4.8).
• Major Smells: As melhorias mais significativas ocorreram nos major code smells (redução de 86,51% a 91,60%).
• Indicadores de Qualidade: As melhorias em métricas de qualidade mais amplas não foram uniformes. Enquanto o Gemini 3.1 mostrou reduções significativas na Complexidade Ciclomática e LCOM, outras métricas (Manutenibilidade, Testabilidade, esforço de Halstead) mostraram mudanças mistas ou adversas dependendo do modelo.

2. Preservação e Riscos (RQ2)

• Altas Taxas de Aprovação: A maioria dos indicadores de preservação estática (assinaturas de métodos públicos, tratamento de exceções, contratos de framework) passou com altas taxas (81,8% a 94,2%).
• Riscos Críticos:
  • Chamadas de Assert/Fail: Apenas 57,1% dos outputs preservaram chamadas críticas de assert/fail entre todos os modelos, indicando um risco sistêmico.
  • Remoção de Método Público: Esta foi a falha de diagnóstico mais concreta. O Gemini 3.1 exibiu a maior taxa de remoção de método público (71 casos), seguido por GPT-5.5 (41) e Opus 4.8 (34).

3. Comportamento de Refatoração (RQ3)

Diferentes modelos alcançaram redução de smell através de perfis de edição distintos:

• GPT-5.5: Produziu as edições mais compactas.
• Gemini 3.1: Exibiu um perfil "pesado em deleções", removendo o maior número de linhas e métodos.
• Opus 4.8: Mostrou um perfil "pesado em extrações" com o maior número de extrações de métodos.
• Correlação: Volumes maiores de edição correlacionaram-se com maior redução absoluta de smell, mas não necessariamente com maior redução relativa.

4. Comparação com Prompting Direto

No subconjunto pareado de 150 arquivos, o REFINE superou o prompting direto em:

• Redução de Smell: Mediana de redução total de 100,0% (REFINE) vs. 20,8% (Prompt Direto).
• Pegada de Edição (Edit Footprint): Menor mediana de churn (14 LOC vs. 65 LOC).
• Segurança de API: Menos remoções de métodos públicos (46 casos vs. 112).
• Trade-off: O prompting direto preservou constructos de assert/fail com mais frequência (100% vs. 58%).

Significância e Alegações

O artigo posiciona o REFINE não como um substituto para ferramentas de refatoração que preservam o comportamento, mas como um mecanismo rastreável e consciente de evidências para gerar e avaliar candidatos à refatoração.

• Consciência de Evidência: A principal contribuição é vincular o código gerado à evidência estática específica (smells) que motivou a mudança e às verificações de evidência que ele passou ou falhou.
• Geração Controlada: O fluxo de trabalho multi-agente fornece uma geração de candidatos mais controlada do que o prompting direto, resultando em edições menores e menos remoções acidentais de API, embora não elimine todos os riscos comportamentais.
• Limitações: Os autores afirmam explicitamente que os outputs gerados são candidatos, não refatorações prontas para produção. As verificações de preservação estática são proxies e não provam equivalência comportamental.
• Implicação Prática: Os candidatos gerados requerem compilação, testes, análise de dependências e revisão humana antes da adoção, particularmente em ambientes dependentes de dependências ou de nível de sistema.

O estudo conclui que, embora fluxos de trabalho multi-agentes conscientes de evidências sejam promissores para a mitigação direcionada de code smells em nível de arquivo, nem o prompting direto nem a abordagem multi-agente fornecem atualmente evidência suficiente de preservação total do comportamento para operar autonomamente em ecossistemas de software complexos.