Este Prompt Obtém Revisões de Código de Engenheiro Sênior de Qualquer IA
Why this prompt matters
Generic 'review my code' prompts produce generic responses: vague suggestions, no line references, no prioritisation. This prompt enforces a specific output structure that separates critical bugs from architecture concerns from style improvements — the same mental model a senior engineer uses when reviewing a PR. The 'What's Done Well' section is intentional: it keeps the feedback calibrated and makes it easier to act on criticism when you also know what to preserve.
What we use it for
Developers who want high-quality code review feedback without blocking on a colleague's availability. Works for any language or framework — paste the function, class, or diff and get structured, specific feedback in seconds.
Prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows: **Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions): For each: state the line number, explain precisely why it's a problem, and show the corrected code. **Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain): 1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode. **Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better): Practical, specific suggestions. Reference line numbers. Show before/after where relevant. **What's Done Well**: 2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note. Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why. [PASTE YOUR CODE HERE]
Pedir a uma IA para "revisar meu código" produz o mesmo resultado genérico todas as vezes: uma lista de coisas a considerar, sem priorização, sem referências de linha, e conselhos que poderiam se aplicar a qualquer base de código. O prompt abaixo resolve isso impondo a estrutura exata que um engenheiro sênior usa ao fazer uma revisão real de Pull Request.
O prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows:
**Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions):
For each: state the line number, explain precisely why it's a problem, and show the corrected code.
**Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain):
1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode.
**Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better):
Practical, specific suggestions. Reference line numbers. Show before/after where relevant.
**What's Done Well**:
2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note.
Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why.
[PASTE YOUR CODE HERE]Como usar
Substitua [PASTE YOUR CODE HERE] pela função, classe, módulo ou diff que você deseja revisar. Funciona melhor com Claude Sonnet, GPT-4o e Gemini 2.5 Pro — todos têm janela de contexto suficiente para lidar com arquivos de até algumas centenas de linhas sem precisar dividi-los.
Para arquivos maiores, cole a seção mais crítica (a função com o bug, a nova classe, o método alterado) em vez do arquivo inteiro. Se o contexto for importante, adicione uma breve descrição antes do código: "Este é um middleware Express.js em Node.js que lida com autenticação. O esquema de banco de dados relevante é users(id, email, password_hash, role)."
Por que a estrutura importa
A estrutura de quatro seções reflete como engenheiros experientes priorizam o feedback. Critical Issues são bloqueadores — devem ser corrigidos antes do merge. Architecture Concerns não são bloqueadores hoje, mas tornam-se bloqueadores em escala. Improvements são para a passagem opcional. Separar esses itens impede o modo de falha comum da revisão de código por IA, onde uma critica de estilo recebe o mesmo peso que uma vulnerabilidade de SQL injection.
A instrução de mostrar o código corrigido (não apenas descrever a correção) é a restrição mais importante. Sem ela, revisores de IA tendem a apontar o problema — "o tratamento de erros aqui poderia ser melhorado" — sem dizer o que digitar. O requisito de código corrigido força a especificidade.
Adaptação para contextos específicos
Adicione contexto no topo do prompt para melhores resultados: especifique a linguagem e o framework, o ambiente de implantação (serverless, contêineres, embarcado), restrições de desempenho ou convenções da equipe. Para código sensível à segurança, adicione "Preste atenção especial à validação de entrada, SQL injection, XSS e casos limite de autenticação" na seção Critical Issues. Para caminhos críticos de desempenho, adicione "a função é chamada 10.000 vezes por segundo em produção."
O prompt funciona em qualquer linguagem de programação. Foi testado em Python, TypeScript, Go, Rust, Java e SQL com resultados consistentes em todos os três modelos de fronteira.