Code review

Como revisar código gerado por IA antes do merge

Código gerado por IA acelera a entrega. Também aumenta o risco de passar erro besta, falha de segurança e mudança escondida no merge. Se você não entende o diff, não aprova o PR.

O caminhoLer tarefaVer diffRodar testesChecar dependênciasValidar segurançaComparar comportamento

Passo01

Comece pela tarefa, não pelo código

Foco: Revise contra o que foi pedido. IA costuma resolver coisa além do escopo e misturar refatoração com correção.

Faça 1: Leia a tarefa original e resuma em uma frase o resultado esperado

Faça 2: Marque o que está fora do escopo antes de abrir o diff

Faça 3: Peça para separar mudanças grandes em PRs menores quando houver mistura de assuntos

Frase pronta: “Explique em uma frase qual problema este PR resolve e o que ficou fora do escopo.”

Passo02

Leia o diff trecho por trecho

Foco: Não confie no texto do PR. Vá hunk por hunk e trate cada bloco como suspeito até entender o motivo da mudança.

Faça 1: Revise cada arquivo alterado na ordem do diff

Faça 2: Pare em toda linha que você não entendeu na primeira leitura

Faça 3: Rejeite mudanças amplas demais para a tarefa, mesmo quando parecem melhorar o código

Frase pronta: “Explique este bloco linha por linha, o motivo da mudança e qual alternativa você descartou.”

Passo03

Procure os erros comuns de código gerado por IA

Foco: Os padrões se repetem. O objetivo é achar rápido o tipo de erro que aparece com frequência em código sugerido por modelo.

Faça 1: Verifique se há APIs inventadas, nomes de pacote que não existem ou uso desatualizado de biblioteca

Faça 2: Procure helpers duplicados em vez de reaproveitamento do que já existe no projeto

Faça 3: Confirme tratamento de edge cases, erros e remoção silenciosa de comportamento em refactors

Frase pronta: “Liste os riscos deste diff: APIs inventadas, uso desatualizado, duplicação, edge cases sem tratamento e comportamento removido.”

Passo04

Rode os testes você mesmo

Foco: Teste verde no texto do agente não basta. IA também pode enfraquecer teste ou fazer teste que valida implementação em vez de comportamento.

Faça 1: Execute os testes localmente antes de aprovar

Faça 2: Leia os testes novos e veja se validam comportamento observável

Faça 3: Procure asserts enfraquecidos ou alterações feitas só para o teste passar

Frase pronta: “Mostre quais testes cobrem comportamento real e quais partes do diff continuam sem cobertura adequada.”

Metade do guia. Agora, mire na vaga certa.

Na mentoria, eu monto com você o plano de estudo para a vaga que você quer, ajusto o seu LinkedIn e te ensino a achar as melhores vagas.

Passo05

Cheque dependências e manutenção

Foco: Toda dependência nova merece desconfiança. Pacotes alucinados podem nem existir, e atacantes podem registrar nomes inventados, o que é conhecido como slopsquatting.

Faça 1: Verifique se cada dependência nova existe de fato

Faça 2: Confirme se o pacote é mantido e compatível com o uso proposto

Faça 3: Questione toda dependência adicionada para algo que o projeto já resolve internamente

Frase pronta: “Justifique cada nova dependência: por que ela existe, se é mantida e por que não reutilizamos código do projeto.”

Passo06

Faça a revisão de segurança no diff

Foco: Código gerado por IA pode introduzir falhas simples e perigosas. Segurança aqui é revisão básica e objetiva do que entrou no PR.

Faça 1: Procure secrets expostos, logs excessivos e dados sensíveis em texto claro

Faça 2: Revise entradas de usuário que chegam a SQL, shell ou comandos externos

Faça 3: Valide sanitização, parametrização e limites de escopo em operações críticas

Frase pronta: “Revise este diff com foco em secrets, logging, SQL injection e command injection.”

Passo07

Compare comportamento antes e depois

Foco: Quando houver rewrite ou refactor, o risco principal é perder comportamento sem ninguém notar. O diff pode parecer limpo e ainda assim quebrar regra de negócio.

Faça 1: Execute ou simule o fluxo principal antes e depois da mudança

Faça 2: Liste o que deveria continuar igual após o refactor

Faça 3: Peça evidência de equivalência quando uma parte foi reescrita

Frase pronta: “Compare o comportamento anterior e o atual e aponte qualquer mudança funcional, mesmo que não intencional.”

Perguntas frequentes

Como revisar código gerado por IA de forma prática?

Comece pela tarefa e valide o escopo. Depois leia o diff trecho por trecho, rode os testes você mesmo, confira dependências e faça uma revisão direta de segurança e comportamento.

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

Os mais comuns são APIs ou pacotes inventados, uso desatualizado de biblioteca, edge cases sem tratamento, testes fracos, duplicação de helpers e mudanças além do escopo. Também aparecem remoções silenciosas de comportamento em refactors.

Como avaliar a segurança de código gerado por IA?

Procure secrets expostos, logging excessivo e entradas de usuário chegando de forma insegura a SQL ou comandos. Revise dependências novas com cuidado, porque até nomes de pacote alucinados podem virar risco de slopsquatting.

Posso confiar nos testes enviados junto com código gerado por IA?

Não sem revisar. O agente pode criar testes que confirmam a implementação atual, e não o comportamento esperado, ou enfraquecer asserts para tudo passar. Rode os testes localmente e leia os casos alterados.

Regra de decisão

Responsabilidade por código em produção é humana. Código gerado por IA não recebe passe livre porque foi rápido de produzir.

A regra é simples: se você não consegue explicar o diff em 2 minutos, volta para revisão com o agente.

Revise melhor código com IA e acelere a sua carreira

Saber usar IA sem perder qualidade virou habilidade prática de engenharia. Na mentoria do Lucas, você organiza estudo, melhora posicionamento e aprende a mostrar julgamento técnico nas vagas certas.