Aula 09Revisar o que o Claude fez

Objetivos

Ao final desta aula você vai saber:

• Conferir uma mudança pelo comportamento, usando a página como um cliente usaria
• Ver quais arquivos mudaram com /diff, para responder: mudou algum arquivo que eu não pedi?
• Pedir ao Claude que explique cada mudança em português simples
• Pedir uma segunda opinião com /code-review, um revisor que começa com o contexto limpo
• Separar cada achado em corrigir agora, perguntar por quê ou deixar para depois, com um print como prova
• Desfazer uma mudança errada: recusando no Manual, com o /rewind ou voltando à última versão guardada

Quando o Claude termina uma tarefa, ele resume o que fez. O resumo costuma ser verdade, mas nem sempre conta tudo: por baixo dele, pode haver um arquivo mexido de passagem ou um detalhe que ninguém pediu.

E quem fez a mudança nem sempre é o melhor juiz dela. A conversa que fez a mudança carrega tudo o que o Claude leu e decidiu até ali, e tende a achar que ficou bom. Por isso, nesta aula, você confere de três jeitos: usa a página, vê o que mudou e pede uma segunda opinião, a um revisor que começa do zero.

💡 Você não precisa ler código para revisar. Três perguntas bastam: a página faz o que eu pedi? Mudou alguma coisa que eu não pedi? Eu entendo, em português, o que mudou? Para quem não lê código, conferir importa mais, não menos.

A mudança desta aula: o formulário de encomenda

Na Aula 06, a página ganhou o cardápio com filtro. Agora, ela ganha um jeito de receber encomendas: um formulário com o nome da pessoa, o doce (escolhido entre os do cardápio) e a data de entrega, e um botão Enviar pelo WhatsApp, que abre o WhatsApp com a mensagem pronta.

Abra o Claude Code na pasta da página, no Manual, e peça:

Na página, acrescente uma seção de encomendas com um formulário: o nome
da pessoa, o doce (escolhido entre os do cardápio) e a data de entrega.
Embaixo, um botão "Enviar pelo WhatsApp", que abre o WhatsApp com a
mensagem pronta para o número (11) 90000-0000, e uma prévia da mensagem,
para a pessoa conferir antes de enviar. Critério: ao preencher, a prévia
mostra o nome, o doce e a data, e o botão leva ao WhatsApp. Para conferir,
eu preencho, clico e te mando um print.

Repare nas cinco partes da Aula 04: o quê, onde, o comportamento, o critério e como conferir. A mudança mexe em mais de uma parte da página, então, se quiser, passe antes pelo Plan Mode, como na Aula 06.

⚠️ Use um número inventado enquanto treina, como o (11) 90000-0000 do exemplo. A página entra nas versões guardadas, e o histórico das versões pode ir junto quando o projeto for publicado. Na Aula 19, antes de pôr a página no ar, você decide se põe o número de verdade. Com o número inventado, a conversa no WhatsApp não chega a abrir, porque ninguém usa esse número. Tudo bem: o que você confere é que o clique leva ao WhatsApp. O texto da mensagem, você confere na prévia.

💡 Como o botão sabe o número? Ele usa um link do próprio WhatsApp: https://wa.me/5511900000000?text=.... O número vai inteiro, com o 55 do Brasil e o DDD, sem parênteses, espaço nem traço, e a mensagem vem depois do text=. Quem monta o link é o Claude, mas conhecer o formato ajuda a conferir.

Quando termina, o Claude resume:

Adicionei a seção de encomendas.

• Formulário com nome, doce e data de entrega
• Botão "Enviar pelo WhatsApp" com a mensagem pronta
• Prévia da mensagem embaixo do botão

Tudo verdade. Agora, confira.

1. Use a página como um cliente usaria

O primeiro jeito de conferir é o mais importante, e não exige ler nada. Abra a página no navegador (ou atualize, se ela já estava aberta) e use o formulário como uma cliente da confeitaria usaria:

