Aula 09Revisar o que o Claude fez

🖥️ Versão Desktop. Nesta versão do curso, você usa o Claude Code no app Claude Desktop, na aba Code. Quase tudo é feito por janelas e botões. Quando uma aula pedir para digitar um comando, ela mostra exatamente o que digitar. Nesta aula, o único comando que você digita é o /code-review, na caixa de mensagem (o Para ir além mostra mais alguns, para quem programa). Os comandos do Git quem roda é o Claude, e no Manual cada um espera a sua aprovação, menos os que só olham.

Objetivos

Ao final desta aula você vai saber:

• Conferir uma mudança pelo comportamento, usando a página como um cliente usaria, no seu navegador ou no painel Browser
• Ver quais arquivos mudaram no diff do app, 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 e agir pelo card Code review
• 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 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.

Na aba Code, abra uma sessão Local na pasta da página, com o seletor de modo em 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, 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, como nas aulas anteriores (dois cliques no index.html, dentro da pasta da sua página, 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, arraste para a caixa de mensagem, como na Aula 04, 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.

Você também pode pedir que o Claude teste no painel Browser. Clique no caminho do index.html na conversa, e a página abre no painel, ao lado da conversa. Ali, ele tira prints, clica e preenche formulários. Peça:

Abra a página no painel Browser, preencha o formulário, tente enviar sem o nome e me mostre um print.

O clique no Enviar pelo WhatsApp, faça você mesmo, no seu navegador de sempre: ele sai da sua pasta e vai para o site do WhatsApp.

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.

Quando o Claude muda arquivos, o app mostra quantas linhas entraram e saíram, como +82 -5, no card Changes (mudanças), no painel ao lado da conversa. Clique nesse indicador de linhas alteradas para abrir o diff, arquivo por arquivo. Se o painel não estiver aparecendo, clique em Show session rail (mostrar o painel da sessão), na barra de título da sessão, ou no menu ⋮ dela, se a janela estiver estreita. O diff também abre pelo botão Changes, na barra de título da sessão, ou com Cmd + Shift + D no Mac (Ctrl + Shift + D no Windows).

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

Confira a lista inteira, até o fim. 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 na caixa de mensagem:

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 espera a sua aprovação: você vê o diff e aceita ou recusa. Apagar o package.json aparece como um comando, que também espera. 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, abra o diff de novo: agora, só o index.html e o estilo.css aparecem.

💡 Um ajuste numa linha só? Dá para comentar direto no diff: clique na linha, escreva o pedido e aperte Enter. Com vários comentários prontos, envie todos de uma vez com Cmd + Enter no Mac (Ctrl + Enter no Windows). O Claude lê os comentários e faz as mudanças, que aparecem num diff novo para você revisar.

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. Digite na caixa de mensagem:

/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.

Na sessão Local, os achados chegam num card Code review, agrupados por arquivo. Pelo card, você age sobre eles:

• Walk through in diff (percorrer no diff) abre o diff e passa pelos achados um por um. Cada achado aparece na sua linha, onde você clica em Fix this one (corrigir este) ou dispensa o achado.
• Apply fixes (aplicar as correções) pede ao Claude para corrigir todos os achados que ainda estão abertos.

⚠️ Separe os achados antes de clicar em Apply fixes. Ele corrige tudo o que está aberto, inclusive um achado que pode estar errado, como o 2 do exemplo abaixo.

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 na caixa de mensagem 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. Dispense esse achado: no Walk through in diff, ele aparece na sua linha. Na Aula 19, com a página no ar, você testa no celular de verdade.

Para corrigir agora, clique em Walk through in diff no card e, na linha de cada achado, em Fix this one. Ou peça na caixa de mensagem, junto com 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. Se preferir, peça que ele confira no painel: "abra a página no painel Browser, escolha a data de ontem e me mostre um print". 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á duas saídas:

1. Antes de a mudança acontecer: recuse. No Manual, o Claude propõe cada mudança e espera a sua aprovação. Se você recusar, o arquivo não muda, e o Claude pergunta como você quer seguir. Responda na caixa de mensagem, com o motivo, como na Aula 05.
2. Depois que ela aconteceu: 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.

⚠️ Um limite. 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, um pedido de limpeza 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: confira a lista inteira de arquivos do diff, inclusive os de teste e os gerados (como o package-lock.json). É justamente nos testes que mora um dos problemas mais comuns.

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.

Quando o Claude corrige os achados, a lista do card é atualizada e marca cada um como corrigido, pulado ou sem mudança necessária.

Limpeza, não caça a bugs

Além de caçar bugs, vale pedir uma limpeza no código que mudou: o que dá para deixar mais simples, como uma função auxiliar que já existia e foi reescrita, código repetido, algo ineficiente ou no nível de abstração errado. O Claude Code tem uma skill pronta para isso, o /simplify, que também funciona no app: digite /simplify na caixa de mensagem, ou escolha em + → Slash commands. Ele põe quatro agentes para revisar o código que mudou, um para cada aspecto, e já aplica as correções. Se preferir, peça com suas palavras:

Revise o código que mudou e simplifique o que der: funções auxiliares que
já existiam e foram reescritas, código repetido e trechos ineficientes.
Não mude o comportamento.

Uma limpeza não procura bugs: para isso, continue usando o /code-review. E, como ela edita o código, confira o 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. Na aba Code, na linha abaixo da caixa de mensagem, escolha Local e a pasta da sua página. Antes da primeira mensagem, escolha Manual no seletor de modo, na mesma linha.
2. Faça o pedido do formulário de encomenda, como no exemplo, com o número inventado. A cada mudança, olhe o diff e aceite 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, arraste para a caixa de mensagem e peça para o Claude conferir o critério.
4. Clique no indicador de linhas alteradas, no card Changes, 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 na caixa de mensagem e espere o card Code review. 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, antes de usar o Apply fixes.
7. Para cada "corrigir agora", clique em Fix this one ou peça a correção com o jeito de conferir, e mande um print. Para cada "perguntar por quê", cite o achado de volta na caixa de mensagem 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, seu ou do Claude, no painel Browser.
• Depois, veja quais arquivos mudaram, no indicador de linhas alteradas do card Changes, 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, no card Code review. Peça a explicação de cada achado e separe em corrigir agora, perguntar por quê e deixar para depois, antes de usar o Apply fixes.
• Para desfazer, recuse no Manual, antes de a mudança chegar aos arquivos, 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.