Resumo Técnico: Adicionar é Máquina, Deletar é Humano

Declaração do Problema

Embora os Grandes Modelos de Linguagem (LLMs) funcionem cada vez mais como agentes de codificação capazes de resolver problemas e gerar pull requests, evidências sugerem que seus patches frequentemente degradam a manutenibilidade do código. Um modo de falha específico e sistemático identificado neste trabalho é a evitação de deleção: a tendência dos modelos de reter código que uma edição pretendida deveria remover. Em vez de realizar uma edição subtrativa, os modelos frequentemente preservam a lógica obsoleta e roteiam a execução ao redor dela usando guardas condicionais ou fallbacks. Esse comportamento, denominado Guard-and-Go (Proteger e Seguir), permite que os patches passem nas suítes de testes existentes (que raramente verificam a remoção de código), enquanto deixa as bases de código inchadas e mais difíceis de manter. O artigo postula que os benchmarks atuais, como o SWE-bench Verified, podem superestimar a prontidão dos modelos para produção porque falham em penalizar essas estratégias de não-remoção.

Metodologia

O estudo emprega uma abordagem multifacetada combinando análise empírica de benchmarks existentes, a criação de um benchmark de diagnóstico especializado e uma intervenção de pós-treinamento controlada.

1. Análise Empírica do SWE-bench Verified

Os autores analisaram as cinco principais submissões ao leaderboard do SWE-bench Verified (GLM-4.6, GPT-5, Kimi-K2, Opus-4.5 e Salesforce SAGE) usando um scaffold OpenHands consistente para controlar a variação do agente.

• Métrica: A recall de deleção foi calculada comparando os patches do modelo com os patches de desenvolvedores, medindo a parcela das linhas deletadas pelo desenvolvedor que o modelo também removeu.
• Verificação de Localização: O estudo distinguiu entre falhar em encontrar o código (erro de localização) e falhar em removê-lo (erro de execução) ao verificar arquivo, escopo (função/classe/módulo) e a modificação exata da linha.
• Classificação de Estratégia: Um classificador baseado em LLM categorizou os patches aprovados em "Delete-and-Replace" (Deletar e Substituir), "Guard-and-Go" (reter a lógica com uma guarda) ou "Non-reference alternative" (alternativa sem referência).

2. Retrofit de Sensibilidade à Deleção

Para determinar se os testes aprovados realmente validam a remoção de código, os autores realizaram o retrofit de 34 tarefas com alta densidade de deleção do SWE-bench Verified com novos testes FAIL_TO_PASS (F2P). Esses testes falham explicitamente se o código alvo permanecer no arquivo, isolando o requisito de remoção de outras especificações comportamentais.

3. Benchmark CanItDelete

Para isolar o comportamento de deleção de fatores de confusão como dificuldade de localização ou a necessidade de código aditivo, os autores curaram o CanItDelete.

• Construção: 200 tarefas mineradas de commits reais onde a totalidade da edição necessária era deleção (sem adições). As tarefas foram selecionadas dos 100 repositórios Python e JavaScript mais estrelados, classificados por complexidade estrutural (tamanho pré-edição, linhas deletadas e blocos de deleção).
• Avaliação: Um avaliador determinístico e consciente de ocorrências pontua as saídas com base em se o alvo está totalmente ausente, se a estrutura não relacionada foi preservada e se nenhuma adição que afete o comportamento foi introduzida.
• Escada de Diagnóstico: O benchmark utiliza quatro modos cumulativos para diagnosticar pontos de falha:
  1. Vanilla: Solicitação padrão no estilo de desenvolvedor.
  2. Explicit Deletion: A instrução proíbe guardas ou fallbacks.
  3. Region Pointer: Identifica funções/regiões relevantes.
  4. Exact Lines: Fornece os intervalos exatos para remover.

4. Intervenção de Pós-Treinamento (Prova de Conceito)

Um modelo de 7 bilhões de parâmetros foi aumentado com uma mistura de pós-treinamento focada em deleção.

• Dados: 12.821 exemplos de deleção (10.000 de nível de arquivo e 2.821 de nível de repositório) foram adicionados ao conjunto de treinamento. Esses exemplos contribuíram com 112,1 milhões de tokens para a mistura de 15,9 bilhões de tokens, constituindo aproximadamente 0,7% do total de tokens.
• Avaliação: O modelo foi testado no CanItDelete, SWE-bench Verified, CanItEdit e EditBench para medir a melhoria direcionada e possíveis regressões.

