Código gerado por IA exige um processo de code review diferente

Code review para código gerado por IA é diferente. Um pull request pode parecer sintaticamente perfeito, passar em todos os testes locais e, ainda assim, estar errado de um jeito difícil de perceber.

Nossos hábitos de review, construídos ao longo de anos lendo código escrito por outras pessoas, não estão preparados para isso. Estamos acostumados a procurar erros de lógica ou problemas de estilo. O que muda agora é que a IA pode gerar centenas de linhas de código que parecem corretas à primeira vista, mas foram construídas sobre suposições erradas.

Isso muda onde está o gargalo no desenvolvimento de software. Escrever código deixou de ser a parte mais lenta. Verificar o que foi gerado passou a ser.

Quando um desenvolvedor consegue gerar grandes volumes de código, o trabalho de quem revisa muda de corrigir erros para validar intenção. O custo de um review superficial também muda. Deixa de ser um bug pequeno e pode virar uma falha arquitetural, um risco de segurança ou um problema de performance que só aparece em produção.

Os custos de confiar em código gerado por IA

Os ganhos imediatos de produtividade com IA são claros. O que vem depois nem sempre é. Estamos começando a ver novos tipos de problema em códigos que parecem corretos à primeira vista, mas foram construídos com uma compreensão frágil ou errada do sistema.

Ignorar falhas nas saídas da IA

Código gerado por IA muitas vezes parece completo. Ele gera funções com docstrings, adiciona tratamento básico de erros e segue a sintaxe geral do código. À primeira vista tudo parece certo, mas detalhes importantes podem estar faltando.

O código geralmente é escrito para um problema genérico, não para o nosso contexto operacional específico. Também podem faltar as verificações extras que um engenheiro mais experiente costuma adicionar com base na sua experiência. Por exemplo, talvez ele não considere o caso de um serviço downstream retornar um objeto malformado ou dar timeout sob carga, porque essas falhas são específicas do nosso sistema, não dos dados de treino. O código gerado pode até ter um bloco `try/catch` para uma falha de rede, mas não vai validar o payload de uma resposta bem-sucedida, porém corrompida.

Outro problema comum é a introdução de bibliotecas pouco conhecidas ou fora do padrão. Um modelo de IA pode resolver um problema usando um pacote de nicho que viu nos dados de treino, adicionando uma nova carga de manutenção e uma nova superfície de segurança sem que o desenvolvedor perceba. O código funciona, mas agora o time é responsável por uma dependência que não escolheu.

Por que os processos atuais de code review falham

Nossas práticas de code review foram construídas em torno de uma premissa: existe um autor humano cujo raciocínio pode ser questionado. Fazemos review olhando lógica e manutenibilidade, confiando que o autor tem um modelo mental do sistema. Código gerado por IA quebra tudo isso.

A ilusão de correção

O maior desafio é que código de IA parece correto. Muitas vezes ele é mais limpo e mais consistente em estilo do que o código de um desenvolvedor júnior. Essa estética pode colocar quem revisa em uma falsa sensação de segurança. A gente procura bugs que são óbvios, mas deixa passar os que são estratégicos.

Uma IA pode gerar um script de transformação de dados perfeitamente funcional. Quem revisa confirma que ele funciona com os dados de exemplo. O que passa batido é que o script carrega o dataset inteiro na memória, uma solução que funciona com um arquivo de teste de 100 registros, mas vai derrubar o servidor quando rodar contra o banco de produção com 10 milhões de registros. O código não está tecnicamente com bug, mas é inviável do ponto de vista operacional.

Isso piora quando o código inclui muitos trechos repetidos. Uma IA consegue produzir um controller de 200 linhas que parece seguir os padrões REST do time. No meio desse código pode haver uma query direta ao banco, contornando a service layer e sua lógica de validação.

Um revisor humano, ao ver padrões familiares, pode passar rápido pelo código e não perceber a violação arquitetural. Não existe uma intenção autoral para questionar, apenas uma saída para validar. Você não consegue rastrear o “raciocínio” da máquina, porque ele não existe.

Ignorar regressões de segurança e performance

Modelos de IA são treinados com código público, incluindo exemplos com vulnerabilidades conhecidas e padrões pouco eficientes. Por isso, eles podem repetir essas soluções sem avaliar o impacto que isso traz.

Um estudo de Stanford de 2021 mostrou que desenvolvedores usando assistentes de IA tinham mais chance de escrever código inseguro do que aqueles que não usavam.

