🔁 Por que "quem escreveu nao revisa"
Mesmo modelo que escreveu o codigo nao percebe seus proprios bugs (vies de confirmacao). Revisor diferente pega 60% mais issues.
🧠 Mecanismo
DeepSeek que escreveu codigo X tem o "esquema mental" daquela implementacao. Quando le seu proprio codigo, ele preenche lacunas mentalmente — assume que o codigo faz o que ele queria que fizesse, mesmo que o texto nao garanta isso. Modelo diferente le com mente fresca: ve o que esta escrito, nao o que era pra estar.
🔍 Checklist de revisao automatica
Bugs, seguranca, performance, aderencia ao plano, edge cases, naming, tests, documentacao. 8 itens fixos para todo review.
📋 8-point review
- Bugs: off-by-one, null, undefined, race conditions
- Seguranca: XSS, SQL injection, IDOR, auth bypass, leak de dados
- Performance: N+1, loops ineficientes, memo faltante, leak de memoria
- Aderencia: faz exatamente o que o plano pediu? sem extras?
- Edge cases: empty state, max input, network error, rollback
- Naming: consistente com o resto do projeto? autoexplicativo?
- Testes: presentes? cobrem caminho infeliz? mock minimo?
- Documentacao: comentarios em logica nao-obvia, sem ruido
⏪ Quando aceitar e quando reverter
Decisao binaria perde nuance. Trinario e mais fiel a realidade.
APROVAR
Sem issues criticas/altas. Codigo segue o plano. Merge direto.
AJUSTAR
Issues medias/altas pontuais. Volta para etapa 3 (DeepSeek corrige) com lista.
REPLANEJAR
Issues criticas estruturais. Volta para etapa 1. Plano errou ou foi mal-interpretado.
🛡️ Revisao especializada: seguranca
Em codigo que toca auth/payment/data, faz um segundo pass de revisao com prompt especifico de seguranca (OWASP, SQL injection, XSS, IDOR).
🔒 Pass de seguranca dedicado
Voce e auditor de seguranca. Audite o diff abaixo contra OWASP Top 10 + checklist: - Injection (SQL, NoSQL, Command) - Broken auth (sessao, JWT, MFA) - Sensitive data exposure - XXE/XSS/SSRF - Broken access control (IDOR) - Security misconfiguration - CSRF - Logging sensivel/insuficiente Output: lista por severidade. Para CRITICA, pare a release.
🤖 Automatizar revisao no CI
Action que roda em todo PR: pega o diff, manda para GPT-5.5/Opus revisar, comenta no PR. Funciona como tech lead robotico.
⚙️ GitHub Action minimo
name: AI Review
on: pull_request
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: |
DIFF=$(gh pr diff)
curl -s https://api.openai.com/v1/chat/completions \
-H "Authorization: Bearer $OPENAI_KEY" \
-d "{\"model\":\"gpt-5.5\",\"messages\":[
{\"role\":\"system\",\"content\":\"$(cat prompts/review.md)\"},
{\"role\":\"user\",\"content\":\"$DIFF\"}
]}" | jq -r '.choices[0].message.content' > review.md
gh pr comment --body-file review.md📝 Documentar decisoes que vieram da revisao
Quando a revisao muda algo importante, registre o porque. ADRs (Architectural Decision Records) servem aos modelos futuros.
📚 Template de ADR
# ADR 001: Por que NAO usamos JWT em sessoes ## Contexto Revisao do PR #42 (auth) levantou risco de XSS leak. ## Decisao Usar cookies httpOnly + session em DB, nao JWT em localStorage. ## Consequencias + Resistente a XSS + Revogacao instantanea - Mais latencia (1 query por request) - Sticky session na infra ## Status Aceito em 2026-04-15
📌 Resumo do Modulo
Proximo Modulo:
2.6 — 📊 Metricas, custo e otimizacao