Como testar código gerado por IA com segurança

Quando a mesma inteligência artificial gera o código e sugere os testes, a equipe precisa verificar mais do que a aparência da suíte. Testar código gerado por IA exige separar três evidências: o código compila, os testes parecem coerentes e o comportamento observado atende ao que o produto precisa entregar. Testes gerados por IA podem ajudar, mas não devem virar prova única. Antes do aceite, é preciso exigir verificação independente do comportamento.

Por que testes gerados pela IA precisam de verificação independente

Quando a mesma inteligência artificial gera a solução e sugere os testes, há um risco a considerar: os testes podem confirmar a forma como a solução foi pensada. Isso não significa que estejam errados. Significa apenas que eles podem estar próximos demais da implementação.

O problema não é usar testes gerados por IA. O problema é aceitar esses testes como se eles provassem, sozinhos, que a mudança resolveu o problema certo.

Um teste é um artefato. Evidência de qualidade é outra coisa. A evidência precisa mostrar que uma entrada, uma ação e um estado esperado foram observados em condições relevantes para o produto. Se o teste só exercita uma função isolada, com dados convenientes e sem verificar efeito real, ele pode ser útil para localizar erro técnico, mas ainda fraco para aprovar comportamento.

A cobertura de testes também precisa ser tratada com cuidado. Ela pode indicar que partes do código foram executadas, mas não confirma que os cenários relevantes foram escolhidos, que os critérios do usuário foram atendidos ou que as falhas perigosas foram bloqueadas. Cobertura ajuda a investigar. Não substitui critério.

Essa distinção fica mais relevante quando a equipe adota ferramentas de geração de código em escala. A liderança não precisa barrar a IA. Precisa impedir que velocidade de produção vire velocidade de aceitação. O processo de qualidade deve continuar perguntando: que comportamento foi prometido, que comportamento foi observado e que risco ainda ficou sem verificação?

Essa conversa se conecta à discussão mais ampla sobre estratégia de inteligência artificial conectada ao negócio. Se a IA entra no desenvolvimento sem critérios de decisão, ela amplifica tanto a capacidade de entrega quanto a capacidade de produzir confiança falsa.

Defina comportamento esperado antes de ler a suíte gerada

Antes de ler os testes gerados, descreva o comportamento esperado da mudança. Essa descrição não precisa virar um documento longo. Precisa ser verificável.

Um bom critério de comportamento responde, no mínimo:

• Qual entrada ou condição inicia a mudança?
• Que ação o sistema deve executar?
• Qual resultado precisa ser percebido pelo usuário, por outro sistema ou por uma rotina interna?
• Que estado deve ser persistido, alterado ou preservado?
• Que efeito colateral é aceitável?
• Que situação deve bloquear a ação?

Essa ordem importa. Se a equipe começa pelos testes gerados, tende a avaliar se eles “fazem sentido”. Se começa pelo comportamento, avalia se eles provam alguma coisa relevante.

Imagine um cenário fictício: uma equipe pede a uma IA que altere a regra de desconto de um comércio eletrônico. O código gerado aplica um cupom promocional. A IA também cria testes para validar um cupom ativo e calcular o preço final. Tudo passa.

Ainda assim, a pergunta de qualidade não está respondida. O comportamento esperado talvez inclua recusar cupom expirado, impedir uso duplicado, bloquear desconto para cliente inelegível e registrar o motivo da recusa para atendimento. Se esses critérios não foram escritos antes da aprovação, a suíte que “passa” pode estar apenas confirmando o caminho feliz.

A liderança deve pedir uma frase verificável, não uma justificativa abstrata. Por exemplo: “Dado um cupom expirado, quando o cliente tenta aplicá-lo no carrinho, o sistema deve recusar o desconto, manter o valor original e registrar o motivo da recusa”. Essa frase já orienta teste automatizado, exploração manual e revisão de efeito no ambiente.

Cruze testes existentes, testes gerados e lacunas de risco

Depois de definir comportamento, a suíte pode ser lida em três camadas.

A primeira camada são os testes existentes. Eles dizem quais comportamentos a equipe já considerava relevantes antes da mudança. A pergunta aqui é simples: algo que já era protegido foi removido, relaxado ou contornado para fazer o novo código passar?

A segunda camada são os testes gerados pela IA. Eles podem revelar cenários que a equipe não tinha lembrado, automatizar verificações repetitivas e acelerar a escrita de casos simples. Mas devem ser avaliados como proposta, não como autoridade. O teste gerado precisa ser lido com a mesma desconfiança produtiva aplicada ao código gerado.

