Agentes de IA acham quantos bugs você pedir

A descoberta de bugs se tornou barata

A tese central é que agentes de codificação permitem escolher, em certa medida, quantos bugs investigar: em sistemas complexos, basta pedir que eles encontrem mais problemas. A descoberta, antes limitada pelo tempo disponível dos engenheiros, tornou-se quase gratuita, e os agentes conseguem identificar falhas sutis que talvez passassem despercebidas por anos. Isso começou com vulnerabilidades de segurança, mas pode se estender a problemas de correção, desempenho, acessibilidade e confiabilidade.

Corrigir os bugs, porém, continua custoso. É preciso ponderar o tamanho e a complexidade da solução, a probabilidade de o problema ocorrer, o risco de introduzir novas falhas e a dificuldade de entendimento para futuros revisores ou agentes. O autor observa que a qualidade geral dos programas não parece ter melhorado com a codificação assistida por IA; ao contrário, haveria mais produtos de qualidade duvidosa. Para ele, isso sugere que a capacidade de encontrar bugs cresceu muito mais rápido que a disposição da indústria para corrigi-los.

O que impede a melhoria

Há incentivos para priorizar resultados visíveis e novas funcionalidades, em vez de aperfeiçoar sistemas que já funcionam. A expectativa gerencial de que uma produtividade dez vezes maior gere dez vezes mais recursos e aplicativos reforçaria essa pressão. Também existe um problema de fadiga: analisar sucessivos relatórios de bugs produzidos por agentes exige compreender detalhes do sistema e avaliar cuidadosamente as consequências de cada correção. Com isso, engenheiros podem ignorar revisões automatizadas ou concentrar-se apenas nos achados mais críticos.

Uma alternativa é colocar o agente em um ciclo de revisão, correção e nova revisão, tratando problemas críticos, altos e médios até chegar a um ponto aceitável. O risco é criar “epiciclos”: remendos sucessivos que aumentam a complexidade sem corrigir uma falha estrutural. Segundo o texto, agentes são ruins em simplificações arquiteturais decisivas e podem criar uma solução específica para cada bug, transformando o código em uma espécie de emaranhado. Por isso, ainda cabe aos humanos perguntar se há uma maneira mais simples ou se a base precisa ser reestruturada antes de corrigir uma classe inteira de problemas.

Testes e simplicidade como estratégias

Bons testes podem permitir que o agente corrija problemas repetidamente com menor supervisão. Ao experimentar a implementação da API IndexedDB por meio de codificação assistida, o autor considerou possível chegar a uma implementação confiável quando o agente se aproximasse de 100% de aprovação na suíte de testes. Isso só funcionou porque os Web Platform Tests foram aperfeiçoados durante anos por implementadores independentes, cobrindo cenários incomuns; a maioria das empresas não dispõe de uma suíte de primeira parte comparável.

Outra estratégia é simplificar o desenho do sistema para tornar categorias inteiras de bugs impossíveis. O texto cita aplicativos multipágina em oposição a aplicativos de página única: eles evitariam problemas como quebra do botão voltar, perda do estado de rolagem, vazamentos de memória no cliente e falhas de acessibilidade durante navegações. Sistemas simples podem perder capacidade, mas seriam preferíveis a arquiteturas complexas mantidas por uma sucessão de remendos.

Uma conclusão ainda provisória

O autor diz não ter confiança de que já conheça as respostas e admite que suas conclusões podem envelhecer em poucos meses. Embora agentes talvez consigam um dia administrar sistemas legados muito complexos, ele não aposta nisso sem evidências. Por enquanto, defende preservar princípios como DRY e KISS, manter uma compreensão funcional do código e orientar os agentes para maior qualidade. A nova capacidade de enfrentar bugs sutis pode inaugurar um renascimento da confiabilidade, mas também pode resultar na mesma proporção de falhas, distribuída por mais aplicativos e recursos. O efeito dependerá de como a indústria responder ao desafio.