O Guia do Desenvolvedor para Revisar Código Gerado por IA

A revisão de código sempre foi sobre capturar erros antes que cheguem à produção. Mas quando o código foi escrito por um assistente de IA em vez de um colega humano, a dinâmica da revisão muda fundamentalmente. Os erros que a IA comete são diferentes dos erros que um humano comete, e as coisas que você precisa verificar não são as mesmas que você verificaria em uma revisão entre pares.

Este guia cobre o que equipes experientes aprenderam sobre revisar código gerado por IA. Está organizado pelas categorias de problemas que modelos de IA consistentemente produzem, para que você possa passar por uma lista de verificação sistemática em vez de confiar na intuição desenvolvida para código escrito por humanos.

Por que código gerado por IA precisa de critérios de revisão diferentes

Desenvolvedores humanos cometem erros que se agrupam em torno de fadiga, distração e lacunas de conhecimento — um desenvolvedor cansado perde um caso de borda, um distraído esquece de tratar um erro, um júnior usa um anti-padrão porque não sabe melhor. Modelos de IA cometem erros que se agrupam em torno de eixos totalmente diferentes: alucinação, cegueira de contexto e inconsistência estilística.

Um humano que escreve uma função que não trata entradas nulas provavelmente sabe melhor e apenas esqueceu. Uma IA que escreve a mesma função genuinamente não sabe se null é possível na sua base de código a menos que você tenha dito explicitamente. Essa distinção importa porque a correção é diferente: um humano precisa de um lembrete, mas a IA precisa de uma restrição codificada no prompt ou capturada na revisão.

Entender essa diferença é a base da revisão eficaz de código de IA. Você não está verificando se o desenvolvedor foi cuidadoso. Você está verificando se a IA tinha contexto suficiente para produzir código correto e se sua saída corresponde às convenções implícitas da sua base de código que ela não podia ver.

Item 1 da lista: APIs e imports alucinados

O problema mais comum em código gerado por IA é o uso de bibliotecas, funções ou APIs que não existem. Modelos de IA são treinados para produzir código plausível, e eles gerarão confiantemente imports para pacotes que nunca foram publicados e chamarão métodos que nunca existiram. Isso não é malicioso — é o modelo interpolando entre pacotes reais que viu durante o treinamento e inventando uma ponte que parece razoável.

// Código gerado por IA que parece plausível mas importa uma função inexistente
import { renderAsync } from 'react-dom'; // renderAsync não existe
import { optimize } from 'lodash/fp/string'; // Este caminho não existe no lodash

// O que você realmente precisa
import { renderToString } from 'react-dom/server';

A correção para isso é simples mas importante: verifique cada import e cada chamada de API contra a documentação real. Não presuma que porque o código compila, as APIs estão corretas — algumas funções alucinadas têm assinaturas de aparência razoável que passam na verificação do TypeScript mas falham em runtime. A revisão deve incluir uma verificação rápida de sanidade em qualquer import que você não reconheça.

Item 2 da lista: Tratamento de erros ausente

Modelos de IA tendem a gerar o caminho feliz. Eles são notavelmente bons em escrever a lógica principal de uma função — o loop, a transformação, o valor de retorno — e notavelmente ruins em tratar o que acontece quando as coisas dão errado. Requisições de rede carecem de blocos catch. Operações de arquivo carecem de tratamento de erros. Funções assíncronas carecem de manipuladores de rejeição.

Isso não acontece porque a IA não sabe escrever tratamento de erros. Se você pedir explicitamente, a IA produzirá lógica try-catch completa. A questão é que o comportamento padrão do modelo é escrever a versão funcional mais simples, e o tratamento de erros não faz parte desse padrão. Toda revisão de código gerado por IA deve incluir uma passada que olhe apenas para os caminhos de erro.

• Toda função assíncrona deve ter um catch ou manipulador de rejeição.
• Toda chamada de API externa deve tratar erros de rede, timeouts e formatos de resposta inesperados.
• Toda transformação de dados deve tratar null, undefined e tipos inesperados.
• Toda operação de arquivo ou banco de dados deve tratar erros de permissão e recursos ausentes.

Uma técnica útil é executar um teste simples: remova os blocos try-catch do código gerado por IA e veja se a lógica restante ainda faz sentido. Se fizer, a IA provavelmente não pensou profundamente sobre tratamento de erros. Se a lógica depende do tratamento de erros para funcionar, a IA o integrou adequadamente.

Item 3 da lista: Incompatibilidades de estilo e convenção

Toda base de código tem convenções de estilo não escritas. A equipe usa retornos antecipados, não ifs aninhados. Mensagens de erro seguem um formato específico. Nomes de variáveis usam um padrão particular. Modelos de IA treinados em milhões de repositórios públicos gerarão código que reflete a média estatística de todos esses repositórios, não as convenções específicas da sua base de código.

