AI-aware code review: revisar PRs com muito código gerado, prompts reproduzíveis

Você recebe um PR de 1500 linhas, 80% gerado por IA. Reviewer cansado em 30 min, commenta "LGTM", e 3 bugs vão pra prod. Esse nó cobre AI-aware code review: como revisar PRs com muito código gerado por IA, prompts reproduzíveis (manter o prompt que gerou o código no commit/PR), e red flags específicos de código IA.

PRs com código IA têm patterns específicos: muitos comentários explicativos (IA gosta de explicar), patterns uniformes (mesmo estilo em arquivos diferentes), mocks excessivos (IA mock pra tudo), e edge cases perdidos (IA não pensa em todos). Reviewer informado pega 3-5x mais bugs que reviewer genérico.

Você sai de "LGTM" pra "review informado que pega bug".

O essencial 🟢

O problema: PRs com código IA são difíceis de revisar.

• Volume grande. IA gera +30% linhas que humano (comentários, boilerplate, edge cases). 200 linhas "humanas" = 300 linhas "IA".
• Patterns uniformes. IA gera código com mesmo estilo em arquivos diferentes - difícil de "sentir" inconsistências.
• Edge cases ignorados. IA resolve happy path, esquece edge cases (null, vazio, Unicode).
• Mocks excessivos. IA mocka tudo pra "passar teste" - teste vira inútil.

Os 6 red flags em PR com código IA.

1. Volume desproporcional. "Por que esse PR tem 1500 linhas pra adicionar um botão?" - sinal claro de código IA sem foco.
2. Comentários explicativos excessivos. // This function validates the email by checking if it contains @ and . - IA explica demais, humano não.
3. Patterns uniformes. 5 arquivos com mesmo estilo de error handling (até espacamento) - sinal de IA.
4. Mocks everywhere. Teste mocka DB, API, file system, logger, auth - testa que o código chama as coisas, não que funciona.
5. Nomes de variável genéricos. data, result, item, value
   • IA escolhe nomes sem semântica. Humano escolheria userEmail, parsedCpf, cartItem.
6. Comentários tipo "this might not work" ou "TODO: improve". IA sabe que tem problema, comenta em vez de corrigir.

Como revisar PR com código IA em 30 min.

# 5 min - Visão geral
git diff --stat  # quanto mudou?
git log -p --follow  # commits anteriores
# Pergunte: "Que problema isso resolve?"

# 5 min - Riscos
- Lista arquivos com +200 linhas
- Lista arquivos de auth/payment/security
- Lista dependencies novas
- Lista "removed lines" (>50 removidas = refactor)

# 10 min - Hot paths
- Auth, payment, session, JWT, password
- SQL, fetch, file upload, eval
- Foca em segurança + dados

# 10 min - Logic
- Foca em funções adicionadas (diff +)
- Roda tests local
- Type check
- Mutation test se possível

# Total: 30 min por PR grande

Como exigir prompts reproduzíveis no PR. Pattern 1: IA gera código, você commita o prompt junto. Justificativa: auditoria, reprodução (re-rodar IA com mesmo prompt gera output similar), review (reviewer vê o que você pediu).

<!-- PR description -->

## What
Adds user authentication via OAuth Google.

## Why
- Reduce signup friction
- Address PM-1234

## AI-assisted
🤖 Generated with Claude Code (claude-sonnet-4)

**Prompts used:**
1. "Implement OAuth Google callback handler in src/auth/google/callback.ts.
   Use google-auth-library, verify state token, exchange code for tokens,
   set httpOnly session cookie. Add unit tests covering happy path,
   invalid state, expired code, and network errors."
2. "Add /auth/google/login route that generates OAuth URL with CSRF state.
   Store state in sessionStorage. Tests for URL generation and state
   persistence."

**Human review:**
- [x] Read all generated code
- [x] Audited auth flow manually
- [x] Tested locally
- [x] Verified with security checklist

Pattern 2: git commit com prompt inline.

git commit -m "feat: add OAuth Google

🤖 Generated with Claude Code.

Prompt: Implement OAuth Google callback in
src/auth/google/callback.ts. Use
google-auth-library, verify state, exchange
code for tokens, set httpOnly cookie.

Reviewed: auth flow, security checklist, tests
pass."

Pattern 3: arquivo AI_NOTES.md no PR.

# AI Notes

## What was generated
- `src/auth/google/callback.ts` (full)
- `src/auth/google/login.ts` (full)
- `src/auth/google/types.ts` (full)
- `tests/auth/google/*.test.ts` (partial)

## What I wrote manually
- `src/auth/google/config.ts` (env vars, secrets)
- `src/auth/google/session.ts` (httpOnly cookie logic)

## What I reviewed
- [x] Auth flow (read every line)
- [x] Security checklist (no hardcoded secrets)
- [x] Tests run locally
- [x] Type check passes
- [x] ESLint passes
- [x] Manual test with real OAuth flow

Conventional Comments - feedback estruturado em code review. Use prefixos pra tornar feedback claro:

• nit: - cosmético, não bloqueia.
• suggestion: - melhoria, não bloqueia.
• issue: - bug ou problema, bloqueia.
• question: - precisa explicação.
• praise: - elogio (importante pra moral do time).
• security: - vulnerabilidade, bloqueia sempre.

Exemplo de review em PR com IA.

