Byam: Fixing Breaking Dependency Updates with Large Language Models

1. O Problema: Atualizações de Dependências que Quebram o Código

O desenvolvimento de software moderno depende fortemente de bibliotecas de terceiros. No entanto, quando essas bibliotecas são atualizadas, as mudanças em suas APIs (como remoção de métodos, alteração de assinaturas, mudanças de tipos de parâmetros ou substituição completa) podem introduzir atualizações de dependência que quebram o código (breaking dependency updates).

• Impacto: Essas alterações impedem que o projeto do cliente compile ou execute, gerando erros de compilação.
• Desafio: Identificar a causa raiz e atualizar manualmente o código do cliente é uma tarefa tediosa, demorada e propensa a erros, muitas vezes desencorajando os desenvolvedores a manterem suas dependências atualizadas (o que é crucial para segurança).
• Limitações de Abordagens Anteriores: Soluções existentes baseiam-se em regras pré-definidas, heurísticas de análise estática ou exemplos minerados, o que limita sua capacidade de lidar com a diversidade de atualizações do mundo real e o contexto específico de cada projeto.

2. Metodologia: A Abordagem Byam

Os autores propõem o Byam, um pipeline automatizado que utiliza Modelos de Linguagem Grandes (LLMs) para gerar correções de código para projetos que falharam na compilação devido a atualizações de dependência.

O processo do Byam ocorre em três etapas principais:

1. Extração de Informações da Build Falha:

   • O sistema analisa os logs de compilação para identificar os arquivos com erros e as mensagens de erro específicas.
   • Localiza a linha exata do código que causou o erro.
   • Realiza uma Análise de Diferença de API (APIDiff) entre a versão antiga e a nova da dependência (usando a ferramenta japicmp) para identificar quais métodos foram removidos, alterados ou adicionados.

2. Geração de Correções via LLM (Prompt Engineering):

   • O Byam formula prompts (instruções) ricos em contexto para consultar o LLM.
   • O estudo avalia oito configurações de prompt, combinando diferentes elementos:
     • Linha Errônea: Incluir a linha de código específica que falhou.
     • Diferenças de API (APIDiff): Fornecer detalhes estruturais sobre o que mudou na biblioteca.
     • Cadeia de Pensamento (Chain of Thought - CoT): Instruir o modelo a raciocinar passo a passo (identificar a mudança, comparar versões, planejar a correção) antes de gerar o código.
   • O objetivo é guiar o LLM para atuar como um assistente de reparo consciente do contexto.

3. Validação e Rebuild:

   • O código gerado pelo LLM é aplicado ao projeto original.
   • O projeto é reconstruído e os testes são executados para verificar se a compilação foi bem-sucedida e se não foram introduzidos novos erros ou falhas de teste.

3. Configuração Experimental

• Dataset: Utilização do BUMP, um benchmark com 103 casos reais de atualizações de dependência que quebram a compilação em projetos Java (filtrados de um conjunto maior de 571 atualizações).
• Modelos de LLM Testados: Cinco modelos variados (proprietários e open-source):
  • Google Gemini-2.0 Flash
  • OpenAI GPT-4o-mini
  • OpenAI o3-mini
  • Alibaba Qwen2.5-32b-instruct
  • DeepSeek V3
• Métricas de Avaliação:
  • Taxa de Sucesso da Build (BSR): Projetos que compilam e passam nos testes após a correção.
  • Taxa de Sucesso de Correção de Arquivos (FFSR): Porcentagem de arquivos com erros que foram corrigidos.
  • Taxa de Correção de Erros de Compilação (CEFR): Porcentagem de erros individuais corrigidos.
  • Razão Relativa de Erros Corrigidos (REF): Mede o equilíbrio entre erros resolvidos e novos erros introduzidos pelo LLM.

4. Resultados Principais

Os resultados demonstram que os LLMs têm um potencial significativo para automatizar esse tipo de reparo:

• Melhor Desempenho Geral: O modelo OpenAI o3-mini obteve os melhores resultados em todas as métricas.
  • Sucesso Total (Build Level): O o3-mini com o prompt mais rico (P8: CoT + Linha Errônea + APIDiff) conseguiu reparar completamente 27% das builds falhas (28 de 103).
  • Correção Parcial (File Level): Mesmo quando a build não foi totalmente reparada, o o3-mini corrigiu 41% dos arquivos com erros.
  • Correção de Erros Individuais: O modelo corrigiu 78% dos erros de compilação individuais, mesmo em builds que ainda falharam no final.
• Impacto do Prompting:
  • A inclusão de APIDiff e Linha Errônea melhorou consistentemente o desempenho da maioria dos modelos.
  • A técnica de Cadeia de Pensamento (CoT) foi benéfica principalmente para modelos com forte capacidade de raciocínio (como o o3-mini), mas teve efeito variável ou negativo em modelos menores (como o Gemini-2.0 Flash em certas configurações).
• Introdução de Novos Erros: O o3-mini introduziu o menor número de novos erros, mantendo uma alta Razão Relativa de Erros Corrigidos (REF), indicando que as correções são seguras e não degradam o código.
• Modelos Open Source: O Qwen2.5-32b-instruct teve o desempenho mais baixo, sugerindo que modelos menores podem ter dificuldade em lidar com a complexidade e o contexto necessário para essas tarefas específicas.

5. Contribuições e Significância

• Contribuição Técnica: Proposta do Byam, uma abordagem que integra análise de diferenças de API e raciocínio estruturado (CoT) diretamente no prompt do LLM para reparo de dependências.
• Evidência Empírica: Estudo em larga escala comparando cinco modelos de ponta em um benchmark realista, demonstrando que a capacidade intrínseca do modelo combinada com o contexto correto supera abordagens puramente baseadas em agentes iterativos ou zero-shot.
• Significância Prática:
  • Redução de Esforço: A capacidade de corrigir automaticamente a maioria dos erros de compilação (mesmo que não resolva 100% da build) reduz drasticamente o tempo que os desenvolvedores gastam em manutenção.
  • Segurança: Facilita a adoção de atualizações de dependências, permitindo que projetos se mantenham atualizados contra vulnerabilidades de segurança.
  • Integração Futura: O trabalho sugere que ferramentas como o Byam podem ser integradas a bots de Pull Request (como Dependabot) para criar um fluxo de trabalho de atualização de dependências totalmente automatizado.

Em resumo, o artigo prova que, com a engenharia de prompts adequada e o uso de modelos de raciocínio avançados, é possível automatizar a resolução de uma das tarefas mais dolorosas na manutenção de software: a adaptação de código a mudanças quebradiças em bibliotecas externas.