A terceira camada são os casos de risco. São situações em que o erro teria impacto maior, mesmo que o caso seja menos frequente. Nem todo risco merece automação imediata. Alguns merecem revisão manual, teste exploratório, simulação de integração ou liberação gradual.

A comparação deve produzir uma pergunta objetiva: que comportamento ficou sem prova?

Essa pergunta evita dois extremos. De um lado, aprovar porque “tem teste”. De outro, rejeitar tudo que foi gerado por IA por princípio. O ponto é mais maduro: identificar lacunas de evidência e decidir como tratá-las.

O DORA recomenda testes ao longo do desenvolvimento, combinando automação com atividades manuais, como exploração e usabilidade, além de manter e revisar suítes de teste. Essa referência sustenta uma prática importante: qualidade não é uma etapa posterior para carimbar o que já foi feito. Ela é um conjunto de verificações distribuídas durante a mudança.

Inclua casos negativos e bordas na revisão

Mesmo quando o caminho principal parece claro, a revisão de código gerado por IA deve incluir bordas como permissões, estados antigos, dados incompletos, entradas inválidas, concorrência, integrações indisponíveis e regras que só aparecem quando o produto encontra a operação real.

Casos negativos são situações em que o sistema não deveria produzir o resultado feliz. Eles testam recusa, limite, interrupção ou preservação de estado. Em muitos produtos, o erro mais caro não é deixar de fazer algo. É fazer algo que não deveria.

Voltando ao exemplo fictício do cupom de desconto, os testes gerados cobrem o cupom válido. A revisão de qualidade deveria perguntar:

• O que acontece com cupom expirado?
• O sistema impede uso duplicado?
• Cliente inelegível recebe desconto indevido?
• O valor original é preservado quando a aplicação falha?
• O motivo da recusa fica disponível para suporte ou auditoria interna do produto?
• Uma alteração de regra muda pedidos já fechados?

Essas perguntas não afirmam que o erro ocorrerá. Elas delimitam hipóteses de falha que precisam ser verificadas de acordo com o risco.

Um critério prático: para cada mudança gerada por IA, exija pelo menos um caso que prove o caminho feliz e pelo menos um caso que prove uma recusa relevante. Em funcionalidades críticas para receita, permissão, privacidade, disponibilidade ou experiência central do usuário, esse mínimo tende a ser insuficiente, mas já impede a aprovação baseada apenas no cenário conveniente.

Aqui há uma diferença importante em relação à estratégia de inteligência artificial conectada ao negócio. A estratégia define critérios de adoção, governança e prioridade. Testar comportamento pergunta se o sistema faz o que deveria fazer diante de condições observáveis. As duas práticas se complementam, mas uma não substitui a outra.

Verifique efeitos no ambiente, não apenas mensagens de sucesso

Um teste que recebe “sucesso” como resposta ainda pode não comprovar o resultado real. A mudança pode ter retornado a mensagem correta, mas não gravado o estado esperado. Pode ter atualizado o banco, mas não publicado um evento. Pode ter chamado uma integração simulada, mas deixado uma fila em estado inconsistente. Pode ter registrado um log, mas com permissão indevida.

A Anthropic, ao discutir avaliações de agentes, distingue a trajetória de execução do resultado efetivo no ambiente: uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado. A avaliação usa entradas, critérios de sucesso e verificadores, e pode exigir várias tentativas, conforme descreve a Anthropic.

Por analogia, essa distinção pode orientar a revisão de código gerado por IA, mesmo quando não há agente autônomo em produção. O que interessa é separar “o código executou um caminho” de “o ambiente ficou no estado correto”.

Em termos práticos, a equipe deve definir verificadores compatíveis com o comportamento esperado. Dependendo da mudança, isso pode incluir:

• registro no banco de dados;
• evento publicado em fila;
• arquivo criado ou preservado;
• permissão aplicada corretamente;
• chamada a serviço externo simulada com contrato conhecido;
• estado anterior mantido quando a operação falha;
• log suficiente para investigação sem expor dado indevido.

Não é necessário transformar todo pull request em uma avaliação pesada. A intensidade da verificação deve acompanhar o impacto do erro, a reversibilidade da mudança e a facilidade de observar falhas depois da liberação.

Um sinal de alerta: testes que só verificam que uma função foi chamada, sem confirmar o efeito que justificava a chamada. Esse tipo de teste pode ser aceitável em partes internas de baixo risco, mas é fraco quando o comportamento esperado depende de estado persistido ou interação com outros sistemas.

Escolha a verificação pelo tipo de risco

