Review de código gerado por IA: o checklist real antes de aceitar

O problema

Código gerado por IA cria uma ilusão perigosa:

• nomes bons
• estrutura limpa
• comentário convincente
• testes sugeridos

Tudo isso passa sensação de qualidade.

Mas sensação de qualidade não é qualidade.

O modelo frequentemente entrega algo que:

• compila
• parece bem escrito
• passa no caso feliz

e ainda assim:

• assume regra de negócio errada
• mexe em mais coisa do que precisava
• abre um buraco de segurança
• preserva mal comportamento legado importante
• inventa abstração cedo demais

Por isso, review de código gerado por IA não pode ser:

• “parece bom”
• “o teste passou”
• “veio organizado”

Isso é pouco.

Modelo mental

Pense assim:

review de código gerado por IA é menos sobre estilo e mais sobre provar que o diff faz sentido.

Essa frase ajuda porque tira a revisão do campo da aparência.

A pergunta principal deixa de ser:

• “esse código parece profissional?”

e passa a ser:

• “essa mudança está correta, limitada e aceitável para este sistema?”

O review forte tenta responder cinco coisas:

1. o problema foi entendido direito?
2. o escopo ficou controlado?
3. o comportamento está certo além do caso feliz?
4. há risco de segurança, operação ou manutenção?
5. se der ruim, a mudança é observável e reversível?

Se você não consegue responder isso, ainda não deveria aceitar.

Quebrando o problema

Primeiro revise o entendimento do problema

Antes de revisar o código, vale revisar a leitura do problema.

Porque, se o modelo resolveu a coisa errada, o resto já sai torto.

Perguntas úteis:

• o diff realmente ataca o bug ou requisito pedido?
• existe alguma regra de negócio que ficou implícita e não entrou?
• o modelo resolveu um sintoma ou a causa correta?

Esse passo parece básico, mas evita um monte de merge bonito e inútil.

Depois confira se o escopo não expandiu sem autorização

Esse é um padrão muito comum em código gerado por IA.

Você pediu:

• uma validação
• um teste
• um ajuste pequeno

E recebe junto:

• renome de função
• extração de helper
• mudança de mensagem
• reorganização de arquivo
• alteração em outro fluxo

Tudo “faz sentido” localmente.

Mas o diff ficou maior, mais difícil de revisar e mais arriscado do que precisava.

Então uma pergunta central de review é:

• o modelo resolveu só o que eu pedi ou aproveitou para redesenhar metade do módulo?

Se expandiu demais, o certo quase sempre é quebrar a mudança.

Código bonito não substitui validação de comportamento

Talvez esse seja o ponto mais importante.

Em review de código gerado por IA, o risco não está só em erro grotesco.

Está em erro plausível.

Então você precisa olhar para:

• caso feliz
• caso de borda
• falha esperada
• contrato público
• comportamento anterior que precisava ser preservado

Às vezes o diff parece impecável.

Mas falha em algo como:

• null versus string vazia
• permissão insuficiente
• concorrência
• ordenação
• transação parcial
• cache inválido

Review bom tenta forçar esses cantos a aparecer.

Premissas escondidas precisam virar texto explícito

Modelo costuma assumir coisas sem avisar.

Exemplos:

• “esse campo sempre vem preenchido”
• “essa função sempre roda só no backend”
• “esse endpoint nunca recebe payload parcial”
• “essa dependência já existe no projeto”

Se a premissa está errada, a solução pode parecer correta até entrar em produção.

Por isso vale revisar também:

• o que este diff assumiu sem dizer?

Se você não consegue responder, peça esclarecimento ou reduza o escopo da mudança.

Segurança e fronteira de confiança merecem olhar separado

Código gerado por IA frequentemente acerta a forma e erra a fronteira.

Exemplos clássicos:

• confiar em input externo demais
• validar tipo e esquecer autorização
• interpolar valor perigoso
• tratar segredo como string comum
• usar biblioteca ou API de forma insegura

Então, se a mudança toca:

• autenticação
• autorização
• entrada de usuário
• query
• arquivo
• token
• integração externa

