Como revisar código gerado por IA, e por que não é a revisão de sempre?

Se gerar código ficou fácil, onde está a dor?

Na pesquisa de desenvolvedores do Stack Overflow de 2025, com mais de 49 mil respostas, 84% disseram usar ou pretender usar ferramentas de IA para programar. Só 29% disseram confiar na precisão do que elas devolvem, contra 40% no ano anterior. A maior frustração, citada por 66%, é a resposta “quase certa, mas não bem”. E 45% dizem que depurar código gerado leva mais tempo.

Junte os números e o retrato é esquisito: um mercado inteiro adotou uma ferramenta em que ele mesmo não confia. A queixa declarada não é a geração. É a conferência. E conferir código gerado por IA pede hábitos diferentes dos que você aprendeu revisando código de colega.

Por que revisar código gerado por IA é diferente?

Pessoas e modelos erram, mas não erram igual. O autor humano erra onde estava com pressa, cansado ou onde não entendeu o problema. E ele deixa rastro: uma variável com nome estranho, um comentário defensivo, um trecho mais confuso que o resto. O código mostra onde a pessoa estava insegura, e a revisão tradicional usa esse sinal sem ninguém perceber.

Código gerado erra parelho. A linha errada tem o mesmo acabamento da linha certa. O modelo não hesita, então não deixa rastro de dúvida, e nomeia bem inclusive o que está errado. Com isso caem, de uma vez, quatro atalhos que a revisão usava:

• Focar no que parece estranho. Nada parece estranho quando o acabamento é uniforme.
• Se está bem nomeado, foi pensado. Nomear bem custava esforço para uma pessoa. Para o modelo é de graça.
• Perguntar ao autor por que ele fez assim. Muitas vezes não havia um porquê, só uma continuação plausível.
• O tamanho do diff indica o esforço. Quatrocentas linhas eram um dia de trabalho. Agora são trinta segundos.

Para onde olhar primeiro no código gerado?

Imagine uma curva. De um lado está o comum: cadastro, listagem, endpoint padrão. Isso apareceu milhões de vezes nos dados de treino, e o modelo acerta com facilidade. Revisar linha a linha ali rende pouco. Do outro lado está o raro: a sua regra de negócio, a exceção que o seu cliente exigiu, o cálculo que só a sua empresa faz. Ali a chance de erro sobe muito, porque não existe um milhão de exemplos daquilo em lugar nenhum.

Um exemplo. Uma função de desconto com três linhas, todas com o mesmo acabamento. Se o cupom expirou, devolve zero. Certo. Calcula a base como total do pedido vezes o percentual. Certo. Devolve o menor valor entre a base e o teto do cupom. Errado: na sua empresa o teto vale por item, não por pedido. Não é descuido nem erro de digitação. É a coisa mais razoável do mundo em qualquer outra empresa. Só não é verdade na sua, e o modelo não tinha como saber.

Daí sai a pergunta que dirige a revisão, feita antes de abrir o diff: que parte disto é específica da nossa empresa? A resposta aponta onde os seus vinte minutos rendem. O resto merece uma passada, não uma leitura.

O desfecho mais comum é aprovar depois de ver os testes verdes e o começo do diff. Testes verdes provam que nada quebrou, não que o pedido foi feito. E o começo do diff costuma ser a parte mais comum do código, justamente onde o modelo erra menos.

Em que ordem ler o diff?

Ninguém decidiu ler diff de cima para baixo. A ferramenta mostra os arquivos em ordem alfabética porque precisa mostrar de algum jeito, e a ordem alfabética não sabe o que importa. Num diff de quatrocentas linhas, o arquivo de cobrança que decide se a mudança pode entrar aparece em décimo quarto, porque começa com a letra P. Quando você chega nele, a atenção já acabou.