Nem toda verificação deve ser automatizada imediatamente. Automatizar faz sentido quando o fluxo é repetível, o critério de sucesso é claro e a regressão seria relevante. Já a exploração manual ajuda quando a mudança envolve ambiguidade de usabilidade, combinações novas de comportamento ou dúvidas que ainda não cabem bem em um teste automatizado.

A pergunta não é qual prática parece mais moderna. É qual verificação consegue observar o risco que a mudança introduz.

Use automação quando:

• o comportamento é estável e recorrente;
• o erro seria relevante em regressões futuras;
• o cenário pode ser reproduzido com dados controlados;
• o verificador consegue observar resultado, não apenas execução.

Use exploração manual quando:

• a experiência depende de julgamento humano;
• há ambiguidade na regra de produto;
• a equipe ainda está descobrindo quais falhas importam;
• a automação criaria uma falsa precisão.

Considere liberação gradual quando o risco depende de uso real controlado, quando a mudança é reversível e quando existem sinais observáveis para interromper a exposição. O capítulo de Google SRE sobre canarying trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar a exposição. Também distingue disponibilizar código de ativar funcionalidades, usando configurações para separar essas decisões.

Essa separação é valiosa para código gerado por IA. Fazer merge não precisa significar ativar para todos. A equipe pode disponibilizar o código, manter uma configuração desligada, observar em ambiente controlado e ampliar apenas se os sinais definidos forem aceitáveis.

A METR, em atualização de fevereiro de 2026, considera seus novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade e aponta dificuldades como seleção de participantes e tarefas e medição de tempo com agentes concorrentes, segundo a METR. Para decidir como testar o código, uma leitura prudente é não usar expectativas genéricas de produtividade como justificativa para reduzir evidência de qualidade.

Se a organização está montando um roadmap de IA, esse ponto deveria aparecer como capacidade de engenharia, não apenas como adoção de ferramenta. Testar melhor é parte da adoção. Não um freio externo a ela.

Roteiro de aprovação para código gerado por IA

Use este roteiro para não aceitar testes gerados por IA como prova única. Ele não substitui o julgamento técnico da equipe, mas ajuda a transformar a discussão em critérios observáveis.

Comportamento esperado

A mudança tem critérios observáveis antes da leitura dos testes gerados?

Aceite quando existir uma descrição verificável de entrada, ação, resultado e efeito colateral aceitável.

Independência mínima

Há pelo menos uma verificação que não foi apenas sugerida pelo mesmo fluxo que gerou o código?

Aceite quando um humano, teste existente, caso de aceite ou verificador externo confirmar o comportamento relevante.

Caminho feliz

O caso principal do usuário foi testado do ponto de vista do produto, e não apenas da função alterada?

Aceite quando o teste demonstrar o resultado percebido pelo usuário ou pelo sistema consumidor.

Casos negativos

A suíte prova que o sistema recusa, limita ou interrompe situações inválidas?

Aceite quando houver cobertura para pelo menos um erro previsível, uma permissão indevida ou uma entrada fora do padrão.

Regressão

A mudança preserva comportamentos que já existiam e não deveriam mudar?

Aceite quando testes existentes relevantes continuarem passando e a equipe revisar se algum teste foi removido, relaxado ou contornado.

Efeito real

O teste verifica o estado produzido no ambiente, e não apenas uma mensagem de sucesso?

Aceite quando banco, fila, arquivo, evento, permissão ou estado persistido forem checados sempre que fizerem parte do comportamento esperado.

Liberação

O risco residual permite merge direto, exploração manual, flag de configuração ou exposição gradual?

Aceite quando a decisão de liberação estiver ligada ao impacto do erro, à reversibilidade e à capacidade de observar falhas.

Regra de aprovação: nenhum código gerado por IA deveria ser aceito apenas com testes gerados pela mesma IA. Pode ser um teste existente, um caso negativo escrito pela equipe, uma exploração manual dirigida ou uma liberação gradual com sinais definidos. O que não deveria passar é a aprovação automática de um pacote em que a IA escreveu o código, escreveu os testes e também definiu, sozinha, o que conta como qualidade.

Se a sua equipe está revendo como adotar IA com mais critério em engenharia e produto, vale conversar com a dooop.

Leituras para continuar

• Qualidade de software com IA: testes, avaliação e responsabilidade
• Como medir a produtividade de desenvolvedores com IA
• Como revisar código gerado por IA

Fontes

• DORA: automação de testes
• Anthropic: avaliações de agentes
• Google SRE: lançamentos graduais
• METR: limites da medição de produtividade