Depois dos capítulos 1 e 2 você já deve ter noção do que o Claude Code é e de como ele se move. O que este capítulo constrói é um ritmo que você consegue repetir do mesmo jeito todo dia: os quatro tempos de explorar, planejar, implementar e commitar.
O motivo de precisar de um formato é simples. Nos dias em que não funciona, a causa costuma ser um tempo pulado. Você mandou escrever sem ler, entregou a tarefa sem um meio de verificação, deixou rodar sem pontos de parada. Os sintomas variam, mas o lugar para onde você volta é o mesmo.
O formato de um dia — quatro tempos
Faça ele ler os arquivos que importam e colocar o estado atual em palavras. Ainda sem escrever.
Traga os passos para a frente e corrija você mesmo. O único ponto barato para consertar.
Deixe escrever e rode a checagem ali mesmo. Deixe o loop do capítulo 1 dar a volta inteira.
Assim que passar, marque um ponto de retorno. A próxima exploração começa daqui.
A medida de uma volta é "se você não consegue lembrar como chegou até aqui, ela foi grande demais". Quatro voltas de uma hora ganham de uma volta de meio dia quase sempre.
Isso não quer dizer fazer os quatro toda vez. Corrigir um erro de digitação não precisa de plano. O que você está julgando é qual tempo dá para cortar, e a posição de partida é "faça todos".
Antes de começar, entregue um meio de verificação
Há uma coisa a fazer antes de entrar nos quatro tempos: dar ao Claude, de antemão, um jeito de conferir o próprio trabalho.
Como mostrou o capítulo 1, o que roda por baixo é o loop coletar → agir → verificar. Ele é forte porque o STEP 3 existe, então consegue seguir corrigindo até os testes passarem. Virando isso do avesso, sem um meio de verificação o loop para depois de uma volta: ele escreve, provavelmente está certo, acabou. Isso é uma ferramenta de chat.
"Faça os testes passarem" já basta. A saída da falha vira a próxima entrada, e o loop gira sem você olhando.
Você roda, você relata o resultado, você pede de novo. Você vira o gargalo. Só parece que você delegou.
O que você entrega não precisa ser elaborado. Uma linha dizendo "rode este comando e você vai saber se está certo" já resolve. E isso é mais seguro escrito em um arquivo do que dito em voz alta: um CLAUDE.md na raiz do projeto é relido do disco mesmo depois de uma compactação.
O que vale a pena colocar no CLAUDE.md (exemplos)
- Comandos a rodar depois de uma mudança: testes / checagem de tipos / linter
- Não relatar "pronto" enquanto eles ainda estiverem falhando
- Lugares em que não se mexe: saída gerada, configuração de produção etc.
Escreva isso e ele passa a se conferir depois de cada mudança sem que você diga "rode os testes" toda vez. Não é que você dê menos instruções, é que menos momentos precisam de uma. É assim que um formato compensa (como escrevê-lo é o capítulo 6). As tarefas que o capítulo 1 colocou do lado "serve mal" caem aqui também, porque não há meio de verificação para entregar.
Explorar — faça ele ler antes de escrever
Primeiro tempo. Há uma única tarefa: fazer ele ler os arquivos relevantes e explicar como as coisas estão agora. Ainda sem escrever. Pule isso e o Claude preenche por chute as partes que não leu. Volta um código plausível, sutilmente fora de compasso com o modo como o resto foi escrito, e você percebe a diferença na revisão ou em produção.
Exploração ruim: "Conserte a autenticação"
→ a edição começa na hora. você nunca vê o que ele supôs
Exploração boa: "Encontre e leia os arquivos envolvidos na autenticação.
Explique como o login é tratado hoje,
junto com uma lista dos arquivos envolvidos.
Ainda não mude nada."
→ as suposições aparecem na tela. se estiverem erradas, corrija aqui
A explicação que volta é para você ler. Este é o ponto mais barato para intervir. "Esse arquivo não é mais usado" custa uma frase, uma fração mínima do que custa achar uma implementação errada na revisão.
A exploração também tem um preço. Todo arquivo lido cai no contexto, então, quanto mais amplo você explora, menos espaço sobra depois: a frase do capítulo 1 sobre ficar lento e esquecer o começo nasce aqui. Três formas de segurar isso.
- Delimite o escopo: "só o lado da autenticação, por enquanto". Você precisa do formato do todo, não de cada arquivo dele
- Leia arquivos enormes em partes: ler o arquivo inteiro enche tudo rápido. Um intervalo de linhas ou uma única função costuma bastar
- Separe as investigações de saída pesada: vasculhar logs e buscas em massa vão para um subagent. Ele tem o próprio contexto e devolve só um resumo, então o principal não incha (capítulo 6)
Planejar — quando o modo de planejamento compensa e quando pesa
Segundo tempo. Coloque na mesa o que muda e em que ordem antes de qualquer escrita. O Claude Code tem um modo de planejamento exatamente para este tempo: ele investiga, para na apresentação do plano e não avança para a escrita até você aprovar. Como entrar nele varia conforme a versão, então consulte a ajuda da versão que você tem.
O que ele faz de verdade é mover o portão de permissão de "cada edição" para "a entrada do trabalho". Por padrão, vem uma checagem a cada chamada de ferramenta; o modo de planejamento junta todas em uma e a traz para a frente. O que você aprova deixa de ser "esta linha" e passa a ser "a abordagem deste trabalho".
Atravessa vários arquivos / há mais de um jeito de fazer / precisa combinar com um design existente / desfazer um erro é doloroso / você também ainda não decidiu o melhor movimento
Há só uma coisa a fazer / os passos já estão decididos / um erro se desfaz na hora / ler o plano leva mais tempo que a implementação
Pule o lado direito sem culpa. Planos não são de graça: custam tempo para criar, tempo para ler e contexto. Quando um chegar, olhe exatamente três coisas. 1. As suposições estão certas? (se o primeiro tempo saiu torto, o plano inteiro sai torto junto). 2. A verificação está lá dentro? (se falta "fazer os testes passarem", acrescente). 3. Os passos são pequenos o bastante? (um plano que faz tudo em um movimento só deixa você sem conseguir localizar a causa quando falha).
Para trabalhos longos, ponha o plano em um arquivo. Um plano que existe só dentro da conversa é esmagado em um resumo assim que a sessão fica longa. Mande escrevê-lo em algum lugar como um PLAN.md e você consegue relê-lo depois de dobrar o contexto, e ele ainda serve de ponto de retomada quando você se ausenta.
Implementar — passos pequenos, corrigidos enquanto roda
Terceiro tempo. Só agora ele escreve. Dois princípios.
Um: rode a checagem depois de cada movimento. Junte cinco mudanças e só então teste, e você acabou de criar para si a tarefa de descobrir qual delas quebrou. Escreva uma, faça passar uma, e a causa é o movimento que você acabou de fazer. Isso é mais por você do que pelo Claude.
Dois: entregue a saída da falha como ela é. Não é preciso resumir e retransmitir. O STEP 3 é "ler a saída e voltar ao STEP 1", então a saída crua é a entrada com mais informação. Mastigá-la para o Claude na verdade tira pistas.
Uma volta durante a implementação (repita em passos pequenos)
[EDITAR] reescrever exatamente um item do plano
↓
[EXECUTAR] rodar os testes / a checagem de tipos
↓
verde → siga para o próximo item (ou commite)
vermelho → leia a saída e volte para [EDITAR]
Três vermelhos seguidos no mesmo lugar: pare de pedir correções
→ tire as mãos do teclado e passe ao diagnóstico (capítulo 4)
Essa última linha é uma regra prática. Quando a mesma falha começa a se repetir, normalmente não é "quase consertado", e sim um sinal de que alguma suposição está errada.
Quando a checagem demora — um build longo, esperar a CI — dá para delegar em vez de ficar sentado ali. O Claude Code consegue repetir uma instrução em um intervalo definido e, quando você omite o intervalo, o próprio Claude decide quando olhar de novo e para o loop assim que julga o trabalho concluído. Como funciona e o que ele não consegue fazer está em O que é o comando /loop. Fique atento: fechar a sessão interrompe o loop.
Commitar — quem marca as paradas é você
Quarto tempo. Assim que os testes passarem, commite ali mesmo. Não "depois que eu chegar a um ponto bom de parar": o momento em que passa é o ponto bom de parar.
- Vira um ponto de retorno: quando o próximo movimento falhar, você consegue voltar a um lugar que estava comprovadamente verde
- Mantém o diff legível: meio dia de mudanças não dá para ler. Um diff que ninguém consegue ler não é revisado de fato
- Libera você para cortar a conversa: com o trabalho guardado, jogar uma sessão fora deixa de assustar
Deixar que ele escreva a mensagem do commit está de bom tamanho, mas não aprove sem olhar o diff. Decida que você não está procurando "o que mudou", e sim "se entrou junto algo que eu nunca pretendi mudar", e seus olhos param de deslizar por cima.
Note que commitar e fazer push são decisões separadas. Até onde delegar operações difíceis de desfazer, deploy entre elas, é o capítulo 5.
Como dobrar uma sessão e como rebobinar
Algumas voltas nos quatro tempos e você sempre esbarra no contexto enchendo. Quando os dois sintomas do capítulo 1 aparecem — respostas lentas, começo esquecido — é hora de dobrar. Há dois caminhos, compactar e recomeçar, e uma única coisa decide entre eles.
Se o que vem a seguir é continuação, compacte: você carrega o histórico como resumo, e poder dizer o que preservar é o que separa isso da versão automática. Se o que vem a seguir é outro assunto, recomece: se você nem precisa do resumo, também não precisa pagar para produzi-lo. Não arrastar trabalho sem relação ainda melhora a precisão.
O momento também tem um formato. Aperte em uma pausa do trabalho, não pelo relógio nem por uma porcentagem: quando uma volta termina, pouco antes de começar um trecho longo. Aperte no meio do fluxo e detalhes que você ia usar são esmagados no resumo. O raciocínio está em Devo rodar o /compact em intervalos fixos?.
Antes de dobrar, tire para um arquivo tudo que você não pode perder. O CLAUDE.md na raiz do projeto e a memória automática são relidos do disco, então sobrevivem a quantas dobras forem, mas as decisões que vivem só na conversa ficam diluídas pelo resumo.
Há outro mecanismo que muda a própria forma de delegar. O Claude Code cria um ponto de retorno automaticamente a cada prompt, então, quando algo dá errado, você consegue rebobinar até um deles. Dá para escolher só o código, só a conversa ou os dois, e o que você mais vai usar é "desfaça o código, mantenha a conversa": as mudanças são desfeitas enquanto você ainda lembra o que havia de errado nelas, então dá para reformular.
O que torna isso valioso é menos a comodidade e mais a mudança no risco que você consegue assumir. Acreditando que não dá para desfazer, você confere cada movimento, e a graça de usar um agente se dilui. Sabendo que dá para desfazer, você entrega pedaços maiores, e tentar e jogar fora se estiver ruim vira uma opção.
O que rebobina, porém, são apenas "os arquivos que o Claude mudou com uma ferramenta de edição". Arquivos que um comando de shell criou ou apagou, as suas próprias edições e o estado de um banco de dados não voltam. Isso não substitui o Git, e parte do princípio de que você também commita nos marcos. A linha se traça assim: trabalho que se resolve dentro de edições de arquivo, entregue em pedaços grandes. Trabalho que muda estado por meio de um shell, commite antes de entregar. Os detalhes estão em Checkpoints e rewind.
Pedir revisão — separe quem escreveu de quem lê
Código que passa nos testes não é necessariamente bom código. Os testes garantem que nada está quebrado, mas não dizem nada sobre se aquele era o jeito certo de escrever.
Um princípio. Separe o contexto que escreveu do contexto que lê. Dizer "revise isto" na mesma conversa que acabou de terminar a implementação tende a carimbar o próprio julgamento. Enxergar cada razão por trás de cada escolha é um estado ruim para achar buracos. Três movimentos concretos.
- Leia em uma sessão separada: commite, gere um diff e entregue só o diff a uma conversa em branco. Faça a leitura por olhos que não conhecem o histórico
- Nomeie o ângulo: não "melhore isso", e sim "condições de contorno", "consistência com o modo como o resto foi escrito". Um pedido vago produz apontamentos vagos
- Não aceite os apontamentos como verdade: confira contra a coisa real. Leia primeiro, antes de mandar corrigir qualquer coisa
O terceiro se conecta ao resto do capítulo. Revisão é o caso exemplar de "tarefa sem meio de verificação" e, sem nada resolvendo automaticamente o certo do errado, o Claude vai dizer coisas fora do alvo em tom confiante. Empurre isso direto para uma instrução de correção e você quebra código que estava certo: trate os apontamentos como candidatos e julgue um por um. Quando você se pegar querendo os mesmos ângulos toda vez, é o sinal de transformar isso em maquinário (capítulo 6).
Várias sessões — até onde compensa
Tocar outra coisa enquanto um lado roda um teste demorado: a ideia surge naturalmente. O Claude Code consegue iniciar várias sessões independentes em segundo plano e gerenciá-las em uma tela só. O coração disso é o isolamento: uma sessão em segundo plano vai para o próprio diretório de trabalho antes de editar qualquer arquivo. As leituras são compartilhadas, as escritas são separadas, então duas sessões sobrescrevendo o mesmo arquivo não acontece por construção. Os detalhes estão em O agent view e o dispatch.
As tarefas são independentes entre si / você não precisa acompanhar o meio / julgar pelo resultado basta / um dos lados é uma espera longa
Dependem da mesma decisão de design / a direção precisa ser redefinida no meio / incluem operações que você não consegue desfazer / mais resultados do que você consegue conferir
O último item da direita é a restrição que morde mais forte. Paralelizar multiplica o total de revisão. Dispare três e voltam três perguntas do tipo "é isso mesmo?"; a conferência não é paralelizada. O teto de quantas você pode disparar é quantos resultados você consegue verificar. O custo também sobe: segundo plano não quer dizer barato (capítulo 7).
Antes de começar a rodar coisas em paralelo, revise as suas configurações de permissão. As sessões que rodam em segundo plano herdam as permissões das suas configurações em vez de escolhê-las na hora. Quanto mais frouxo o seu ajuste habitual, mais sessões de "permissões frouxas e ninguém olhando" você cria, uma por tarefa. O capítulo 5 vem antes.
O item sem graça que mais causa acidentes é a limpeza. O espaço de trabalho que uma sessão em segundo plano criou vai embora junto com ela quando você apaga a sessão. "Terminado" e "incorporado" são coisas diferentes: commite antes de apagar.
Resumo
- O ritmo de um dia são os quatro tempos explorar → planejar → implementar → commitar. Quando dá errado, a causa costuma ser um tempo pulado
- Antes de começar, entregue um meio de verificação. Sem ele, o loop coletar → agir → verificar para depois de uma única volta
- Explorar é ler antes de escrever. Mas cada arquivo lido custa espaço, então delimite o escopo
- Planejar é o mecanismo que junta o portão de permissão na entrada do trabalho. É pesado para uma tarefa de um movimento só
- Implemente um movimento por vez com uma checagem depois de cada um e, depois de três falhas, mude para o diagnóstico. Commite no momento em que passa
- Compactar ou recomeçar se resolve em "o que vem a seguir é continuação ou outro assunto?" Pouco antes de dobrar, escreva as coisas em um arquivo
- O rewind restaura apenas edições de arquivo. Mudanças feitas por um shell não voltam, então use junto com commits
- Revise em um contexto separado do que escreveu, e trate os apontamentos como candidatos. O teto do trabalho em paralelo é quanto você consegue verificar
Mesmo com um formato, em alguns dias você trava. Deixe o próximo capítulo lhe dar uma ordem para seguir. Siga para o capítulo 4, "Sair do travamento".