A ideia central é inverter: ler de fora para dentro, intenção antes de detalhe. Primeiro a lista de arquivos, só os nomes, com uma pergunta barata: algum arquivo aqui te surpreende? Depois o que foi apagado, porque linha removida some do diff visual e da memória. Numa revisão real, as três linhas que saíram eram uma validação, um alerta de log e um comentário que dizia “não remover, exigência do contrato com o banco”. Nenhuma quebrava teste.

Os testes vêm antes da implementação. O que o modelo testou revela o que ele achou que estava fazendo, e o que ele nem cogitou testar é a lista do que você precisa conferir no código. Só então você lê de verdade o arquivo que decide, e passa pelo resto procurando padrão fora do lugar. A vantagem dessa ordem é que dá para parar no meio e ainda ter feito uma revisão honesta.

E há um limite. Nenhuma ordem de leitura salva oitocentas linhas. A partir de certo tamanho, a decisão certa é devolver a mudança para ser fatiada em partes que se aprovam sozinhas. Isso custa um pedido ao agente e troca uma revisão impossível por algumas de dez minutos.

Quais são os sete defeitos que a IA produz mais?

Defeito que você procura aparece. Defeito que você espera notar, não, porque código gerado parece bom. Por isso vale ter uma lista curta e procurar pelo sintoma, não pelo bug. Os três primeiros são os mais frequentes e os menos visíveis.

• Tratamento de erro engolido. O catch devolve um valor padrão sem relançar nem registrar nada. Nada quebra, nenhum teste fica vermelho, e o cliente é cobrado em dólar como se fosse real porque a conversão falhou em silêncio.
• Teste que testa o dublê. O teste define que o repositório falso devolve 100 e depois confere que o total é 100. Está verde e não prova nada. Pergunte: que mudança no código faria este teste falhar?
• Caso de borda inventado. Defesas contra formatos que a sua base nunca produz, como cupom que chega como lista ou número. Cada uma é código a mais para manter e um lugar onde erro de verdade passa convertido em vez de reclamar.
• Regra da casa trocada pela regra do mundo. O modelo aplica o padrão do mercado onde o seu negócio tem exceção. O sintoma é trecho com cara de livro-texto no meio de um arquivo cheio de regra sua.
• Consulta ao banco dentro do laço. Funciona com dez itens e derruba com dez mil. O sintoma é um await dentro de um for.
• Concorrência ignorada. Ler, decidir e gravar como se ninguém mais mexesse no mesmo registro, sem transação e sem trava.
• Configuração fixa no código. Um limite, um prazo ou uma taxa escritos direto na linha, como número solto que não veio de lugar nenhum.

Achar os sete não é o objetivo. Sete comentários num pull request de trinta linhas deixam de ser revisão e viram julgamento, e quem recebe para de ler. Comente o que impede a entrada e deixe o resto para a próxima volta.

Quando revisar, quando perguntar e quando devolver?

Duas vantagens que a revisão de código humano nunca teve. O autor está disponível, responde na hora e não se ofende, então interrogue em vez de deduzir. E você pode recusar em vez de consertar: devolver com o motivo, em vez de arrumar você mesmo, que é o reflexo de todo revisor experiente.

Quando o erro é de regra da casa, como o teto por item do desconto, a correção que dura não fica só no código. A regra vai para o CLAUDE.md do projeto, onde o agente a lê antes do próximo pedido.

Continue lendo

• CLAUDE.md: o que é, onde fica e o que escrever nele?O CLAUDE.md é o arquivo de instruções que o Claude Code lê em toda sessão. Onde ele fica, o que entra, o que não entra e um modelo para copiar.
• Claude Code para iniciantes: como sair do terminal vazio para a primeira sessão?O que é o Claude Code, o mínimo de terminal para começar, onde abrir a primeira sessão e o que pedir primeiro. Para quem nunca abriu um terminal.
• Comandos do Claude Code: quais usar e em que momento?Os comandos de barra e atalhos do Claude Code organizados pelo momento de uso: começar, contexto, modelo e esforço, retomar e custo. Atualizado em 2026.