A IA agêntica precisa de mais testadores, não de menos

A IA agêntica está mudando a forma como o software é desenvolvido e lançado. Assistentes elaboram solicitações de pull request, agentes iniciam migrações e bots de revisão afirmam que uma alteração é segura antes mesmo que alguém termine o café. Muitas vezes, o setor apresenta esse cenário como um caminho para reduzir o número de profissionais de qualidade. Essa perspectiva está invertida. Quanto mais código as máquinas escrevem, mais escassa se torna uma habilidade que não é a geração de código, mas a verificação independente.

A Pesquisa com desenvolvedores do Stack Overflow de 2025 constatou que 84% dos entrevistados usam ou planejam usar ferramentas de IA no desenvolvimento, e que 51% dos desenvolvedores profissionais as utilizam diariamente. A avaliação positiva caiu para 60%, e mais desenvolvedores desconfiam ativamente da precisão da IA (46%) do que confiam nela (33%). A principal frustração, citada por 66%, foram soluções quase certas, mas não totalmente. A pesquisa DORA de 2025 informou, no Google Cloud, que a adoção de IA entre profissionais de desenvolvimento de software chegou a 90%; mais de 80% disseram que a IA aumentou a produtividade, mas apenas 24% afirmaram confiar muito ou bastante nela. Ser útil sem inspirar confiança é justamente o que amplia o trabalho de quem testa, em vez de reduzi-lo.

Velocidade não é prova

Trabalho com qualidade de software, com foco em testes agênticos e controles de integração contínua (CI) para código escrito por IA. Na empresa, lançamos um revisor de solicitações de pull request e um gerador de casos de teste. Ambos são ferramentas para elaborar rascunhos. Nenhum deles avalia o próprio trabalho. Essa regra é importante porque os agentes falam com convicção. Convicção não é sinônimo de correção.

Aprendemos isso da maneira mais cara. Em um projeto-piloto de revisor de solicitações de pull request criado com IA, uma alteração passou pela integração contínua em menos de 4 minutos. Dois dias depois, um painel subsequente mostrou temperaturas impossíveis. Uma inversão da conversão de Celsius para Fahrenheit estava em um caminho de código que a suíte nunca exercitava. O pipeline estava verde. O produto estava errado. Uma integração contínua verde que nunca fez a pergunta difícil é puro teatro.

Esse incidente faz parte de um padrão mais amplo. O Relatório sobre o estado da geração de código por IA versus por humanos, da CodeRabbit, analisou 470 solicitações de pull request de projetos de código aberto no GitHub (320 coescritas por IA e 150 exclusivamente por humanos). As alterações escritas por IA geraram cerca de 1,7× mais problemas no total; problemas de lógica e correção foram 75% mais comuns, e as falhas de segurança chegaram a ser 2,74× mais frequentes. O Relatório de segurança de código com IA generativa de 2026, da Veracode, testou modelos em diferentes tarefas de segurança e constatou uma taxa média de aprovação em segurança de 56%, pouco diferente dos 55% do relatório anterior; cerca de 44% das tarefas de geração de código por IA introduziram uma vulnerabilidade conhecida. A sintaxe está quase resolvida. Comportamentos seguros e corretos, não. Quem testa é quem se recusa a confundir essas duas coisas.

Dependências alucinadas são um problema de testes

A geração também inventa dependências. A pesquisa da USENIX Security de 2025, Temos um pacote para você!, avaliou alucinações de pacotes em 16 modelos de linguagem de grande porte (LLMs) que geram código, com base em 576.000 amostras. Em média, os modelos comerciais alucinaram pacotes em pelo menos 5,2% dos casos; os modelos de código aberto tiveram média de 21,7%, com 205.474 nomes alucinados únicos. Pacotes fantasmas persistentes criam um alvo fácil para o sequestro de nomes de pacotes: invasores registram o nome inventado e esperam que um desenvolvedor ou agente o instale.

