Um Claude que corrige o outro

O que é e porque importa

Quando uma sessão do Claude Code acaba um trabalho e te diz «feito», o natural é pedir-lhe que volte a verificar. Funciona pouco. Acabou de escrever aquele código, sabe porque o fez assim, e quando o relê vê o que queria fazer, não o que fez de facto.

É o mesmo ponto cego que temos quando relemos um texto nosso. Os erros que escapam são precisamente os que não imaginaste enquanto escrevias: o campo deixado vazio, o duplo clique, o utilizador que abre os dados de outro.

Por isso a verificação faço-a fazer a outra sessão, que começa sem a conversa da primeira. Só vê as alterações e uma tarefa: descobrir como as partir. O guia oficial do Claude Code também o diz: uma sessão com o contexto limpo revê melhor o código, porque não está presa ao que acabou de escrever.

Porque importa: se constróis uma app sem seres programador, ainda não tens olho para ver estes buracos. Um revisor que tem a tarefa de atacar o código procura-os por ti, antes que os utilizadores os encontrem.

1. O prompt do revisor

Este é o prompt que colo na segunda sessão, palavra por palavra. Tal como está funciona antes do commit. Se já fizeste commit, acrescenta no fim que ficheiros ver.

És um revisor externo. Não foste tu que escreveste este código e não sabes porque está feito assim: não perguntes e não procures justificações. Olha só para as alterações acabadas de fazer: corre git status e git diff, e lê por inteiro os ficheiros novos que o git status lista (o diff não os mostra). A tua única tarefa é descobrir como as partir. Procura:
- entradas: campos vazios, textos compridíssimos, caracteres estranhos, números negativos, duplo clique, pedidos duplicados;
- permissões: quem pode ver ou alterar dados que não são seus, o que acontece sem login ou com o login de outra pessoa;
- casos limite: listas vazias, rede lenta ou sem rede, dois utilizadores ao mesmo tempo;
- segurança: chaves ou palavras-passe no código, dados do utilizador usados sem verificação, erros que mostram demasiado.
Para cada problema escreve: onde (ficheiro e linha), como o parto (os passos exatos), o que acontece, gravidade (alta, média, baixa). Ordena do mais grave. Não corrijas nada e não alteres os ficheiros: só quero o relatório.

Cada parte tem um motivo.

• «Não foste tu que escreveste este código»: tiro-lhe o papel de autor. Um autor defende o seu trabalho, um revisor externo procura os defeitos.
• «Corre git status e git diff, e lê por inteiro os ficheiros novos»: o git diff só mostra as alterações aos ficheiros que o git já conhece. Os ficheiros criados de raiz encontra-os com o git status, e sem esta linha ficavam de fora.
• «A tua única tarefa é descobrir como as partir»: não lhe pergunto se o código está bem. Peço-lhe que o ataque, que é outra pergunta.
• As quatro áreas, ou seja entradas, permissões, casos limite e segurança, são os pontos onde as apps feitas à pressa se partem mais vezes. Se a tua app tem uma parte delicada, tipo os pagamentos, acrescenta-a como quinta linha.
• «Como o parto (os passos exatos)»: um problema com os passos verificas tu em dois minutos. Um «pode haver um problema», não.
• «Não corrijas nada e não alteres os ficheiros»: o revisor assinala, não mexe. Se corrigisse ele, terias duas sessões a mudar os mesmos ficheiros e deixavas de saber quem fez o quê.

2. Como o uso

1. Quando a primeira sessão diz «feito», não lhe peço que se verifique a si própria.
2. Abro um terminal novo na mesma pasta e lanço claude. Ou, na mesma janela, /clear abre uma conversa nova com o contexto vazio. A antiga fica guardada e retomas com /resume.
3. Colo o prompt. Antes do commit, git status e git diff mostram o trabalho acabado de fazer. Depois do commit, indico-lhe os ficheiros.
4. Levo o relatório à primeira sessão e mando corrigir a começar pela gravidade alta.
5. Em login, pagamentos e dados dos utilizadores revejo também a correção, noutra sessão nova.