• Preencha o nome, escolha um doce e uma data, e veja se a prévia mostra os três.
• Clique em Enviar pelo WhatsApp e veja se o clique leva ao WhatsApp.
• Faça o que um cliente apressado faria: tente enviar sem o nome.
• Ligue o modo escuro e veja se o formulário continua fácil de ler.
• Clique nos botões do cardápio, para ver se o filtro da Aula 06 continua funcionando.

Tire um print, cole na caixa de texto (Ctrl + V, ou Alt + V no Windows) e peça para o Claude conferir o critério. Viu algo errado? Diga o que viu, com o print junto. A prova é o print: o que aparece na tela, e não a palavra de ninguém, nem a do Claude.

2. Veja quais arquivos mudaram

A página funcionou. Falta uma pergunta, que a tela não responde: mudou algum arquivo que eu não pedi? Para isso serve o diff, o antes e o depois de cada arquivo: as linhas que saíram aparecem em vermelho, começando com -, e as que entraram, em verde, começando com +. Você não precisa ler as linhas: a lista dos arquivos já responde à pergunta.

Na caixa de texto, digite:

/diff

O jeito como ele aparece depende do visual do seu terminal:

• Num painel ao lado da conversa, que se atualiza enquanto você trabalha. Clique num arquivo para ver o que mudou nele. Se a janela do terminal for larga, o painel pode até abrir sozinho quando o Claude começa a mexer nos arquivos. Para fechar, digite /diff de novo ou clique no ✕ do painel.
• No lugar da caixa de texto. Use as setas para cima e para baixo para escolher um arquivo, Enter para abrir, e Esc para voltar à lista e, depois, para fechar.

⚠️ No painel, alguns arquivos ficam recolhidos no fim da lista, numa linha com uma contagem: os de teste e os gerados, numa, e o que mudou antes desta conversa, em outra. Se uma linha assim aparecer, clique nela para ver os arquivos.

No exemplo desta aula, a lista ficou assim (a sua pode ser diferente; a pergunta é a mesma):

Clique no .gitignore para ver a linha que saiu: é a do .env. Sem ela, a senha do .env pode entrar na próxima versão guardada, e o que entra numa versão pode ir parar na internet quando você publicar a página (Aula 19). É uma mudança de uma linha só, que pode fazer um estrago grande.

O package.json é um arquivo de projetos de programação: ele lista os pacotes de código pronto que o projeto usa. A sua página não usa nenhum. Não é perigoso, mas ninguém pediu.

3. Peça a explicação de cada mudança

A lista mostra quais arquivos mudaram. Para saber o que mudou dentro deles, peça:

Explique cada mudança que você fez, arquivo por arquivo, em português simples. Diga também se mexeu em algo que eu não pedi.

No exemplo, a resposta foi esta:

• index.html: acrescentei a seção de encomendas, com o formulário, o botão e a prévia da mensagem. Também troquei o ícone do botão do modo escuro: agora ele mostra um sol quando a página está escura.
• estilo.css: as cores e os espaços do formulário.
• .gitignore: tirei a linha do .env.
• package.json: criei para registrar o projeto.

Repare no index.html: o botão do modo escuro mudou sem ninguém pedir 🚩. Esse a lista não mostrava, porque estava dentro de um arquivo que você esperava ver nela. É por isso que a explicação vem depois da lista: uma responde onde mudou, a outra, o quê.

Agora, pergunte por quê e decida:

Por que você tirou o .env do .gitignore e criou o package.json? Devolva
a linha do .env ao .gitignore e, se a página não precisa do package.json,
apague esse arquivo. E deixe o botão do modo escuro como estava.

No Manual, cada mudança pede a sua licença, e apagar o package.json aparece como um comando. Desta vez, quem pediu para apagar foi você, então pode aprovar; se não entender o comando, peça a explicação, como na Aula 05. Depois, rode o /diff de novo: agora, só o index.html e o estilo.css aparecem.