As verificações de procedência das dependências devem estar no mesmo nível dos testes funcionais. Se um agente inventar um pacote NuGet ou npm, a mesclagem deve ser bloqueada antes mesmo de alguém discutir se os testes unitários foram abrangentes. Verificar a procedência não é uma prática opcional de higiene. É um controle de qualidade para alterações escritas por IA.

Controles que acompanham a escala dos agentes

Quando fizemos, em toda a organização e em cerca de duas semanas, uma atualização do .NET 8 para o .NET 10 com automação assistida por IA, fiquei responsável pelos controles de qualidade. A velocidade foi real. Também foi real a necessidade de verificações que não confiem no resumo do agente. Nos trechos de código alterados, aplico os seguintes controles:

• Metas de pontuação de mutação entre 60% e 70% na lógica alterada, para que a suíte elimine mutantes reais, em vez de apenas cobrir linhas
• Testes baseados em propriedades para lógicas de alto risco, nas quais exemplos, por si só, não especificam o comportamento de forma suficiente
• Verificações da procedência de dependências para prevenir o sequestro de nomes de pacotes e o uso de pacotes alucinados
• Sinais de duplicação e de alterações excessivas que detectam o trabalho repetitivo de copiar e colar dos agentes
• Verificação independente de afirmações dos agentes, como “migração concluída”, pois uma afirmação é uma hipótese até que surjam evidências

A pontuação de mutação não é uma métrica de vaidade. Ela verifica se os testes detectam uma falha introduzida deliberadamente. A cobertura pode aumentar enquanto a suíte continua deixando passar o caminho de Celsius. As verificações baseadas em propriedades obrigam o modelo do sistema a se manter válido em diferentes intervalos, e não apenas em um cenário favorável. A verificação de procedência fecha a porta para pacotes suspeitos. Os sinais de alterações excessivas e de duplicação detectam o hábito dos agentes de reescrever a mesma ideia de três maneiras. Juntos, esses controles formam uma postura: presumir que o agente está errado até que a suíte prove o contrário. Mantenho essa regra de calibragem durante a revisão.

Nada disso substitui os testes de API, de autenticação, de fumaça ou a automação da interface do usuário. O FlaUI e o PowerShell ainda detectam problemas que passam despercebidos nas APIs. O empacotamento por NuGet, MSI e MSM ainda exige validação da instalação e dos modos silenciosos. Os fluxos de trabalho agênticos ampliam o volume. Não eliminam essas práticas.

Mais testadores, trabalho diferente

O receio é que os agentes escrevam os testes e os seres humanos se tornem dispensáveis. Os agentes podem elaborar casos de teste, mas não devem certificar os próprios rascunhos. Entre os participantes do Stack Overflow que planejam usar IA para testes no futuro, a desconfiança humana continua sendo central: quando recorreriam a outra pessoa para pedir ajuda, o principal motivo era não confiar nas respostas da IA. Esse instinto é um trunfo da profissão.

É importante contratar e dar condições para que pessoas com trajetórias não tradicionais tenham sucesso nessa área. Migrei para a área de qualidade depois de uma carreira em operações de RH e dados, concluí um mestrado em Sistemas de Informação na UMBC em maio de 2024 e hoje passo os dias tornando práticos os mecanismos de controle para sistemas agênticos. A IA agêntica não vai esperar que todos tenham uma trajetória profissional idêntica. Ela precisa de mais pessoas capazes de elaborar evidências, não de menos pessoas que aprovam sem questionar builds verdes.

A questão do produto é simples. Se os agentes lançam produtos mais rápido do que sua verificação consegue acompanhar, você não está ganhando em produtividade. Está adiando um incidente. Invista em profissionais de testes que desconfiem de todas as afirmações dos agentes, integrem testes de mutação e proveniência ao CI e mantenham o discernimento independente justamente nos pontos em que o modelo é mais eloquente e menos confiável. A IA agêntica precisa de mais profissionais de testes, não de menos.