O resultado é código que funciona mas parece estranho. Ele usa uma convenção de nomenclatura diferente, uma estrutura de módulo diferente ou um padrão de tratamento de erros diferente do código ao redor. Esse tipo de inconsistência se acumula rapidamente — cinco funções geradas por IA escritas com cinco estilos implícitos diferentes criam uma base de código que parece incoerente e é mais difícil de manter.

A melhor mitigação é incluir exemplos de estilo em seus prompts. Cole uma função representativa do mesmo módulo e diga use este estilo. Isso dá à IA uma referência concreta que substitui seu padrão de treinamento. Durante a revisão, verifique se o código gerado poderia ter sido escrito pela mesma pessoa que escreveu o módulo ao redor.

Item 4 da lista: Superengenharia e abstração desnecessária

Modelos de IA têm um forte viés em direção à abstração. Dado um problema simples, eles frequentemente gerarão uma hierarquia de classes, uma interface, uma fábrica e três funções utilitárias — onde uma única função teria sido suficiente. Essa tendência vem dos dados de treinamento, que super-representam bibliotecas de código aberto bem estruturadas e sub-representam scripts simples e funções pontuais.

Modelos de IA tendem à superengenharia. Sua revisão deve tender à simplicidade. Toda abstração que a IA introduziu precisa justificar sua existência contra uma alternativa mais simples.

Durante a revisão, pergunte-se: este código precisa de uma classe, ou uma função funcionaria? Esta interface é usada por mais de uma implementação? Extrair este utilitário economizaria repetição suficiente para justificar a indireção? Se a resposta para qualquer uma destas for não, a IA provavelmente superengenhou, e a versão mais simples é melhor.

Item 5 da lista: Vulnerabilidades de segurança

Modelos de IA são treinados em código que contém vulnerabilidades de segurança. Eles aprendem padrões desse código, incluindo os vulneráveis. Embora modelos modernos sejam melhores em evitar problemas óbvios como injeção de SQL, eles ainda produzem código com problemas sutis de segurança que um revisor precisa capturar.

• Verifique se há segredos hardcoded, chaves de API ou credenciais no código gerado.
• Confirme se a entrada do usuário é validada e sanitizada antes do uso.
• Verifique se as verificações de autenticação e autorização estão presentes em operações protegidas.
• Garanta que as consultas SQL geradas usam statements parametrizados, não concatenação de strings.
• Confirme se caminhos de arquivo não são construídos a partir de entrada não confiável sem sanitização.

Uma passada de revisão focada em segurança é inegociável para código gerado por IA que lida com dados sensíveis ou entrada de usuário. A IA não sabe quais partes do seu sistema são críticas para segurança a menos que você diga a ela. Em caso de dúvida, execute uma ferramenta de análise estática sobre o código gerado antes de mesclar.

Item 6 da lista: Consistência com a arquitetura existente

Modelos de IA veem cada requisição isoladamente. Eles não sabem que sua equipe concordou no último trimestre em usar React Query para todas as buscas de dados, que a API sempre retorna chaves em camelCase, ou que o projeto usa um padrão específico de gerenciamento de estado. O código que geram será internamente consistente mas pode violar decisões arquiteturais que não estão visíveis no arquivo atual.

É aqui que o revisor humano adiciona mais valor. Você conhece as decisões documentadas em seus ADRs, os padrões que emergiram de discussões da equipe e as restrições de design que não estão capturadas em nenhum arquivo único. Revise o código gerado por IA contra essas restrições invisíveis, não apenas contra correção e estilo.

Construindo um processo de revisão sustentável

Conforme a IA gera mais da sua base de código, o processo de revisão precisa escalar. Uma equipe de quatro revisando cada linha gerada por IA manualmente vai se esgotar. A abordagem sustentável combina verificações automatizadas com revisão humana focada.

Verificações automatizadas devem capturar imports alucinados, violações de estilo, tratamento de erros ausente e problemas comuns de segurança antes que um humano veja o código. Isso reduz a revisão específica de IA a um conjunto menor de preocupações: consistência arquitetural, decisões de design e os problemas sutis que linters não conseguem detectar.

O objetivo não é eliminar a revisão humana de código gerado por IA. É tornar essa revisão tão eficiente quanto possível, filtrando os problemas que ferramentas podem capturar automaticamente e reservando a atenção humana para os julgamentos que apenas humanos podem fazer. Com o processo certo, revisar código gerado por IA se torna mais rápido e mais confiável do que revisar código escrito por humanos — porque os erros da IA são mais previsíveis.