A IA gerou código errado: por que acontece e como revisar antes de quebrar produção

A IA gerou o código. Roda. Compila. Passa no happy path. E três dias depois quebra em produção, num caso de borda que ninguém testou.

Se isso já aconteceu com você, não é azar nem incompetência. É o comportamento esperado de quem trata código gerado por IA como pronto só porque parece pronto. O modelo não te entregou uma solução. Ele te entregou um texto que tem alta probabilidade de parecer uma solução. Não é a mesma coisa.

Neste post a gente separa as duas coisas: por que a IA gera código errado de um jeito tão convincente, e que processo de revisão pega o problema antes do merge — sem te transformar num revisor paranoico que desconfia de cada linha.

TL;DR

• O que é: código gerado por LLM que parece correto, compila e passa no caminho feliz, mas falha em borda, concorrência, contrato de API ou segurança.
• Por que acontece: o modelo é treinado para produzir o próximo token mais provável, não o token correto. Plausibilidade não é corretude.
• Como resolver: processo de revisão em camadas — rodar de verdade, ler com intenção, testar borda, checar dependências e segurança — antes do merge.
• Para quem é: dev que usa Copilot, Cursor, Claude ou qualquer agente no dia a dia e quer parar de levar susto em produção.

Por que a IA gera código errado que parece certo

Vamos ao ponto técnico, porque sem ele o resto vira superstição.

Um LLM gera código prevendo o próximo token mais provável dado o contexto. Ele não tem um modelo de execução na cabeça. Não roda o código mentalmente. Não sabe se a função existe — sabe que, estatisticamente, um nome de função parecido com aquele costuma aparecer naquele lugar.

E aqui mora o problema. O objetivo de treino e os benchmarks que medem esses modelos recompensam o chute confiante mais do que a incerteza calibrada. Um paper da OpenAI de setembro de 2025 mostra exatamente isso: o modelo aprende que blefar com confiança pontua melhor do que dizer "não sei". Traduzindo pro seu PR: o código vem com nome de variável impecável, comentário convincente, type hint coerente e uma estrutura lógica. Tudo isso é a embalagem. Nada disso garante o conteúdo.

O Simon Willison resumiu bem: "código de LLM geralmente parece fantástico: bons nomes de variável, comentários convincentes, type annotations claras e estrutura lógica. Isso pode te dar uma falsa sensação de segurança." E completa com a distinção que importa: o método alucinado é o erro fácil — "no momento em que você roda o código, qualquer método alucinado fica óbvio na hora: você toma um erro". O perigo de verdade são os erros que o compilador não pega.

Não é teoria. Um estudo apresentado no USENIX Security 2025 testou 16 modelos de geração de código em 576 mil amostras e achou que 19,7% dos pacotes recomendados simplesmente não existiam — nomes inventados, plausíveis, prontos pra você dar composer require ou pip install e abrir uma porta pra ataque de supply chain. O modelo não mentiu de propósito. Ele preencheu uma lacuna com o que era estatisticamente provável.

Os quatro erros que passam pelo happy path

Erro de sintaxe e import quebrado o interpretador acusa em segundos. Esses não te machucam. Os que machucam são os que rodam:

1. Borda silenciosa. O código trata o caso comum e ignora o vazio, o nulo, o negativo, a lista com um elemento, o usuário sem permissão. Passa no teste que você escreveu pensando no fluxo principal. Quebra com o input real.
2. Contrato de API errado. A função existe, mas o modelo inventou um parâmetro, trocou a ordem, assumiu que retorna um array quando retorna um objeto. Compila no PHP, explode no runtime quando aquele caminho específico é exercido.
3. Concorrência e estado. Race condition, lock que falta, cache que não invalida. O tipo de bug que só aparece sob carga — ou seja, em produção, nunca no seu teste local.
4. Segurança plausível. Query montada por concatenação, validação que parece existir mas não cobre o caso, segredo logado. Estudos apontam que perto de 29% do código gerado contém potenciais fraquezas de segurança — e segurança é justamente o tipo de coisa que "passa no happy path" porque o happy path não é um ataque.

Some a isso um dado de tendência: a GitClear mostrou que clones de código aumentaram cerca de 4x na era dos assistentes, com mais churn de curto prazo. Mais copy-paste, menos design. O modelo resolve o trecho na sua frente sem olhar o resto do sistema — e isso é exatamente o que você precisa compensar na revisão.

O processo de revisão que pega o erro antes do merge

A boa notícia: você não precisa desconfiar de tudo. Precisa de um processo, e o processo é mais barato do que o rollback. Cinco camadas, da mais barata pra mais cara.