4. Peça uma segunda opinião com o /code-review

Você conferiu o que dá para ver. Falta o que não aparece na tela, e para isso existe o revisor:

/code-review

O /code-review olha a mudança com o contexto limpo: ele começa sem nada desta conversa, ao contrário da conversa que fez a mudança, que carrega tudo o que leu e decidiu (o contexto, a memória de trabalho da Aula 07). Ele procura problemas e relata o que encontrou, sem mudar nada, a menos que você peça.

• Ele olha as mudanças que ainda não estão numa versão guardada e pode olhar também a última versão que você guardou. Por isso, peça a revisão antes de guardar a versão: assim, o que entra nela já passou pelo revisor.
• Ele roda em segundo plano: você pode continuar conversando enquanto isso, e os achados chegam na conversa quando ele termina.
• Ele conta no seu uso como qualquer outra tarefa (Aula 08). Guarde-o para as mudanças que merecem.

Também dá para pedir com as suas palavras: "revise as mudanças que você fez, aponte os problemas e ainda não corrija nada". Se ele responder direto, sem chamar a revisão, digite o /code-review você mesmo.

O relatório vem com termos técnicos. Peça a tradução:

Explique cada achado em português simples: o que acontece com o cliente se isso ficar como está?

No exemplo, a revisão trouxe quatro achados. Traduzidos:

1. A data de entrega aceita um dia que já passou. Uma cliente pode encomendar para ontem, e a encomenda chega sem chance de ser atendida.
2. O botão pode não abrir o WhatsApp no celular. Quem encomendasse pelo celular não conseguiria enviar.
3. O número está diferente em dois lugares. O texto da página mostra (11) 90000-0000, mas o link do botão leva para 5511900000001. As encomendas iriam para outro número.
4. O rosa do botão é outro. O botão do WhatsApp usa um rosa um pouco diferente do resto da página.

5. Decida o que fazer com cada achado

Separe cada achado numa de três pilhas:

1. Corrigir agora. É um problema de verdade e importa para o cliente.
2. Perguntar por quê. Você não consegue confirmar, ou o achado não bate com o que você viu. Revisores também erram.
3. Deixar para depois. É de verdade, mas pequeno. Fica para a próxima rodada de ajustes.

Para perguntar por quê, cite o achado de volta e peça para o Claude conferir:

Você disse que o botão não abre o WhatsApp no celular, mas no computador
ele abriu. Confira de novo, me explique em português simples por que isso
aconteceria e me diga se o achado se mantém.

No exemplo, o Claude confere e conclui que o achado não se mantém: o botão usa o link oficial do WhatsApp, o wa.me, que funciona no celular e no WhatsApp Web. Na Aula 19, com a página no ar, você testa no celular de verdade.

Para corrigir agora, peça a correção e o jeito de conferir:

Corrija os achados 1 e 3: a data de entrega não pode aceitar um dia que
já passou, e o número tem de ser o mesmo no texto e no botão. Depois, me
diga como eu confiro.

Confira do jeito que ele disser e mande um print, por exemplo, da página recusando a data de ontem. A prova é o print, e não a palavra do Claude. Se uma correção crescer e virar uma mudança grande, peça a revisão de novo.

O achado 4 fica para a próxima rodada de ajustes.

6. Guarde a versão revisada

Com tudo conferido, falta guardar. Antes, uma última olhada no que mais importa:

Confira se o .env continua na lista do que o Git não guarda.

Depois:

Guarde uma versão com a mensagem "Formulário de encomenda pelo WhatsApp".

No Manual, os comandos do Git esperam a sua aprovação, como na Aula 06. A pasta ganha mais uma versão guardada, e a mais nova é o formulário funcionando.

Quando a mudança inteira está errada

Às vezes, o que o Claude fez não tem conserto, e o melhor é desfazer. Há três saídas, da mais cedo para a mais tarde:

1. Antes de a mudança acontecer: recuse. No Manual, cada mudança espera a sua aprovação. Recuse e, com Tab, diga o motivo, como na Aula 05.
2. Logo depois, na mesma conversa: o /rewind. Digite /rewind, ou aperte Esc duas vezes com a caixa de texto vazia, e escolha a mensagem em que você fez o pedido. Depois, escolha Restore code and conversation (restaurar o código e a conversa), para voltar os arquivos e a conversa àquele ponto, ou Restore code (restaurar o código), para voltar só os arquivos.
3. A qualquer momento: volte à última versão guardada. Peça: "desfaça as mudanças desde a última versão guardada". As versões que você guardou continuam lá. No Manual, o comando aparece e espera a sua aprovação: é uma boa hora para pedir a explicação. A Aula 10 mostra isso por inteiro.

⚠️ Dois limites. O /rewind não desfaz o que um comando mudou: se o Claude criou, copiou, moveu ou apagou um arquivo rodando um comando, essa parte fica como está. E voltar à última versão guardada pode deixar na pasta um arquivo novo, que nunca entrou numa versão. Depois de desfazer, peça: "me mostre se sobrou algum arquivo que não está em nenhuma versão guardada".

Quando vale revisar com mais cuidado

Toda mudança merece o passo 1: usar a página. Uma mudança pequena, como trocar um texto, quase sempre só precisa disso. Faça a revisão completa, com o /code-review, quando a mudança:

• for maior do que você consegue acompanhar de cabeça;
• mexer em algo sensível, como senhas, dados de clientes ou o que vai para a internet;
• apagar ou substituir alguma coisa;
• for ser mostrada a alguém ou publicada.

Para ir além (opcional): revisar como programador

🔧 Para ir além (para quem já programa; pode pular): esta parte mostra como ler o diff de um projeto de código, as variações do /code-review, o /simplify e a revisão automática de pull requests para empresas. Se você nunca programou, pule direto para o Na prática.

Ler o diff com olho de programador

Num projeto de código, três coisas merecem uma segunda olhada, toda vez:

• Mudanças que você não pediu. Um valor de configuração editado "de passagem" ou uma função auxiliar reescrita sem você mencionar.
• Testes que ficaram mais fracos. Testes pulados, apagados ou afrouxados até passarem. Um arquivo de teste com +2 -8, que perdeu mais do que ganhou, merece desconfiança, mesmo com o resumo dizendo que todos os testes passam.
• Pacotes novos e valores fixos no código. Uma dependência adicionada só para uma função (com o package-lock.json que vem junto), ou uma URL ou uma chave escrita direto no código.

⚠️ Pegadinha do painel: a lista do painel do /diff deixa de fora os arquivos de teste e os gerados (como o package-lock.json) e junta numa linha só o que mudou antes desta sessão. Clique nas linhas de contagem, no fim da lista, para expandir. É justamente nos testes que mora um dos problemas mais comuns.

Mais recursos do /diff:

• No painel, Ctrl+X B troca o que ele compara: as mudanças desta sessão, todas as mudanças ainda não commitadas ou tudo desde que o seu branch saiu do branch padrão.
• Selecione linhas no painel com o mouse para perguntar sobre elas: a seleção vai junto com o seu próximo prompt.
• No visual clássico, o viewer tem a visão Current, com as mudanças não commitadas, e uma visão por turno, só com o que o Claude editou depois de cada prompt. Passe de uma para outra com as setas para os lados. Uma mudança feita por comando de shell aparece só na Current.

Variações do /code-review

Sem alvo, o /code-review revisa os commits do seu branch que estão à frente do upstream, mais as mudanças não commitadas. Se o branch não tem upstream, ele compara com o main, ou com o commit anterior. A revisão segue o seu CLAUDE.md (Aula 11), e o /review é outro nome para o mesmo comando.

/simplify: limpeza, não caça a bugs

O /simplify procura no código que mudou o que dá para deixar mais simples: uma função auxiliar que já existia e foi reescrita, código repetido, algo ineficiente ou no nível de abstração errado. Ele roda quatro agentes em paralelo, um para cada aspecto, e já aplica as correções.

