Code review de código gerado por IA: guia prático

Code review de código gerado por IA é a revisão humana, apoiada por ferramentas, de código que um modelo escreveu — com foco no que a IA erra com mais frequência: segurança, regras de negócio implícitas e dependências inventadas. A revisão tradicional pressupõe que o autor entendeu o que escreveu; com código gerado, essa premissa deixa de valer, e o revisor passa a ser a primeira pessoa a entender de fato o que está no commit. Este guia mostra o que muda, traz um checklist por camada e propõe um modelo de aprovação por nível de risco, tanto para times de engenharia quanto para apps criados por quem não é desenvolvedor. Ele complementa o pilar vibe coding nas empresas e o checklist de segurança do vibe coding.

O que muda na revisão quando a IA escreve o código

Na revisão tradicional, o revisor avalia decisões de alguém que se responsabiliza por elas. No código gerado por IA, três coisas mudam.

• O autor pode não saber explicar o código. Em vibe coding, quem pediu a funcionalidade muitas vezes não leu cada linha. A pergunta "por que você fez assim?" pode não ter resposta.
• O volume cresce. Quando gerar é barato, o número de linhas por pull request aumenta, e a revisão vira o gargalo.
• Os erros têm outro perfil. O código costuma estar sintaticamente correto e funcionar no caminho feliz, mas falhar em segurança e em casos de borda.

Os dados de segurança dão a dimensão. O relatório GenAI Code Security da Veracode, de julho de 2025, testou mais de 100 modelos de linguagem em quatro linguagens e encontrou que 45% das amostras falharam em testes de segurança e introduziram vulnerabilidades do OWASP Top 10; por linguagem, a taxa de falha foi de 72% em Java, 45% em C#, 43% em JavaScript e 38% em Python. A análise não encontrou melhora com modelos maiores ou mais novos: o desempenho de segurança ficou estável, mesmo com código funcionalmente melhor (Veracode, 2025 GenAI Code Security Report). A conclusão prática: a qualidade funcional melhora, mas a segurança não vem de graça — ela depende do processo de revisão.

Esse acúmulo é parte da dívida técnica do vibe coding: código que ninguém revisou hoje é código que ninguém sabe manter amanhã.

Checklist de code review por camada

Revise em camadas, da mais barata de verificar à mais cara. Cada camada tem perguntas objetivas.

1. Intenção e requisito

• O código faz o que o pedido descreve — e só isso? Modelos adicionam funcionalidades não pedidas.
• Há regras de negócio implícitas que o prompt não continha (prazos, exceções, alçadas)?
• O comportamento nos casos de borda (lista vazia, valor nulo, usuário sem permissão) foi definido ou apenas assumido?

2. Segurança

• Segredos: há chaves, tokens ou senhas no código ou em arquivos versionados?
• Entrada de dados: toda entrada externa é validada e escapada? O relatório da Veracode destaca falhas recorrentes de defesa contra cross-site scripting nas amostras geradas.
• Autenticação e autorização: o acesso é verificado no servidor, e não só escondido na interface?
• Dependências: os pacotes existem de fato, são mantidos e estão na versão correta? Modelos podem sugerir bibliotecas inexistentes ou desatualizadas.

3. Corretude e testes

• Existem testes? Foram escritos pela IA contra o próprio código (o que só confirma o comportamento atual) ou derivam do requisito?
• Os testes cobrem falhas, não só o caminho feliz?
• O código lida com erros de forma explícita, ou os engole silenciosamente?

4. Manutenibilidade

• Outra pessoa consegue entender o código sem o prompt original? Nomes, estrutura e comentários importam.
• Há duplicação de lógica que já existe no repositório? Modelos tendem a recriar em vez de reutilizar.
• O código segue os padrões do projeto?

5. Operação

• Há logs úteis, sem dados pessoais?
• Há tratamento de falha de serviços externos (tempo limite, nova tentativa)?
• O custo de execução é previsível?

Automatize o que dá, reserve o humano para o que importa

A revisão humana é cara; o objetivo é gastá-la onde ela agrega mais. Uma divisão de trabalho que funciona:

Verificação	Quem faz	Quando
Formatação, lint, tipos	Ferramenta	A cada commit
Varredura de segredos	Ferramenta	A cada commit
Dependências vulneráveis	Ferramenta	A cada pull request
Análise estática de segurança (SAST)	Ferramenta	A cada pull request
Testes automatizados	Ferramenta	A cada pull request
Intenção, regra de negócio, casos de borda	Pessoa	Em todo pull request
Arquitetura e decisões de design	Pessoa sênior	Mudanças estruturais
Segurança de fluxo crítico (pagamento, dados pessoais)	Pessoa + segurança	Sempre