1. Rode. De verdade. Antes de qualquer coisa, execute o código no fluxo que ele deveria cobrir. Não leia e aprove — rode. Ler código de IA e achar bonito é a tal falsa sensação de segurança. Boa parte da alucinação grosseira morre aqui, no primeiro php artisan ou no primeiro teste verde.

2. Leia com intenção, não com confiança. Reler procurando confirmação é inútil — você vai achar tudo lindo. Releia procurando a falha. Pergunte a cada bloco: o que acontece se a entrada for vazia? E se a API estiver fora? E se dois requests caírem ao mesmo tempo? Trate o diff como código de um estagiário esperto e apressado, não de um sênior.

3. Teste a borda, não o caminho feliz. O modelo já te entregou o caso comum funcionando. Seu teste tem que cobrir o que ele ignorou: nulo, vazio, limite, permissão negada, payload malformado. Se você só escrever o teste do happy path, está carimbando o ponto cego do modelo.

// O modelo entrega isso e "funciona":
public function aplicarDesconto(Pedido $pedido, float $percentual): float
{
    return $pedido->total - ($pedido->total * $percentual / 100);
}

// A revisão pergunta: e percentual negativo? E acima de 100?
// E pedido com total zero? Onde está a validação?
// O teste de borda é o que expõe o buraco — não a leitura.

4. Cheque dependências e contratos. Toda lib que o código importa, confirme que existe e que a assinatura usada é real. Aquele 19,7% de pacotes fantasma não é estatística distante — é o import que você ia aceitar no automático. Abra a doc, confirme o retorno, confirme o parâmetro.

5. Passe um segundo par de olhos — humano ou máquina. Aqui um revisor automatizado ajuda, desde que você saiba o que ele é. Ferramentas de review por IA viraram rede de segurança pré-merge boa pra pegar borda, race condition e null pointer que escapam na leitura humana. Mas é camada, não juiz final. IA revisando IA não substitui alguém que entende o produto decidindo se aquilo deve entrar.

Repare que nenhuma dessas camadas é "confie no modelo". E olha que não é exagero de neurótico: cerca de 46% dos devs dizem não confiar plenamente no resultado da IA. A diferença entre quem leva susto e quem não leva não é confiar mais ou menos — é ter um processo que não depende de confiança.

FAQ rápido

Então eu paro de usar IA pra codar? Não. IA acelera muito — em torno de 46% do código em quem usa assistente já sai assim. O ponto não é parar de gerar. É parar de mergear sem revisar. Velocidade de geração sem processo de revisão é dívida técnica em alta velocidade.

Não dá pra confiar que o modelo melhora e isso some? Os modelos melhoram, mas o problema é estrutural: enquanto o treino premiar o chute confiante sobre a incerteza, vai existir código plausível-e-errado. Melhora a taxa, não a natureza. Processo de revisão não é gambiarra temporária.

Testes não resolvem sozinhos? Só se você escrever os testes de borda. O perigo é deixar a IA escrever também os testes — aí ela testa o happy path que ela mesma cobriu e o ponto cego fica selado em verde. Teste é seu, principalmente o que dói. A gente destrinchou esse jogo de quem manda no teste em TDD com agentes: testes que sobrevivem ao código gerado.

Code review automatizado por IA é suficiente? É uma camada ótima pra pegar o que escapa na leitura humana, mas tem falso positivo e não entende o seu produto. Use como rede, não como aprovador. Quem aprova o merge é quem entende a consequência em produção.

A revisão é a parte de engenharia que sobrou pra você

Quando a geração de código virou commodity, o valor migrou. Não está mais em escrever a função — o modelo escreve. Está em saber se aquela função deve existir, se está no lugar certo da arquitetura, e o que ela quebra no resto do sistema. Revisar código de IA não é desconfiança. É a parte de engenharia que não dá pra terceirizar.

E é por isso que revisar bem começa antes do PR: começa em como você arquiteta a solução. Quando o desenho é claro — fronteiras, contratos, onde cada agente atua e onde o humano decide — a revisão fica fácil, porque você sabe exatamente o que checar. É esse desenho que a gente coloca na mesa no Workshop Arquitetando Soluções de IA, um workshop prático de como arquitetar software com agents de IA — com código rodando e decisão de arquitetura na mesa, não slide.

No fim, é a velha tese: dev bom não é quem gera código mais rápido. É quem entende o problema, modela a solução e garante que o que entra em produção funciona no mundo real — inclusive quando foi a IA que escreveu.