Review automático de código
OpenClaw é seu Senior Engineer — online 24/7, lê cada linha de código com atenção
A realidade de Code Review
Fica esperando Review até quando cai toda a flor
Abre PR, Senior tá ocupado em outro projeto. Dois dias depois faz Review mas comenta só "LGTM". Ou espera muito, ou não lê de verdade — qual a utilidade dessa Review?
O pior é que todo mundo do time tem um padrão diferente. Fulano acha ok daquele jeito, outro diz que tem que mudar. Qual critério usar? Tentar padronizar? Marca 3 reunião que não define.
OpenClaw: Senior Engineer online 24/7
Joga o código pra OpenClaw, ele passa linha por linha seguindo best practices da indústria: vulnerabilidade de segurança, gargalo de performance, manutenibilidade, casos extremos — tudo coberto.
Sem fila, sem ter que agradar ninguém, sem aquele "tô ocupado" de última hora. E o padrão de Review é sempre o mesmo — nunca mais discussão chata na DM sobre se aquilo é problema ou não.
3 Prompts de Review, copia e cola direto
Desde auditoria de segurança até princípios de design, pega o que precisa.
Review de PR: Auditoria focada em segurança + performance
Instrução ouro
Review a mudança de código (PR diff), foca em:
1. Vulnerabilidade de segurança: SQL injection, XSS, CSRF, vaza de info sensível, desserialização insegura
2. Problema de performance: Query N+1, alocação de memória desnecessária, query sem índice, operação bloqueante
3. Caso extremo: null check, race condition, dado gigante
Pra cada problema mostra:
- Nível de severidade (Critical / Warning / Suggestion)
- Local exato (arquivo + linha)
- Dica de fix e código de exemplo
No final mostra opinião geral e se recomenda mergear ou não.Perfeito pra fazer você mesmo uma passada antes de mergear, pega a maioria dos problemas de segurança comuns. Usa Claude Opus 4.6, tem melhor entendimento de risco de segurança entre arquivos.
Auditoria em relação a princípios SOLID
Dica avançada
Checa se o código segue os princípios SOLID:
- S (Responsabilidade Única): Essa classe/função não tá fazendo muita coisa?
- O (Aberto/Fechado): Novo feature precisa mexer em código existente?
- L (Substituição de Liskov): Classe filha consegue substituir a mãe com segurança?
- I (Segregação de Interface): Interface não tá muito grande?
- D (Inversão de Dependência): Módulo de alto nível tá dependendo diretamente de baixo nível?
Pra cada violação:
1. Explica o que violou e onde
2. Por quê isso é um problema
3. Mostra plano de refatoração e exemplo de códigoBom pra Review de lógica crítica ou código da base. CRUD simples não precisa disso.
Busca e arruma problema N+1 em query de banco de dados
Instrução ouro
Analisa a query de banco de dados do código:
1. Acha todos os problemas N+1:
- Mostra query dentro de loop
- Calcula quantas queries no pior caso
2. Opção de fix:
- Qual consegue mergear com JOIN
- Qual consegue fazer eager loading / preload
- Qual precisa de cache
3. Escreve o código otimizado
4. Estima diferença de performance antes vs depois
O ORM é [seu ORM, tipo SQLAlchemy / Prisma / ActiveRecord].N+1 é o vilão de performance mais comum, página lenta? Checa isso primeiro. Lembra de trocar o nome do ORM pelo que você usa de verdade.
Code Review: OpenClaw vs GitHub Copilot
Ambos fazem Review de código, mas forma totalmente diferente.
OpenClaw
- Vê o contexto inteiro do projeto, entende lógica de negócio entre arquivos
- Prompt totalmente customizável, segue a norma do seu time
- Consegue trocar modelo: Review simples usa GPT-4o, arquitetura complexa usa Opus 4.6
- Resultado de Review pode exportar, guardar, virar base de conhecimento do time
VS
GitHub Copilot Code Review
- Integrado na interface de PR do GitHub, fácil triggerar
- Review só do diff, entendimento entre arquivos é limitado
- Modelo fixo, sem como customizar regra de Review
- Às vezes entende errado comentário em chinês e nome de variável
Cenário real
Startup: dois backend segurando todo o código
Time tem só dois backend, Review entre eles sempre erra coisa, daí vai pra produção e quebra.
Solução com OpenClaw
Antes de mergear faz uma rodada de Review com OpenClaw (segurança + performance), filtra problema óbvio, Review manual só cuida de lógica de negócio. Taxa de incidente em produção caiu no meio, tempo de Review de 2 dias pra meio dia.
Solução só manual
Dois caras fazem Review um do outro, quando tá ocupado só "LGTM". Padrão de código só funciona por conversa informal, quando chega alguém novo precisa treinar de novo.
Umas dicas bem práticas
Não joga o projeto inteiro de uma vez pra IA fazer Review. Faz por módulo, cada vez focando um ponto (tipo segurança, ou performance, ou legibilidade), resultado é melhor.
Review de IA não substitui Review manual, é antes. Deixa máquina achar formato e problema comum, deixa gente ver design e lógica de negócio.