Regressão em correção feita com agente de IA: 21 em mais de 130 PRs

Os testes passaram, o revisor aprovou, o mantenedor do projeto fez o merge. A correção resolveu o bug que prometia resolver. O que mais ela mudou?

A Trail of Bits, empresa americana de segurança de software, fez essa pergunta aos próprios patches e publicou a resposta em 21 de outubro de 2026. Ela revisou todo patch escrito por um engenheiro dela que os mantenedores já tinham aceitado e confirmou 21 regressões. A segurança saiu ilesa: nenhuma delas quebrou uma proteção. O que quebrou foi comportamento que funcionava antes e era suportado.

O que a Trail of Bits contou nos patches que já tinham passado

Os patches vêm do Patch the Planet, iniciativa da Trail of Bits com a OpenAI em que, segundo a empresa, ela foi coautora de centenas de correções de segurança para projetos open source muito usados. Scapy e GPAC são os dois que o texto cita pelo nome. O post trata essas correções como trabalho de agente de código, e a ferramenta que saiu dele foi montada sobre milhares de sessões de Codex dos engenheiros da casa. A empresa não diz quanto de cada patch saiu do agente e quanto saiu da mão de quem o conduziu, e isso importa para ler os números abaixo.

O resultado, nas palavras dela: 21 regressões confirmadas em mais de 130 PRs mergeados, sendo 16 funcionais, uma de desempenho e quatro de build ou teste. Pela nossa conta, isso dá no máximo 16% dos PRs, ou uma regressão para cada seis PRs ou mais. É teto e não taxa, por dois motivos: a base é "mais de 130", e a conta supõe uma regressão por PR, coisa que o texto não diz.

O número não diz que agente erra mais que gente. Não há grupo de controle: ninguém mediu, com o mesmo método, quantas regressões os patches escritos sem agente carregavam nesses projetos. O que ele diz é mais incômodo e mais útil: o filtro de sempre, revisão humana mais aceite do mantenedor, deixou passar essas 21.

Quase duas candidatas falsas para cada regressão real

A revisão foi feita por agente, com um engenheiro conferindo o fim. Para cada patch, um agente procurou regressões possíveis e precisou confirmar cada suspeita rodando uma prova de conceito antes e depois da mudança. Numa única rodada, ele levantou 58 candidatas. Ficaram 21.

As outras 37 não se confirmaram: quase duas candidatas sem prova para cada regressão real, mesmo num fluxo que exige evidência. Quem pede a um agente apenas que "revise o PR atrás de regressões" recebe uma lista longa, diferente a cada rodada, e alguém precisa separar o que é real. A Trail of Bits diz que o regression-hunt, com etapas que exigem evidência, produziu 25% menos falsos positivos do que um agente Codex comum com esse pedido simples. O próprio texto chama a avaliação de preliminar, e o intervalo de confiança de 95% vai de 14% a 38%. A direção é clara; o tamanho exato ainda não.

Segundo a empresa, a diferença está no desenho do fluxo: não acreditar no resumo de ninguém. Cada etapa do plugin regression-hunt recebe a saída da anterior num formato fixo e precisa verificá-la, não aceitá-la:

1. levantar as candidatas seguindo a mudança até as interfaces que alguém de fato chama;
2. reproduzir cada uma num ambiente rodando;
3. repetir a mesma prova com um agente novo, sem o contexto do primeiro;
4. julgar se aquilo é mesmo regressão, e não falso positivo, correção incompleta, bug que já existia ou bug latente que a mudança só revelou.

Sem prova que roda, o resultado é inconclusivo, por regra. A empresa admite o custo dessa rigidez: algumas regressões que ela sabia existir ficaram marcadas como "limítrofes", sem evidência suficiente para confirmar.

Na nossa rotina editorial aprendemos a mesma coisa por outro caminho. Quando passamos a exigir que cada achado de um revisor por agente sobrevivesse a um segundo agente encarregado de derrubá-lo, boa parte dos achados caiu. Revisor que só lista é barato de rodar e caro de ler.

Três árvores que precisam dar o resultado certo

O segundo plugin, patching-bugs, vai do outro lado: escreve a correção. O que ele traz de novo é a regra de aceite, que a empresa chama de prova em três braços. A mesma prova de conceito roda em três versões do código. Na original, o bug precisa aparecer. Na corrigida, precisa sumir. Na versão em que a correção foi inteiramente revertida, precisa voltar.

O terceiro braço é o que separa correção de coincidência. Um teste que passa depois do patch não prova que foi o patch que resolveu: o bug pode ter dependido de outra coisa que mudou junto, ou o teste pode nunca ter exercitado o caminho quebrado. Se reverter a correção não traz o bug de volta, a correção não foi provada, por mais verde que esteja o pipeline.