A IA também pode ajudar a revisar, como um primeiro filtro que aponta suspeitas, mas não como o único revisor: um modelo revisando o código de outro modelo compartilha pontos cegos. Trate o resultado como sugestão e mantenha a decisão com uma pessoa.

Quem aprova: um modelo por nível de risco

Aprovação única para tudo cria gargalo ou brecha. Um modelo em três níveis, no mesmo espírito da matriz de risco do vibe coding:

Nível	Exemplo	Quem aprova
Baixo	Ferramenta interna sem dados sensíveis, uso individual	Autor + checagens automáticas
Médio	App de equipe com dados internos	Segundo par de olhos (colega treinado) + checagens automáticas
Alto	Qualquer coisa exposta a cliente, com dado pessoal, financeiro ou integrada a sistema crítico	Engenheiro sênior + revisão de segurança

Isso conversa com o novo papel de TI no vibe coding: TI deixa de ser a fila e passa a definir as regras e os níveis, e aprovar o que é de nível alto. O papel do sênior também muda, como mostra vibe coding e o novo papel do desenvolvedor sênior. E o conjunto de apps em produção precisa estar visível, como detalha a governança de portfólio de vibe coding.

Code review quando quem pede não é desenvolvedor

Em vibe coding feito por áreas de negócio, quem criou o app não consegue revisar o código. Três ajustes:

1. Revise o comportamento, não só o código. O criador testa o app com um roteiro de casos reais, incluindo entradas inválidas, e documenta o resultado.
2. Deixe o ambiente fazer parte do controle. Plataformas com governança nativa limitam o que o app pode acessar, reduzindo o que a revisão precisa cobrir. No caso do Replit, veja Replit Enterprise e a governança nativa.
3. Escale para alguém técnico no que for crítico. O nível alto do modelo acima existe para isso.

A Jetpacks, parceira oficial da Replit no Brasil, conduz imersões e workshops que ensinam justamente essa divisão: quem constrói testa e documenta; quem é técnico revisa o que é crítico. A capacitação de quem já programa, para revisar código gerado, está em capacitação técnica de desenvolvedores em IA.

Como medir se o code review está funcionando

Sem métrica, a revisão vira ritual. Quatro indicadores simples:

• Vulnerabilidades encontradas antes versus depois da produção: o objetivo é que quase tudo seja pego antes.
• Tempo de revisão por pull request: se crescer sem parar, o volume gerado está acima da capacidade de revisão.
• Taxa de retrabalho: quantos pull requests voltam por problema de intenção ou de regra de negócio.
• Incidentes atribuídos a código gerado sem revisão: idealmente, zero.

FAQ

Preciso revisar todo código gerado por IA?

Sim, mas com profundidade proporcional ao risco. Um script pessoal sem dados sensíveis pode passar só por checagens automáticas e leitura do autor; código exposto a cliente ou que trata dado pessoal exige revisão humana técnica. O que não se recomenda é publicar sem nenhuma verificação.

A IA pode revisar o código que ela mesma gerou?

Pode ajudar como primeiro filtro, mas não deve ser o único revisor. Modelos tendem a compartilhar pontos cegos, e a decisão de aprovar precisa ficar com uma pessoa responsável.

Quais os erros mais comuns em código gerado por IA?

Falhas de segurança (45% das amostras no estudo da Veracode de 2025), regras de negócio implícitas ignoradas, tratamento de erro fraco, duplicação de lógica e dependências inexistentes ou desatualizadas.

O código gerado por IA é menos seguro que o escrito por pessoas?

O estudo da Veracode mostra que quase metade das amostras geradas por modelos introduziu vulnerabilidades do OWASP Top 10 e que modelos maiores não melhoraram esse resultado. O estudo não compara diretamente com código humano; o ponto prático é que a revisão e os testes de segurança continuam necessários.

Quanto tempo a revisão de código gerado por IA adiciona ao processo?

Depende do volume e do nível de risco. Automatizar lint, varredura de segredos, dependências, SAST e testes tira da pessoa o que máquina faz melhor e deixa para ela intenção, regra de negócio e arquitetura. Meça o tempo por pull request para ajustar.

Quem deve aprovar um app criado por uma área de negócio?

Depende do nível de risco. Em nível baixo, o autor com checagens automáticas; em nível médio, um segundo par de olhos treinado; em nível alto (cliente, dado pessoal, sistema crítico), um engenheiro sênior e revisão de segurança.

Conclusão: velocidade de geração exige disciplina de revisão

Quando o código passa a custar quase nada para ser gerado, o gargalo e o risco se deslocam para a revisão. Empresas que definem níveis de risco, automatizam o que é mecânico e reservam pessoas para intenção, regra de negócio e segurança crítica ganham velocidade sem acumular dívida. Para desenhar esse modelo de aprovação na sua empresa, agende o diagnóstico gratuito da Jetpacks: uma conversa de 30–45 minutos para mapear o uso atual e definir os níveis de revisão.