/simplify

Ele não procura bugs: para isso, continue usando o /code-review. E, como ele edita o código, passe pelo /diff depois, como em qualquer mudança.

Revisão automática nos pull requests (Team e Enterprise)

Nos planos Team e Enterprise, uma pessoa com papel de Owner pode ligar o Code Review para a organização. A partir daí, o Claude revisa os pull requests do GitHub sozinho, com vários agentes, e deixa comentários nas linhas com problema, marcados por gravidade: 🔴 importante, 🟡 detalhe e 🟣 problema que já existia antes do PR.

• Ele não aprova nem bloqueia o PR: o fluxo de revisão do time continua igual.
• Dá para ajustar o que ele aponta com um arquivo REVIEW.md (ou com o CLAUDE.md) no repositório.
• Não há preço fixo por revisão: cada uma é cobrada em créditos de uso e custa mais quanto maior a mudança e mais profundo o nível que o Owner escolhe (Quick, Standard ou Deep). O Owner pode definir um teto mensal.

Na prática

Use a pasta da página (a confeitaria, ou a da sua ideia), com as versões que você guardou na Aula 06.

1. Abra o terminal, entre na pasta e abra o Claude Code: cd Documents/confeitaria, com o nome da sua pasta, e depois claude. Aperte Shift + Tab uma vez e confira se aparece manual mode on.
2. Faça o pedido do formulário de encomenda, como no exemplo, com o número inventado. Aceite as mudanças que fizerem sentido.
3. Abra a página no navegador e use o formulário como um cliente: preencha, confira a prévia, clique no botão, tente enviar sem o nome, ligue o modo escuro e clique no cardápio. Tire um print, cole na caixa de texto e peça para o Claude conferir o critério.
4. Digite /diff e responda: mudou algum arquivo que eu não pedi? Se a resposta for não, ótimo: era o que você esperava.
5. Peça: "Explique cada mudança que você fez, arquivo por arquivo, em português simples. Diga também se mexeu em algo que eu não pedi." Se ele mexeu em algo que você não pediu, pergunte por quê e decida se fica.
6. Digite /code-review e espere os achados. Depois, peça: "Explique cada achado em português simples: o que acontece com o cliente se isso ficar como está?" Separe os achados nas três pilhas.
7. Para cada "corrigir agora", peça a correção e o jeito de conferir, e mande um print. Para cada "perguntar por quê", cite o achado de volta e peça para o Claude conferir.
8. Peça: "Confira se o .env continua na lista do que o Git não guarda" e, depois, "Guarde uma versão com a mensagem 'Formulário de encomenda pelo WhatsApp'".

Resumo

• O resumo do Claude pode ser verdade e ainda deixar coisas de fora. Confira antes de guardar a versão.
• Primeiro, use a página como um cliente: preencha, clique, tente o que um cliente apressado faria. A prova é um print.
• Depois, veja quais arquivos mudaram, com o /diff, e responda: mudou algum arquivo que eu não pedi? Uma linha a menos no .gitignore pode deixar a senha entrar nas versões.
• Peça a explicação de cada mudança em português simples: a lista diz onde mudou, a explicação diz o quê.
• Peça uma segunda opinião com o /code-review, que começa com o contexto limpo e só relata. Peça a explicação de cada achado e separe em corrigir agora, perguntar por quê e deixar para depois.
• Para desfazer, recuse no Manual, use o /rewind (Esc Esc), que não desfaz o que um comando mudou, ou volte à última versão guardada.

Na próxima aula, você usa as versões guardadas no dia a dia: vê o que mudou de uma para outra, volta atrás quando algo dá errado e retoma uma conversa de onde parou. E quando o revisor apontar o mesmo problema várias vezes, talvez seja hora de escrever uma regra para o Claude ler no começo de toda conversa: é o CLAUDE.md, assunto da Aula 11.