Writing Bug Reports for Software Repair Agents: What Information Matters Most?

Resumo Técnico: Escrita de Relatórios de Erros para Agentes de Reparo de Software

Declaração do Problema
Os fluxos de trabalho de desenvolvimento de software estão adotando cada vez mais abordagens "agentic-first" (prioridade para agentes), onde agentes de IA recebem relatórios de problemas para gerar correções iniciais antes da revisão humana. Neste paradigma, os relatórios de erros deixam de ser documentação para mantenedores humanos e passam a servir como a especificação de tarefa primária para agentes automatizados. No entanto, permanece incerto quais tipos específicos de informação dentro dos relatórios de erros são mais eficazes para permitir que os agentes produzam patches corretos. Benchmarks existentes, como o SWE-bench Verified, contêm problemas com conteúdo de informação altamente variável, tornando difícil distinguir se o sucesso do agente advém da capacidade de raciocínio do modelo ou da riqueza da descrição do erro. Este estudo investiga o que constitui um relatório de erro "pronto para o agente", analisando especificamente quais tipos de informação se correlacionam com o reparo automatizado bem-sucedido.

Metodologia
Os autores conduziram um estudo empírico utilizando o benchmark SWE-bench Verified, que compreende 500 problemas reais do GitHub pareados com patches de ouro (gold patches) e suítes de teste.

1. Curadoria de Dados: Dos 500 problemas, 441 foram classificados como relatórios de erros (excluindo solicitações de recursos e refatorações).
2. Anotação: Dois autores anotaram manualmente o texto desses 441 relatórios ao nível de caractere usando uma taxonomia derivada da literatura existente. A taxonomia incluiu nove tipos de informação: Resumo, Comportamento Observado, Comportamento Esperado, Referências, Passos de Reprodução, Ambiente, Área Afetada (pistas de localização em níveis de linha, função, arquivo ou genérico), Sugestões de Correção (em código ou linguagem natural) e Contornos Atuais (Workarounds). A concordância entre anotadores foi moderada ($\kappa = 0,57$), com conflitos resolvidos por um terceiro autor.
3. Execução do Agente: O estudo utilizou o mini-swe-agent, uma arquitetura de agente que interage com repositórios via comandos bash. Este agente foi executado nos 441 relatórios de erros usando três backbones de Grandes Modelos de Linguagem (LLMs) distintos: GPT-5-mini, MiniMax M2.5 e Gemini 3 Flash. Cada problema foi executado três vezes por modelo para considerar a estocasticidade, resultando em 3.969 observações totais.
4. Análise Estatística:
   • Estudo Observacional: Um modelo de regressão binomial de efeitos mistos foi ajustado para estimar a associação entre a presença de tipos de informação específicos e o sucesso do agente (passar na suíte de testes). O modelo controlou o comprimento do problema, o tamanho do patch de ouro, a dificuldade, menções ao código e efeitos aleatórios do repositório.
   • Estudo de Ablação: Para isolar o impacto causal dos tipos de informação, os autores selecionaram 65 problemas "completos em informação" (contendo todas as macrocategorias). Eles geraram variantes removendo sistematicamente tipos de informação específicos (por exemplo, removendo pistas de localização, removendo sugestões de correção, ou removendo ambos) e reexecutaram os agentes. Isso permitiu uma avaliação controlada de como a ausência de pontos de dados específicos afeta o desempenho.

Principais Contribuições

1. Conceitualização: O artigo introduz a noção de "relatórios de erro agentic-first", distinguindo-os dos relatórios tradicionais orientados a humanos ao focar em informações que operacionalizam a tarefa de reparo.
2. Anotação: Fornece um conjunto de dados anotado ao nível de caractere dos problemas do SWE-bench Verified, categorizando o conteúdo em tipos comportamentais, ambientais, de localização e de sugestão de reparo.
3. Evidência Empírica: Oferece a primeira análise empírica em larga escala da relação entre o conteúdo do relatório de erro e o sucesso de agentes baseados em LLM através de múltiplos backbones de modelos.
4. Orientação: Fornece recomendações baseadas em evidências para estruturar relatórios de erros para maximizar a eficácia do agente.

Principais Resultados

• Localização e Sugestões de Correção são Críticas: As associações positivas mais fortes com o sucesso do agente foram encontradas para pistas de localização (referências a linhas, funções ou arquivos afetados) e sugestões de correção (tanto em código quanto em linguagem natural). As sugestões de correção em linguagem natural mostraram a maior razão de chances (OR = 2,01) no modelo agrupado.
• Informação Centrada no Humano é Menos Decisiva: Contrariamente às diretrizes tradicionais de reporte de bugs, os tipos de informação cruciais para o debug humano — como passos de reprodução, comportamento esperado e comportamento observado — mostraram associações mais fracas ou não significativas com o sucesso do agente no estudo observacional. O estudo de ablação confirmou que remover esses componentes não degradou significativamente o desempenho se as pistas operacionais (localização/sugestões) permanecessem.
• O Hiato "Operacional": O estudo de ablação revelou que a degradação mais significativa no desempenho do agente ocorreu apenas quando ambas as pistas de localização e sugestões de correção foram removidas simultaneamente (OR = 0,60). Isso sugere que os agentes requerem pelo menos uma "direção de reparo" clara (seja onde procurar ou como corrigir).
• Especificidade do Modelo: Embora as sugestões de correção em linguagem natural fossem robustamente úteis para todos os três LLMs, outros tipos de informação mostraram dependências específicas do modelo. Por exemplo, o GPT-5-mini beneficiou-se da localização em todos os níveis de granularidade, enquanto o Gemini Flash 3 e o MiniMax M2.5 beneficiaram-se principalmente de pistas de granularidade mais fina.
• Correlações Negativas: Descrições de erros mais longas e tamanhos de patch de ouro maiores foram negativamente associados ao sucesso, sugerindo que a verbosidade pode introduzir ruído ou que os agentes lutam com correções inerentemente complexas, independentemente da qualidade do relatório. Referências a recursos externos também foram negativamente associadas, provavelmente porque os agentes não conseguem inferir a relevância de links externos de forma eficaz sem uma sumarização explícita.

Significância e Implicações
O artigo argumenta que o desenvolvimento agentic-first exige uma mudança na forma como os relatórios de erro são escritos. Os relatórios devem ser tratados menos como narrativas exaustivas para compreensão humana e mais como especificações de reparo que estreitam explicitamente o espaço de busca e reparo do agente.

• Design de Templates: Os templates de problemas devem priorizar informações acionáveis (localização e hipóteses de reparo) sobre o contexto descritivo.
• Evolução do Fluxo de Trabalho: Como informações críticas como a localização frequentemente emergem durante a discussão, os autores sugerem que os fluxos de trabalho de agentes devem ser incrementais. Os rastreadores de problemas poderiam suportar a reexecução de agentes quando novos comentários acionáveis (ex: "Suspeito que o bug está em file.py") são adicionados, em vez de disparar uma tentativa única imediatamente após a criação do problema.
• Arquitetura de Sistema: As descobertas apoiam o design de sistemas de agentes de múltiplos estágios, onde um componente dedicado de localização identifica regiões de código suspeitas antes que um agente de reparo tente a geração do patch.

Os autores concluem que, embora a qualidade tradicional do relatório de erro permaneça importante para mantenedores humanos, a "prontidão para o agente" é definida pela presença de informações que operacionalizam o conserto, especificamente ao expor uma direção de reparo plausível.