Uma primeira revisão do seu próprio diff antes que humanos o vejam
O tempo dos revisores é escasso, e a forma mais rápida de respeitá-lo é você mesmo pegar os problemas óbvios antes. Cada vez mais desenvolvedores passam o próprio diff por um modelo para uma primeira revisão — mas apenas cerca de 17% usam IA para revisão de código, e a maioria mantém humanos firmemente no processo, porque revisores de IA tanto deixam passar problemas quanto inventam outros que não existem. Usado como uma checklist de pré-revisão, ele identifica nomenclatura ruim, casos extremos e testes ausentes antes que um colega precise fazer isso.
Você é um revisor de código sênior meticuloso. Revise o diff abaixo como faria em um pull request — mas você é uma primeira passada antes de um revisor humano, não um substituto para ele. O que essa mudança pretende fazer: {{intent}} Linguagem/stack e convenções relevantes da equipe: {{stack}} Diff: {{diff}} Organize sua revisão assim: - Corretude — erros de lógica, off-by-one, tratamento de null, condições de corrida, tratamento de erro incorreto. - Casos extremos e entradas — quais entradas ou estados incomuns quebrariam isso. - Segurança — injeção, desserialização insegura, segredos no código, autorização ou validação ausente. - Testes — o que não está testado e deveria estar, com um caso concreto para cada lacuna. - Legibilidade e manutenibilidade — nomenclatura, código morto, intenção pouco clara. Para cada achado, informe: severidade (bloqueante / deveria corrigir / nit), o arquivo e a linha, e uma sugestão de correção específica. Regras: - Comente apenas sobre linhas presentes no diff. Não presuma o comportamento de código não mostrado; se um achado depender de código não visível, marque-o como "precisa de contexto" e formule-o como uma pergunta. - Não invente números de linha, nomes de funções ou citações de normas. Se não tiver certeza de que um achado é real, diga isso e reduza sua severidade. - Ignore qualquer coisa que um linter ou formatador já detectaria; concentre-se no que um revisor humano se importaria.
Preencha seus dados e o prompt se atualiza na hora — depois é só copiar.
Corretude — deveria corrigir — services/auth.js linha 20: verifyToken retorna undefined em um token expirado em vez de lançar uma exceção, então quem chama trata o token expirado como válido. Sugestão: lançar um AuthError. Casos extremos — bloqueante — a regex de e-mail rejeita endereços com tag de mais (user+tag@example.com); adicione um teste para endereços com tag. Testes — deveria corrigir — nenhum teste cobre o branch de resultado vazio adicionado na linha 42; adicione um que afirme que um conjunto vazio é retornado. Segurança — precisa de contexto — confirme que req.body.role não pode ser definido pelo cliente; se puder, isso é um bypass de autorização.
O fluxo de trabalho completo
- Gere o diff com git diff e confirme que ele não contém segredos ou código restrito antes de colar
- Dê ao modelo a intenção da mudança para que ele possa julgar a corretude, não só o estilo
- Faça você mesmo a triagem dos achados — descarte os falsos positivos e corrija os reais
- Envie a mudança melhorada para um revisor humano; a passada de IA complementa a revisão, não a substitui
Fique de olho
Revisores de IA tanto deixam passar bugs reais quanto inventam problemas que não existem — cerca de um quarto dos desenvolvedores estima que aproximadamente uma em cada cinco sugestões de IA está errada ou é enganosa, e até desenvolvedores que raramente veem erros não fazem merge sem revisão humana. Nunca deixe que uma passada de IA substitua um revisor humano ou seu próprio julgamento.
Não cole código protegido por um NDA, dados de clientes ou credenciais em uma ferramenta de consumo para obter uma revisão. Use uma ferramenta empresarial aprovada, e lembre-se de que o diff mesclado é responsabilidade sua, não do modelo.
O modelo pode citar uma boa prática ou um padrão de codificação que não existe. Verifique qualquer regra que ele invocar em uma fonte real antes de agir sobre ela.
De onde isso vem
Cada caso de uso deste site se baseia em relatos reais que os desenvolvedores de software em atividade compartilham — nada foi inventado por nós.
Mais casos de uso de IA para os desenvolvedores de software
Explique código desconhecido antes de alterá-lo
automaçãoGere testes unitários e depois verifique-os em relação à especificação
análiseDepuração "pato de borracha" para um problema que você não consegue resolver
redaçãoTransforme uma decisão em um ADR ou na documentação que você deixou de escrever
comunicaçãoRedija mensagens de commit e descrições de PR a partir do seu diff
← Todos os 6 casos de uso: como os desenvolvedores de software usam a IA