Quem testa o código que a IA escreveu? Quando o teste verde deixa de ser prova

Muitas equipes montaram, sem perceber, este circuito: a IA escreve o código, a IA escreve os testes, o CI fica verde e a produção quebra. Cada etapa parece razoável sozinha. O problema está na soma, porque ninguém dentro do circuito é independente de quem escreveu o código.

Os números de 2026 apontam para essa tensão. Em uma pesquisa da Applause realizada em agosto e divulgada em 30 de setembro, mais de 92% dos respondentes usavam IA no processo de testes, contra 59,6% no levantamento anterior, e 29% relataram aumento na quantidade ou na gravidade dos defeitos. Em outra, da SmartBear, com 1.436 participantes nos Estados Unidos e no Reino Unido, 46% das equipes já tinham colocado em produção código gerado por IA que depois falhou, e ainda assim 69% desse grupo mantinha muita ou total confiança de que esse tipo de código se comporta como esperado. Trato esses números como indício, e não como sentença, porque são pesquisas de fornecedores, com amostras e critérios próprios. Mesmo assim, a combinação de mais velocidade, mais defeitos e confiança intacta descreve um problema que qualquer pessoa de QA reconhece.

Por que o teste verde deixa de provar alguma coisa

Quando o teste é gerado a partir do código, ele herda as mesmas suposições do código. Se a implementação entendeu o requisito errado, o teste entende errado do mesmo jeito, e os dois concordam entre si. Veja um parcelamento em centavos:

// código gerado
function parcelar(totalCentavos, n) {
  return Array(n).fill(Math.round(totalCentavos / n));
}

// teste gerado a partir do código
expect(parcelar(1000, 3)).toEqual([333, 333, 333]);

O teste passa, mas a soma das parcelas é 999: um centavo desapareceu. O teste copiou o comportamento do código, e não o requisito, que diz que as parcelas devem somar o total. Um teste derivado do requisito falha logo na primeira linha:

// teste derivado do requisito
const p = parcelar(1000, 3);
expect(p.reduce((a, b) => a + b, 0)).toBe(1000);
expect(Math.max(...p) - Math.min(...p)).toBeLessThanOrEqual(1);

A pergunta que separa os dois testes é simples: de onde veio o valor esperado? Se veio do código, o teste só confirma que o código faz o que o código faz. Se veio do requisito, ele pode discordar, e é essa capacidade de discordar que dá valor a um teste. Com uma biblioteca de testes baseados em propriedades, como o fast-check, essas duas últimas linhas viram uma regra verificada com milhares de entradas geradas.

Há uma segunda verificação barata: perguntar se o teste consegue falhar. Ferramentas de teste de mutação, como o Stryker (JavaScript e TypeScript) e o PIT (Java), alteram o código de propósito e conferem se algum teste percebe a alteração. No exemplo acima, trocar Math.round por Math.floor não muda nada para o teste gerado, e uma suíte que não nota essa troca não protege o que parece proteger. A cobertura de linhas diz que o código executou, e a mutação diz se o teste notaria um erro.

O que muda para quem faz QA

Se gerar código e testes ficou barato, o trabalho de QA se desloca para a pergunta mais cara: podemos confiar no processo que produziu este software? Isso é mais do que achar bugs no fim da fila. Significa medir a confiança com evidência, e não declará-la. Algumas medidas ajudam: a pontuação de mutação nos módulos críticos, a taxa de testes instáveis, os defeitos que escaparam para a produção e o tempo que a equipe leva para atualizar a automação depois de uma mudança. Em uma pesquisa da Leapwork em parceria com a SD Times, com 302 respondentes entre dezembro de 2025 e janeiro de 2026, 56% apontaram a manutenção dos testes como o que mais desacelera as equipes, atrás apenas da criação de testes, citada por 71%, o que mostra que a automação sozinha não resolve.

Na prática, três hábitos mudam bastante o resultado. O primeiro é escrever o valor esperado a partir do requisito antes de pedir o código à IA. O segundo é revisar cada teste gerado com a pergunta sobre a origem do esperado. O terceiro é rodar mutação nos caminhos que não podem falhar, como cálculo de valores, autorização e integração com terceiros. E como nenhuma suíte cobre tudo, vale somar observabilidade e liberação gradual em produção, para que o erro que passou apareça pequeno e seja revertido rápido.

Esse trabalho exige ler código e escrever código, e por isso funciona melhor quando QA e desenvolvimento deixam de ser lados opostos. A velocidade da IA é um fato. A confiança no que ela entrega continua sendo algo que a equipe precisa construir, teste a teste, com evidência.