Prompt Code Review

Escrevendo prompts de code review para LLMs

Um prompt de code review é a instrução que você dá ao ChatGPT, Claude ou GitHub Copilot Chat para que ele inspecione um diff antes do pull request. A prática explodiu em 2023 com o GitHub Copilot Chat, depois com agentes do Cursor e do Aider, e por fim com serviços gerenciados como CodeRabbit, Greptile e Cody, que entregam comentários inline direto no PR via GitHub Actions. A qualidade do review depende quase inteiramente do prompt: um vago “revise isso” produz checklists genéricas, enquanto um prompt estruturado entrega sugestões acionáveis.

Um template reutilizável que funciona em vários modelos:

Você é um dev sênior {linguagem} revisando este PR.
Código:
```{linguagem}
{código}
```
Revise quanto a:
1. Correção / bugs
2. Problemas de performance
3. Vulnerabilidades de segurança (OWASP Top 10)
4. Legibilidade e manutenção
5. Lacunas de teste
Forneça sugestões acionáveis com referência de linha.

Especificidade vence verbosidade

Prompts genéricos geram feedback genérico. Fixe o style guide (PEP 8, Google Java Style, Airbnb JavaScript, gofmt), a versão do framework (Django 5.0, React 19, Spring Boot 3) e as convenções do projeto (“usamos classes utilitárias Tailwind, nada de CSS modules”). Para contexto multi-arquivo use GitHub Copilot Workspace, Cursor ou Aider — eles puxam arquivos vizinhos para o contexto do modelo automaticamente.

Variantes de prompt por foco específico

• Heurísticas de ORM: “Verifique N+1 queries e falta de select_related / eager-loading.”
• Concorrência: “Procure race conditions, locks ausentes e uso incorreto de async/await.”
• Segurança: “Procure SQL injection, XSS, SSRF, CSRF e autenticação quebrada conforme OWASP Top 10.”
• Performance: “Sugira otimizações do hot path e sinalize loops O(n²).”
• Formatos de saída: JSON estruturado (agentes Cursor), bullets Markdown, comentários inline no PR via gh pr review --comment.

Armadilhas comuns do code review por IA

LLMs não executam código, então ignoram problemas de runtime, testes flaky e bugs específicos do ambiente. Também produzem falsos positivos (sugerem fixes que quebram código funcional), contexto faltante (padrões do projeto desconhecidos do modelo) e APIs alucinadas (métodos que não existem na versão da lib que você usa). Um modelo mental útil é a hierarquia de confiança: modelo ML sozinho < revisor humano sozinho < (modelo + testes passando) < (modelo + humano + testes).

Anti-padrão: aprovação carimbada — tratar “LGTM by AI” como sinal verde. Gera falsa confiança e mergeia bugs críticos. Use o LLM para levantar candidatos, não para decidir.

Caminhos de integração

• GitHub Actions + API Anthropic/OpenAI: on: pull_request + gh pr comment — entrega review automaticamente.
• CodeRabbit, Greptile, Cody, Qodo — serviços gerenciados com UI no PR.
• Continue.dev, Cursor, Aider — review no IDE antes do push.
• Claude no IDE via extensão oficial da Anthropic para VS Code.

Perguntas frequentes

O LLM substitui o revisor humano? Não — complementa. Ele é ótimo para problemas de superfície (estilo, bugs óbvios, checklist de segurança), mas ruim em decisões arquiteturais e em entender intenção de negócio.

É melhor mandar o diff ou o arquivo inteiro? O diff é melhor para contexto de PR (mais curto, focado), mas inclua 5-10 linhas de contexto ao redor de cada mudança. Envie o arquivo inteiro quando o LLM precisar entender a estrutura geral (refactors, rewrites grandes).

O modelo pode auto-aprovar PRs? Tecnicamente sim, na prática perigoso. Use-o para sinalizar riscos e disparar revisão humana. Auto-merge por aprovação de LLM já causou incidentes em produção (falhas de segurança, builds quebrados).

Qual modelo dá os melhores reviews? Claude 3.5 Sonnet, GPT-4o e Gemini 1.5 Pro performam de forma similar em benchmarks. O diferencial é o prompt e o contexto que você fornece — não o modelo.