Principais Resultados

1. Prevalência de Evitação de Deleção

• Baixa Recall: Mesmo nos 197 tarefas resolvidas por todos os cinco modelos, a recall de deleção variou de 65,2% a 71,7%. Os modelos deixaram entre 28,3% e 34,8% das deleções necessárias no lugar.
• Localização vs. Execução: Os modelos localizaram com sucesso o arquivo correto para >92% das deleções e o escopo envolvente para ~70%, mas removeram a linha exata em apenas 44,6% a 51,6% dos casos. A lacuna é primariamente uma falha de execução, não de localização.
• Dominância do Guard-and-Go: Entre os 1.703 pares de tarefa-modelo aprovados analisados, 494 (29,0%) seguiram o padrão Guard-and-Go, onde o modelo retém a lógica removida pelo desenvolvedor e adiciona um bypass condicional. Esses patches foram, em média, 61,1% maiores que o patch do desenvolvedor.

2. Lacuna de Avaliação

Quando 34 tarefas com alta densidade de deleção foram reavaliadas com verificações sensíveis à deleção:

• As taxas de resolução de quatro modelos de fronteira caíram de 63,2% para 41,9% (uma queda de 21,3 pontos percentuais).
• 33,7% dos patches que passaram nas suítes de testes originais retiveram o alvo de deleção validado.

3. Descobertas do CanItDelete

• Variância de Desempenho: Nos 200 tarefas de apenas deleção, as taxas de sucesso variaram de 79,0% (Claude Opus 4.8) até 18,0% (modelos abertos menores).
• Modos de Falha: A deleção incompleta (deixar o código necessário) representou 69,8% das falhas entre os modelos. No entanto, conforme os modelos melhoraram na localização de alvos, um segundo modo de falha surgiu: over-deletion (deleção excessiva — remover código além do limite alvo).
• Impacto da Orientação: Fornecer intervalos de deleção exatos (o modo "Exact lines") quase eliminou a deleção incompleta para quatro de cinco modelos, mas não corrigiu a deleção excessiva. Por exemplo, o sucesso do GPT-5.6 Sol subiu para 80,5%, mas ele ainda falhou em 16,5% das tarefas por deletar além dos intervalos especificados. Isso indica uma falta de controle sobre o limite da deleção, em vez de uma falta de capacidade de encontrar o código.

4. Intervenção de Pós-Treinamento

Adicionar supervisão de deleção à mistura de pós-treinamento do modelo de 7B:

• Reduziu a deleção incompleta no CanItDelete em 13,9 pontos percentuais (de uma taxa de falha de 80,4% para 66,5%).
• Melhorou o SWE-bench Verified em 5,3 pontos e o CanItEdit em 1,4 pontos.
• Não introduziu regressões significativas em outros benchmarks.
• Trade-off: A intervenção aumentou a taxa de over-deletion (deleção completa com edições inválidas), sugerindo que, embora o modelo tenha aprendido a deletar, ele ainda tem dificuldade com onde parar.

Significância e Alegações

O artigo alega que a evitação de deleção é um comportamento sistemático e subtreinado nos LLMs atuais, em vez de uma limitação intrínseca. Os autores argumentam que:

1. Os Benchmarks Atuais são Insuficientes: As métricas padrão de passagem de testes mascaram o padrão "Guard-and-Go", levando a uma superestimação da prontidão do modelo para manutenção de código.
2. O Controle é o Gargalo: Os modelos possuem a capacidade de localizar o código a ser deletado, mas carecem de controle para executar remoções precisas e delimitadas sem edições excessivas ou adição de guardas.
3. Deleção é Aprendível: A prova de conceito da intervenção demonstra que o pós-treinamento direcionado pode reduzir a evitação de deleção e melhorar o desempenho geral de edição de código, sugerindo que o déficit se deve à representação de dados (viés aditivo nos dados de treinamento) e não à arquitetura do modelo.

Os autores mantêm a modéstia quanto ao escopo, observando que a intervenção foi testada em um único modelo de 7B e que o trade-off de "over-deletion" indica que a conclusão da deleção e o controle de limites são objetivos de treinamento distintos que requerem mais pesquisas para serem resolvidos simultaneamente em escala.