Como revisar código depois de Cursor, Claude Code e Codex

Um agente de programação reduz o tempo entre a tarefa e o diff, mas não assume a responsabilidade pelo release. Código escrito por IA não é perigoso por ter uma categoria especial de bug de máquina. Ele produz bugs comuns rapidamente, em vários arquivos, com explicações convincentes. Portanto, a revisão deve começar pelos limites da mudança e por sinais reproduzíveis, não por outro chatbot.

Explique por que cada arquivo alterado pertence ao diff

Peça ao agente um resumo curto e depois compare com o diff real. Remova formatação incidental, atualizações de lockfile sem explicação, código de depuração e mudanças em módulos vizinhos que a tarefa não exige. Divida um diff grande quando possível: esquema de dados, servidor, interface e testes são mais fáceis de avaliar como unidades lógicas separadas.

Localize a nova fonte da verdade. Onde o estado vive agora, quem chama a função e quais caminhos antigos permanecem? Um agente muitas vezes adiciona uma nova camada sem remover ou atualizar a anterior. Buscar pelo nome, pela rota e pelo tipo pode revelar duas implementações concorrentes.

Deixe o compilador e os testes falarem antes de um revisor de IA

Execute formatação, linting, verificação de tipos, testes unitários e testes de integração com os mesmos comandos da CI. Se o projeto não tem essas verificações, isso é um risco separado, não um motivo para substituí-las por um modelo. Uma ferramenta determinística repete uma regra exatamente; um revisor de IA estima problemas prováveis e pode deixar passar algo simples.

Um novo teste deve falhar contra o código antigo e passar depois da correção. Um teste que fica verde nas duas versões talvez não prove nada. Reproduza a falha original para uma correção de bug; para uma funcionalidade, cubra o caminho principal, os limites e a falha de uma dependência.

Playwright valida uma jornada do usuário, não a elegância da implementação

Adicione ou atualize um teste de navegador para um fluxo web crítico. Projetos do Playwright executam diferentes navegadores e ambientes, enquanto o trace viewer preserva etapas, estado do DOM, atividade de rede e capturas de tela para diagnóstico na CI. Codegen é um rascunho útil, mas locators e expectativas devem ser reescritos em torno de comportamentos estáveis e visíveis ao usuário.

Não cubra cada setter com E2E. Trave a jornada cuja falha é cara: login, pagamento, criação de objeto, publicação ou permissões de função. Testes de API e unitários podem cobrir os ramos mais baratos.

Migrações e trabalho em segundo plano precisam de ensaio de rollback

Quando um diff altera o esquema, inspecione linhas existentes, valores nulos, índices, locks e tempo de execução. Execute a migração contra uma cópia com volume realista. Decida se o novo código funciona com o esquema antigo durante um deploy gradual e se a aplicação consegue fazer rollback depois da migração.

Para filas e webhooks, teste tentativas, ordenação, timeouts e conclusão parcial. Agentes escrevem facilmente um caminho feliz em que um evento chega uma única vez. A produção tende a testar o oposto.

Permissões e caminhos de dados importam mais que linhas com aparência suspeita

Rastreie entradas não confiáveis até o banco de dados, sistema de arquivos, shell, HTML e requisições de saída. Verifique a autorização no servidor em vez de depender de um botão oculto. Segredos não devem entrar em um bundle de cliente, logs, uma resposta de erro ou no contexto de um modelo.

Inspecione dependências e código gerado. Uma nova biblioteca amplia a superfície da cadeia de suprimentos e o tamanho do bundle; um pacote parecido pode ser um erro de digitação. Para dados pessoais, verifique minimização, retenção e se registros são enviados a um modelo sem autorização.

Uma segunda IA funciona melhor como oponente com briefing estreito

Depois das verificações convencionais, entregue o diff a um agente revisor separado. Defina uma tarefa precisa: encontrar violações de invariantes, testes ausentes, incompatibilidade de API, condições de corrida ou bypasses de autorização. Exija um arquivo, uma linha e um cenário de falha. “Revise este código” produz muito ruído estilístico.

Não aceite um achado sem reproduzi-lo. Um modelo pode inventar um contrato ou deixar passar uma regra do projeto. Produtos relevantes estão listados na coleção de revisão de código com IA da AIDive, com produtos focados em execução na coleção de testes com IA.

A revisão de release termina com observação após o deploy

Antes do merge, verifique a descrição do PR, a issue vinculada, a documentação, as flags, as métricas e o plano de rollback. Depois do release, monitore mais do que erros de servidor: conversão de etapas, latência, profundidade da fila, taxas de rejeição e invariantes de negócio. Um rollback rápido é mais valioso do que um longo debate com um agente durante um incidente.

A sequência curta é: entender o diff, reduzi-lo, executar verificações determinísticas, reproduzir a jornada crítica, inspecionar dados e acesso separadamente, usar IA como segundo revisor e então fazer o release com observação. A velocidade de geração só importa quando a equipe mantém a capacidade de provar a correção.