A IA pode sugerir um algoritmo de criptografia depreciado porque ele aparecia em dados de treino mais antigos. Pode gerar código suscetível a um ataque de negação de serviço por expressão regular (ReDoS) ao sugerir um padrão de regex complexo copiado de um fórum público. Não são erros simples. São vulnerabilidades herdadas que linters e testes básicos muitas vezes não detectam.

Regressões de performance também são comuns e difíceis de identificar. A IA costuma resolver o problema imediato, sem considerar o impacto na performance do sistema como um todo. Ela pode gerar uma solução para processar itens em uma lista usando loops aninhados, resultando em complexidade O(n²). Isso passa no teste unitário com 10 itens, mas faz a aplicação praticamente parar com 10.000.

Um desenvolvedor humano, com contexto sobre a escala do sistema, provavelmente evitaria isso. A IA não tem esse contexto.

O mesmo acontece com tratamento de erros. Em uma função, a IA pode usar exceções com base em exemplos de treino. Em outra, pode retornar null ou códigos de erro, criando um comportamento inconsistente e um sistema mais frágil.

Adaptando o code review para a era da IA

Para lidar com esses novos riscos, precisamos mudar o foco do code review de correção de código para verificação de código. A pergunta passa a ser: “Esse código faz a coisa certa, pelos motivos certos, dentro das restrições do nosso sistema?” Todo bloco de código gerado por IA deve ser tratado como se tivesse vindo de um desenvolvedor novo que não faz ideia de como seu projeto funciona.

Priorize intenção acima de sintaxe

O processo de review precisa começar antes de você olhar o código. As primeiras perguntas de quem revisa para quem criou a mudança deveriam ser: “Qual foi exatamente o prompt que você usou?” e “Que problema você estava tentando resolver?”. Isso reposiciona o review em torno do que o código deveria fazer.

Primeiro, verifique se o código gerado realmente resolve o problema pretendido. É comum a IA resolver um problema parecido, mas sutilmente diferente. A solução pode estar correta para o prompt, mas errada para o requisito de negócio.

Depois, veja se a implementação da IA se encaixa na arquitetura do sistema. Se a tarefa era adicionar uma regra simples de validação, ela alterou corretamente um serviço já existente ou gerou uma nova classe e fragmentou a lógica?

Por fim, percorra mentalmente o fluxo de dados. Em qualquer função não trivial, siga os dados da entrada até a saída. O que acontece se uma entrada vier nula? Se uma string estiver vazia ou tiver caracteres estranhos? Se uma chamada de rede falhar? Esse rastreamento deliberado força uma análise mais profunda do que uma leitura simples.

Um checklist para revisar código gerado por IA

Para tornar isso sistemático, os times deveriam adotar um checklist focado em verificação para qualquer pull request com muito código gerado. Isso tira o review do campo subjetivo e leva para um processo estruturado.

• Ele entende o nosso negócio? A IA não tem contexto de domínio e vai preencher lacunas com suposições genéricas. Por exemplo, ela assumiu que um usuário tem apenas um endereço de e-mail quando nosso sistema permite vários?
• Os testes são bons mesmo? Se a IA gerou os testes, eles cobrem só o happy path? Testes gerados por IA são um começo, mas raramente cobrem edge cases ou modos de falha específicos do seu sistema. A expectativa de cobertura de testes para código gerado por IA deveria ser maior, não menor.
• Está seguro? Trate o código como entrada não confiável. Ele introduziu novas dependências, e elas foram avaliadas? Ele trata entrada de usuário com segurança? Ele usa bibliotecas criptográficas e aprovadas?
• É eficiente? Qual é a complexidade algorítmica das funções geradas? Ele faz acesso a dados dentro de um loop? É eficiente em memória? Quem revisa agora também é responsável pela análise de performance que o gerador ignorou.
• Um ser humano consegue manter isso? O código é fácil de entender? A IA escolheu um algoritmo mais complicado do que o necessário? O código está documentado para explicar por que ele funciona desse jeito, não só o que ele faz? A pessoa que usou o prompt precisa conseguir explicar a saída. Se não consegue, não faça merge.
• Ele segue os padrões do projeto? A IA não conhece seus padrões arquiteturais específicos, bibliotecas preferidas ou estratégias de tratamento de erro. Quem revisa precisa garantir que esses padrões sejam seguidos, verificando se o código gerado se integra bem ao restante do sistema, em vez de introduzir lógica inconsistente.

Essa abordagem exige mais de quem revisa. O papel do revisor deixa de ser apenas olhar estilo ou sintaxe. Ele precisa entender se o código realmente faz sentido dentro do sistema.

Caso contrário, a base de código começa a acumular erros difíceis de perceber e problemas que só aparecem depois em produção.

A velocidade de geração de código com IA é uma grande vantagem, mas só funciona com bons processos de code review.