A Crise da Manutenção: Por Que Agentes de IA Que Corrigem Bugs Criam Mais Bugs

Um agente de IA recebe um bug report. Analisa o código. Gera um patch. Os testes passam. O PR é mergeado.

Três semanas depois, o patch quebra outra coisa. O agente recebe o novo bug report. Gera outro patch. Os testes passam de novo. O PR é mergeado de novo.

Ninguém conecta os dois eventos. O segundo bug não parece ter relação com o primeiro. Mas tem. E o terceiro, que virá em seis semanas, também terá.

O Problema do Retrato Único

A maioria dos benchmarks de agentes de codificação funciona assim: entrega uma tarefa, mede se o agente resolve, registra o score. O SWE-bench, o mais citado, avalia tarefas isoladas extraídas de repositórios reais. Uma tarefa, uma tentativa, um resultado.

Esse formato captura competência pontual. O agente consegue ler código, entender um problema descrito em linguagem natural e gerar um fix funcional? Sim, muitas vezes consegue. Os scores melhoram a cada geração de modelo.

O que esse formato não captura é o que acontece depois. O fix introduziu uma regressão sutil? O código ficou mais difícil de manter? O padrão arquitetural se degradou de maneira invisível aos testes automatizados?

Para responder essas perguntas, você precisa de tempo. E benchmarks pontuais, por definição, não têm tempo.

SWE-CI: A Primeira Medição Longitudinal

Em março de 2026, pesquisadores publicaram o SWE-CI (arXiv 2603.03823v1), o primeiro benchmark projetado para medir manutenção contínua, não resolução pontual.

A estrutura é simples na descrição e brutal nos resultados. Os pesquisadores coletaram 100 tarefas de 68 repositórios Python, cada tarefa cobrindo uma média de 233 dias de evolução do código. Testaram 18 modelos de 8 provedores diferentes. Consumiram mais de 10 bilhões de tokens no processo.

A métrica central é a taxa de zero-regressão: das correções que o agente aplica, quantas não quebram nada ao longo do tempo?

O resultado: a maioria dos modelos ficou abaixo de 0,25. Traduzindo, mais de 75% das correções introduziram pelo menos uma regressão em iterações subsequentes. O agente resolve o bug de hoje e planta o bug de amanhã.

Apenas um modelo (Claude Opus) ultrapassou 50% de taxa de zero-regressão. E mesmo esse número significa que metade das correções eventualmente causou problemas. O melhor cenário atual ainda implica que cada duas correções geram, em média, uma regressão futura.

Por Que Agentes Regridem

A explicação não é misteriosa, embora seja inconveniente para quem vende automação de código.

Agentes de codificação operam sobre snapshots. Recebem o estado atual do repositório, o bug report, e talvez algum contexto de testes. Geram um patch que satisfaz as restrições visíveis naquele instante. Não carregam memória de patches anteriores. Não entendem a trajetória do código. Não reconhecem que a correção que estão propondo conflita com uma correção que eles mesmos fizeram três meses atrás.

Como já exploramos em A Dívida de Verificação, existe uma distância estrutural entre produzir código que passa nos testes e produzir código que é correto ao longo do tempo. O SWE-CI transforma essa intuição em dado empírico.

O problema se agrava em código real porque repositórios acumulam decisões implícitas. Uma variável nomeada de certa forma, um padrão de error handling específico, uma convenção de módulo que ninguém documentou mas todos seguem. Desenvolvedores humanos absorvem essas convenções por osmose. Agentes não. Cada intervenção é, cognitivamente, a primeira.

Bugattis de Argila

O programador e ensaísta Chris Trottier cunhou uma imagem que captura esse fenômeno com precisão: “Bugattis de argila.” Software que, visto de fora, parece uma obra de engenharia. Por dentro, não tem estrutura. Visualmente indistinguível. Funcionalmente frágil.

A IA, argumenta Trottier, tornou “dramaticamente mais barato produzir software que parece funcionar.” A palavra operativa é “parece.” Os testes passam. O demo roda. O deploy funciona na terça-feira. Na quinta, algo quebra de um jeito que ninguém consegue explicar sem ler 400 linhas de diff.