Um pormenor sobre git diff: mostra as alterações aos ficheiros que o git já conhece, por isso os ficheiros novos não estão lá. É por isso que no prompt está git status, que os lista, e o revisor lê-os por inteiro. Se preferires vê-los também no diff, antes de abrir o revisor corre git add -N . no terminal: o git marca-os como ficheiros a adicionar e a partir daí aparecem no git diff.

O revisor não deve poder escrever

No prompt está escrito para não alterar os ficheiros, mas é um pedido, não um bloqueio. Se quero ter a certeza, abro a segunda sessão em plan mode:

claude --permission-mode plan

Em plan mode o Claude lê os ficheiros e pode correr comandos para explorar, tipo git diff, mas não altera o código enquanto não aprovares um plano. Se no fim te propuser um plano de correções, não o aproves: o relatório chega-te. Se a sessão já estiver aberta, entras carregando em Shift+Tab até aparecer «plan mode on» em baixo.

Levar o relatório de volta

Na primeira sessão colo o relatório com um prompt assim:

Aqui está o relatório de um revisor externo: [cola o relatório]. Corrige primeiro os problemas de gravidade alta, um de cada vez. Para cada um diz-me o que mudaste e como o verificaste. Os de gravidade baixa não lhes mexas: decido eu.

Se tinha usado /clear, primeiro volto à conversa inicial com /resume, para a sessão que corrige ter outra vez todo o contexto do trabalho.

As baixas guardo-as para mim por um motivo concreto. Um revisor a quem pedes para encontrar problemas encontra quase sempre algum, mesmo quando o trabalho está bem feito, porque é o que lhe pediste. Se corriges tudo, acabas com código a mais para casos que nunca vão acontecer.

3. Com um subagente, na mesma janela

Se não queres abrir outra janela, o revisor pode ser um subagente: um ajudante que trabalha dentro da tua sessão, com um contexto seu, e não vê a conversa. No guia sobre os subagentes explico como criar um code-reviewer fixo só com as ferramentas para ler.

A vantagem: o relatório volta diretamente à sessão que escreveu o código, sem copiar e colar. O risco: a tarefa do subagente escreve-a o Claude, e o Claude sabe porque o fez assim. Se lho explicar, o revisor já parte convencido. Por isso peço-lhe que passe o prompt tal como está:

Manda o subagente code-reviewer rever as últimas alterações. Passa-lhe este prompt palavra por palavra, sem acrescentar explicações sobre como ou porque escreveste o código: [cola o prompt do revisor]

Para as partes delicadas, porém, prefiro a sessão nova: aí sou eu que colo o prompt e sei exatamente o que o revisor recebeu.

A regra de ouro

Nada da conversa anterior: se lhe explicas porque fizeste assim, acaba por te dar razão.

Vale também para ti. Quando colas o prompt, não acrescentes «fiz assim porque…». Dá as alterações e a tarefa, e chega. As explicações servem depois, quando decides que problemas corrigir.

Uma sessão nova lê na mesma as instruções do projeto (CLAUDE.md) e a memória automática, se as usares. Está bem: são regras, não a história de como nasceu aquele código.

Os erros mais comuns

• Pedir à mesma sessão que se verifique: abre uma sessão nova, ou usa /clear, para que quem verifica não tenha escrito o código.
• Explicar ao revisor porque o código está feito assim: dá-lhe só as alterações e a tarefa, senão acaba por te dar razão.
• Deixar o revisor corrigir: pede-lhe só o relatório e manda corrigir a sessão que escreveu o código.
• Corrigir todos os problemas assinalados: começa pela gravidade alta e as baixas decide-as tu, senão enches o código de defesas inúteis.
• Confiar só no git diff quando há ficheiros novos: no diff não aparecem, por isso manda correr também o git status, como no prompt.
• Não rever a correção nas partes delicadas: para login, pagamentos e dados dos utilizadores, refaz a revisão numa sessão nova.

Checklist

• O revisor está numa sessão nova
• O prompt está colado sem explicações
• Antes do commit: git status e git diff. Depois: os ficheiros indicados
• Cada problema tem onde, passos, efeito e gravidade
• Os problemas de gravidade alta estão corrigidos e verificados
• As partes delicadas tiveram uma segunda revisão

Perguntas frequentes