vale fazer uma revisão específica de segurança, não só uma revisão geral.

Dependência nova e abstração nova precisam pagar aluguel

Outro padrão comum:

o modelo traz uma solução “sofisticada” sem precisar.

Por exemplo:

• helper novo sem uso claro
• camada extra
• dependência nova
• genericão que piora leitura

Review forte pergunta:

• isso realmente reduz problema aqui ou só aumenta superfície?

Se a abstração não paga custo agora, ela provavelmente entrou cedo demais.

Toda mudança deveria responder: como eu testo e como eu volto?

Esse critério vale para código humano também, mas fica ainda mais importante aqui.

Antes de aceitar, vale saber:

• que testes cobrem a mudança?
• o que eu testaria manualmente?
• se quebrar, rollback é simples?
• consigo observar rápido se a mudança piorou algo?

Se nem isso está claro, você ainda está aceitando no escuro.

Exemplo simples

Imagine um endpoint de criação de cupom.

Você pediu ao modelo uma correção pequena:

• rejeitar desconto negativo
• manter contrato atual
• adicionar testes mínimos

O modelo devolve um diff elegante.

Só que, junto com a validação, ele:

• extrai uma classe nova
• muda nomes de funções
• altera mensagem de erro
• troca a ordem de validações
• mexe em um formatter usado por outro fluxo

Review fraco diria:

“Está mais organizado e os testes passaram.”

Review forte diria:

1. a correção do valor negativo está certa?
2. a API pública continuou igual?
3. por que esse refactor entrou no mesmo diff?
4. a ordem nova de validações muda algum comportamento?
5. esse formatter alterado pode afetar outra tela?
6. dá para separar a correção do refactor?

Perceba o padrão.

O review forte não está brigando com estilo.

Está tentando reduzir risco escondido.

Erros comuns

• Aprovar porque “veio limpo”.
• Usar teste verde como prova suficiente de correção.
• Ignorar mudança de escopo embutida no diff.
• Não revisar premissas que o modelo assumiu sem dizer.
• Aceitar abstração ou dependência nova sem necessidade clara.
• Fazer review superficial em trecho de segurança, dados ou concorrência.
• Tratar código gerado por IA como se a responsabilidade de merge fosse menor.

Como um senior pensa

Quem tem mais maturidade não revisa código gerado por IA como quem revisa texto bonito.

Revisa como mudança de sistema.

O pensamento costuma ser:

“Onde este diff pode estar parecendo certo sem estar suficientemente provado?”

Isso leva a uma revisão mais útil:

• entender o problema antes do código
• cortar expansão de escopo
• forçar casos de borda
• procurar premissa escondida
• revisar segurança e contrato
• manter rollback e observabilidade em mente

Também existe um julgamento importante aqui:

às vezes o melhor review é não aceitar aquele diff do jeito que veio.

E sim:

• pedir quebra em partes
• pedir resposta menor
• pedir só testes
• pedir só análise
• refazer a tarefa com restrição melhor

Isso não é resistência à ferramenta.

É controle de qualidade.

O que o entrevistador quer ver

Quando perguntam sobre revisão de código gerado por IA, normalmente estão avaliando se você:

• mantém critério técnico mesmo com geração rápida
• sabe que risco principal é plausibilidade enganosa
• tem um checklist de aceite que vai além de estilo
• continua assumindo responsabilidade pelo merge

Resposta forte costuma soar assim:

“Eu não reviso código gerado por IA pelo texto do diff. Eu reviso pelo comportamento, pelo escopo e pelo risco. Primeiro vejo se o problema foi entendido certo. Depois checo se o modelo expandiu demais a mudança. Em seguida valido casos de borda, segurança, contrato e facilidade de rollback. Se o diff ficou grande demais, eu quebro antes de aceitar.”

Isso mostra algo importante:

você não usa IA para escapar do review.

Você usa IA e mantém o review como barreira de qualidade.

O problema do código gerado por IA não é parecer ruim. É parecer bom cedo demais.

Se você não aceitaria o mesmo diff vindo de um humano sem mais prova, também não deveria aceitar vindo de um modelo.