É tentador descartar isso como pessimismo. Mas o SWE-CI coloca números na intuição: 75% de taxa de regressão não é pessimismo. É medição.

A Prova do Query Planner

Para quem prefere exemplos concretos a estatísticas agregadas, considere o caso da reescrita do SQLite em Rust, documentado pelo blog KatanaQuant em março de 2026.

Um agente gerou 576.000 linhas de Rust funcional. O código compilava. Os testes passavam. Em operação, buscas por chave primária rodavam 20.171 vezes mais devagar que o SQLite original em C.

O bug: o query planner ignorava a flag is_ipk, forçando table scans completos onde deveria usar index lookups. O tipo de erro que nenhum teste unitário pega porque o resultado é correto, só absurdamente lento.

Como discutimos em Código Barato, Qualidade Cara, o custo de gerar código caiu para perto de zero. O custo de verificar que o código gerado é bom permanece alto. O caso SQLite/Rust é a versão extrema dessa dinâmica: código sintaticamente perfeito, semanticamente destruído.

O Efeito Cumulativo

O dado mais preocupante do DORA 2024 conecta essas observações individuais a uma tendência sistêmica: cada 25% de aumento na adoção de IA em equipes de desenvolvimento correlaciona com 7,2% de queda na estabilidade de entrega.

Note a direção. Mais IA, menos estabilidade. Não é que a IA seja inútil. É que a velocidade de geração ultrapassou a capacidade de absorção. Times produzem mais código, mergeam mais PRs, fecham mais tickets. E o sistema, como um todo, fica mais frágil.

O SWE-CI explica o mecanismo: cada correção automatizada tem 75% de chance de plantar uma regressão futura. Multiplique isso por dezenas de correções por semana, por meses. O resultado é um repositório onde a arqueologia de bugs se torna impossível. Cada camada de correção obscurece a camada anterior.

O Que Fazer

Se você lidera uma equipe que usa agentes para correção de código, três ajustes práticos.

Meça regressões, não resoluções. Benchmark interno que só conta “bugs fechados” está medindo a métrica errada. Comece a rastrear quantos bugs reabertos ou novos têm relação causal com correções automatizadas. Essa métrica não existe na maioria das equipes. Precisa existir.

Limite o raio de ação. Agentes funcionam bem em correções localizadas com escopo claro: um fix de tipo, uma validação de input, um ajuste de configuração. Correções que tocam múltiplos módulos ou alteram fluxos de controle precisam de revisão humana antes do merge, não depois. O SWE-CI sugere que a taxa de regressão cresce proporcionalmente ao escopo da mudança.

Trate correções automatizadas como dívida potencial, não como resolução definitiva. Cada patch gerado por agente deveria entrar em uma fila de revisão de 30 dias. Se nenhum problema surgir nesse período, o patch é promovido a fix permanente. Se algo quebrar, o padrão de regressão fica visível e pode ser corrigido na raiz.

Nenhum desses ajustes requer abandonar agentes. Requerem governar agentes. A diferença entre uma ferramenta que acelera e uma ferramenta que degrada é a infraestrutura de verificação ao redor dela.

Benchmarks pontuais nos dizem que agentes sabem consertar. Dados longitudinais nos dizem que eles não sabem manter. O desafio de engenharia dos próximos anos não é fazer agentes mais capazes. É fazer o código que eles tocam mais durável.

---

Fontes

• Nieve, M. et al. “SWE-CI: Evaluating LLM Agents on Continuous Software Maintenance.” arXiv 2603.03823v1. Março 2026.
• KatanaQuant. “LLM Plausible Code: SQLite Rewrite Analysis.” blog.katanaquant.com. Março 2026.
• Trottier, C. “The Illusion of Building.” uphack.io. Março 2026.
• DORA. “Accelerate State of DevOps Report.” 2024.

Victorino Group ajuda equipes a governar agentes de codificação com infraestrutura de verificação contínua: contato@victorino.com.br | www.victorino.com.br