src/auth/google/callback.ts:42
security: Oauth state token não está sendo
  validado contra CSRF. Adicione
  `oauth2Client.verifyIdToken()` ou check
  manual do state.

src/auth/google/login.ts:15
issue: `state` gerado mas não persistido em
  cookie/sessionStorage. Ataque CSRF possible.
  Fix: salvar state antes do redirect.

src/auth/google/types.ts:8
question: Por que `GoogleUser.email` é
  `string | null`? Em OAuth Google, email
  sempre vem. Null check pode esconder bug.

src/auth/google/callback.ts:100
nit: comentário `// This validates the token`
  é redundante - nome da função já diz.
  Remova.

src/auth/google/callback.ts:80
praise: bom uso de try/catch com error
  handling adequado. 👍

3-5x mais eficiente que "LGTM".

Red flags específicos de código gerado por IA - checklist.

[ ] Volume desproporcional (PR grande pra task simples)
[ ] Comentários explicativos excessivos
[ ] Patterns uniformes (todos arquivos mesmo estilo)
[ ] Mocks excessivos (testa mocks, não lógica)
[ ] Nomes genéricos (data, result, item)
[ ] Sem tratamento de edge cases
[ ] Sem teste pra error handling
[ ] Sem teste pra boundary
[ ] Sem teste pra input inválido
[ ] Sem revisão de tipos (any em vez de tipos específicos)
[ ] Sem revisão de error handling (catch vazio)
[ ] Dependência nova sem justificativa
[ ] Refactor grande sem plano
[ ] Código de auth/payment sem review de especialista
[ ] Secret/key em código (deveria ser env var)
[ ] Sem prompt reproduzível no PR
[ ] Sem AI_NOTES.md explicando o que foi gerado

Como auditar se código IA foi "vibe coding" vs "AI-assisted". Vibe coding = aceito sem entender. AI-assisted = IA gera, você revisa e entende.

Vibe coding:
- PR sem descrição de AI
- Sem AI_NOTES.md
- Sem testes
- Diff gigante
- Commit message genérico

AI-assisted:
- PR descreve o que IA gerou
- AI_NOTES.md separa "IA gerou" vs "humano escreveu"
- Tests inclusos
- Diff proporcional
- Commit messages específicos
- Prompts reproduzíveis

Tempo de review por tipo de PR.

• PR pequeno (50 linhas): 5-10 min.
• PR médio (200 linhas): 15-30 min.
• PR grande (500+ linhas): 30-60 min.
• PR com IA (500+ linhas): 45-90 min. Volume + need to verify patterns = +50% tempo.

AI-assisted code review (ferramentas). GitHub Copilot Review, Coderabbit (AI reviewer no GitHub), Claude Code review

• IA revisa PR antes de humano. Pega bugs básicos (style, typo, unused import), falha em design decisions. Use como primeira linha, não substituto de humano.

Aprofundamento 🟡

"AI slop" - o pattern de código ruim de IA. AI slop = código gerado por IA sem review, com patterns ruins: comentários desnecessários, "this function" + "this method" (muitos comments explicando o obvio), error handling genérico (catch (e) ), "helper functions" que só chamam 1 função (over-abstraction), nomes sem sentido (helper1, helper2, util3). Sinal claro: "muito código, pouco valor".

Como detectar AI slop em PR.

- Mais de 30% de comentários? AI slop
- Nomes `helper`, `útil`, `manager`? AI slop
- Error handling genérico? AI slop
- Refactor com "this improves X"? AI slop
- Testes com mocks excessivos? AI slop
- Sem edge case handling? AI slop

AI slop = technical debt emergente. Refactor ou delete.

Prompt reproduzível: log vs código. Opção 1: prompt no commit message (sempre visível, sem arquivo extra). Opção 2: prompt em AI_NOTES.md (separado, mais espaco pra explicação). Opção 3: prompt em PROMPTS.log (log de todos os prompts, busca via grep). Recomendado: Opção 1 pra PRs pequenos, Opção 2 pra PRs grandes.

O pattern "vibe coding" em empresas. Vibe coding = "gerar tudo, aceitar, mandar PR". Anti-pattern em empresa: revisor gasta 1h revisando código ruim, rejeita, dev re-gera com IA, mesma qualidade, outro 1h de review. Ciclo infinito. Solução: AI-assisted workflow documentado (IA gera, humano revisa com checklist, IA ajuda em iteração).

Code review com AI: 2-pass pattern. Pass 1: AI revisa (catches: typo, style, unused). Pass 2: humano revisa (catches: design, security, business logic). Sem AI no pass 1 = +50% tempo. Sem humano no pass 2 = bugs passam. Combinação = +30% eficiência, mesma qualidade.

Leitura recomendada:

• Conventional Comments - prefixos pra feedback estruturado.
• GitHub - PR Review - como revisar PR.

Dica: o erro mais comum em AI code review é "LGTM" porque parece bom. Código IA parece bom por design (IA gera patterns uniformes, explicações claras, comentários educados). Por isso parece "LGTM" mas tem bugs (edge case perdido, security vuln, mock excessivo). Review com checklist = 3-5x mais bugs pegos. 30-60 min por PR com IA = economiza horas de bug em prod. LGTM é código legado futuro.

No próximo nó (último), vamos projeto final: feature completa com IA no loop (decomposição, geração, review, test, commit), diffs auditáveis, e PR limpo com prompts reproduzíveis.