Duas outras regras do plugin valem tanto para gente quanto para agente. Corrigir a regra de segurança que o bug violou, e não só o caso relatado, para pegar as variantes. E passar todo patch pelo regression-hunt antes de entregar. O plugin não faz push nem abre PR: entrega um relatório local para quem revisa.

Onde a prova executável não tem onde rodar

O método inteiro supõe uma coisa que muita empresa brasileira não tem: um projeto que builda do zero numa máquina limpa e sobe num ambiente onde dá para rodar uma prova contra ele. O patching-bugs pede, logo na entrada, um checkout limpo com o build funcionando. O regression-hunt precisa subir as duas versões, antes e depois, para executar a prova. Os scripts de apoio dos dois exigem Python 3.13 ou mais novo.

Em sistema legado que só compila na máquina de uma pessoa, ou que só existe de verdade no servidor de produção, não há onde rodar os três braços. Ali, o primeiro trabalho não é instalar plugin: é tornar o build reproduzível e ter um ambiente descartável. É o mesmo pré-requisito de qualquer teste automatizado, e a ausência dele já custava caro antes do agente de código. Na nossa operação, migração de automação só vai para produção depois de uma suíte de regressão que roda sem efeito externo, sem rede real e sem gravar nada. Sem esse ambiente, a suíte não existiria.

Também não vale tratar os números como medição independente. Quem mediu foi quem escreveu os patches e quem publica a ferramenta. O texto não traz um único exemplo concreto de regressão, nem tempo, nem custo de tokens por rodada, e o fluxo usa vários agentes por candidata. Para quem paga a conta, o custo total está quase todo em aberto:

• plugins: abertos, num repositório público sob licença CC BY-SA 4.0;
• consumo do agente por rodada, horas para escrever o modelo de ameaça e o guia de correção, tempo do engenheiro que lê o relatório: sem dado publicado;
• ambiente para rodar as provas: sem dado, e é o item que mais pesa em legado.

Por fim, os dois projetos citados, Scapy e GPAC, são ferramentas open source de rede e de mídia. Sistema de negócio, com regra que mora na cabeça de quem opera, tem regressão de outro tipo: a que nenhum teste descreve porque ninguém escreveu a regra.

Os dois arquivos que cabem nesta semana

A recomendação mais barata do texto não depende de plugin nenhum. A Trail of Bits pede dois arquivos na raiz do repositório, que os plugins leem e que servem de contexto para qualquer agente de código:

• um modelo de ameaça (THREAT_MODEL.md): o que o sistema protege, onde estão as fronteiras de confiança, quem pode acessar o quê, quais configurações são suportadas e que evidência basta para chamar algo de vulnerabilidade;
• um guia de correção (PATCHING_GUIDELINES.md, ou o AGENTS.md que o projeto já tenha): como buildar e testar, que tamanho uma correção pode ter, onde ela deve ficar e que teste de regressão é obrigatório.

A decisão desta semana é a segunda metade desse guia: exigir que todo PR de correção, feito com agente ou sem, traga um teste que falha sem a mudança e passa com ela. Não é a prova em três braços inteira, mas é o pedaço que dá para cobrar já no próximo PR.

E a pergunta que dá para responder hoje, com o histórico do seu repositório: dos últimos 20 PRs de correção que entraram, quantos trazem um teste que falha quando a correção é revertida?

Fontes, datas e o que é declaração da empresa

• Caso e números: "Your AI agent fixed the bug, but what else did it change?", de Anish Naik e Marcelo Morales, blog da Trail of Bits, publicado e consultado em 21/10/2026. Os 21 de mais de 130 PRs (16 funcionais, 1 de desempenho, 4 de build ou teste), as 58 candidatas e os 25% a menos de falso positivo (intervalo de 95% de 14% a 38%, avaliação preliminar) são declaração da empresa sobre o próprio trabalho, sem verificação independente.
• Plugins: READMEs de patching-bugs e regression-hunt no repositório trailofbits/skills no GitHub, consultados em 21/10/2026 (licença, requisito de Python 3.13 ou mais novo, ausência de push e de PR automático).
• Contas nossas: 16% é 21 dividido por 130, teto pelo motivo explicado no texto; uma para cada seis ou mais é 130 dividido por 21; 37 falsas é 58 menos 21; quase duas por regressão real é 37 dividido por 21.
• Experiência da X-Apps: a rotina editorial deste blog e a migração das nossas automações internas, descritas sem número.