Um modo de falha diferente

Codigo gerado por IA nao falha da mesma forma que codigo humano. Bugs humanos tendem a ser visiveis: um erro de digitacao, uma variavel errada, um erro de logica que quebra um teste. Falhas de IA sao mais sutis. O codigo compila, os testes passam, o PR parece limpo. O problema nao esta no que o codigo faz. Esta no que ele nao faz.

Um arquiteto descreveu assim: "IA nao escreve bugs. Ela escreve lacunas."

Tres padroes que passam em todos os testes

Estes sao padroes de falha reais de sistemas em producao. Todos os tres passam em testes unitarios. Todos os tres passam em testes de integracao. Todos os tres quebram sob carga de producao.

Engolindo erros silenciosamente. IA reescreve um tratador de erro em um try/catch que registra um aviso e retorna um valor padrao. O codigo parece mais limpo apos a reescrita. Testes passam porque o erro e "tratado." Em producao, o sistema continua em estado corrompido e ninguem e alertado ate que dados downstream ja estejam errados.

Concorrencia ausente. IA escreve o caminho feliz. O codigo funciona perfeitamente em testes sequenciais. Sob trafego concorrente de producao, duas requisicoes modificam o mesmo recurso simultaneamente. Sem lock, sem concorrencia otimista, sem deteccao de conflito. A condicao de corrida aparece como corrupcao de dados intermitente que leva semanas para diagnosticar.

Idempotencia removida. Logica de retry reprocessa a mesma operacao sem uma chave de deduplicacao. Funciona bem em staging com volumes controlados de requisicoes. Sob tempestades de retry em producao, o mesmo pagamento e processado multiplas vezes.

Por que testes nao capturam lacunas

Testes verificam comportamento esperado contra casos conhecidos. Eles validam o que voce pediu, nao o que voce esqueceu de definir.

Testes gerados por IA tem um problema adicional: frequentemente sao gerados pelo mesmo modelo que escreveu o codigo. Os testes validam a implementacao, nao os requisitos. Uma IA pode gerar testes que passam engolindo falhas de assertion silenciosamente, testando apenas o caminho feliz ou verificando valores errados.

Cobertura de testes cria confianca, mas nao completude. Numeros altos de cobertura dizem que os caminhos de codigo nos quais voce pensou sao exercitados. Eles nao dizem nada sobre os caminhos de codigo nos quais ninguem pensou.

Verificando pela ausencia

A maioria das ferramentas verifica corretude: esse codigo esta certo? A pergunta mais dificil e completude: algo esta faltando?

Ao revisar uma mudanca, voce precisa saber tres coisas: o que factualmente mudou, o que pode ser arriscado nessas mudancas e o que nao pode ser verificado apenas pelo diff. A terceira categoria e onde lacunas se escondem.

Um processo de verificacao que so reporta o que encontrou de errado nunca vai capturar o que esta ausente. As equipes que lidam bem com isso tem ferramentas que explicitamente listam o que nao pode ser verificado, nao apenas o que foi. Essa e a diferenca entre uma revisao que diz "parece bom" e uma revisao que diz "aqui esta o que eu verifiquei, aqui esta o que eu sinalizei e aqui esta o que eu nao consigo te dizer."