Ao fim deste capítulo, você será capaz de organizar seu dia de trabalho com o Claude Code de forma madura: manter a janela de contexto saudável, controlar o custo de cada sessão, escolher o modelo certo para cada tipo de tarefa e reconhecer os erros mais comuns da inteligência artificial antes que eles cheguem ao repositório. Tudo o que aparece aqui foi construído ao longo dos capítulos anteriores. A tarefa agora é juntar as peças em um fluxo coerente.
A janela de contexto como recurso finito
Desde o capítulo dois você sabe que o Claude Code trabalha dentro de uma janela de contexto, e no capítulo dez viu os sinais de degradação em refatorações longas. Vale entender por que isso acontece. Tudo o que entra na sessão ocupa espaço: suas mensagens, cada arquivo lido, cada saída de comando, cada diff proposto. Quando a janela enche, a ferramenta resume o começo da conversa para caber o restante, e detalhes importantes se perdem. Mesmo antes de encher, uma sessão longa acumula ruído: tentativas descartadas, erros já corrigidos e discussões encerradas continuam influenciando as respostas. Na prática, o Claude começa a esquecer regras que você deu no início, repete erros que já havia corrigido e fica mais lento e mais caro, porque cada resposta reprocessa todo esse histórico.
A regra mais simples é uma sessão por tarefa. Terminou de corrigir um bug e vai começar uma funcionalidade? Use o comando /clear. O que precisa sobreviver entre sessões não deve morar na conversa, e sim no CLAUDE.md, em um plano em Markdown dentro do repositório ou no próprio histórico do Git, como você aprendeu nos capítulos cinco, dez e onze.
Quando a tarefa ainda não acabou mas a sessão já está pesada, prefira o comando /compact, e não o use às cegas. Ele aceita uma instrução de resumo, que orienta o que deve ser preservado. Um exemplo:
/compact Preserve a lista de arquivos alterados, as decisões de design sobre a camada de repositório e os testes que ainda falham. Descarte as tentativas abandonadas e a saída completa dos comandos.
Depois do resumo, peça algo como: resuma em três linhas onde paramos. Se a resposta estiver errada, corrija antes de continuar. É muito mais barato do que descobrir a confusão dez minutos depois.
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
Custo e escolha do modelo
O comando /cost, apresentado no capítulo dois, mostra quanto a sessão atual já consumiu. Vale um aviso: esse valor em dinheiro aparece para quem paga por uso da API; em planos de assinatura, como Pro ou Max, o comando informa o uso da sessão em relação aos limites do plano, e não um custo em reais ou dólares. Crie o hábito de olhar para ele ao final de cada tarefa, não para economizar centavos, e sim para perceber padrões. Uma correção simples que custou o triplo do normal quase sempre revela um problema de contexto, como arquivos gigantes lidos inteiros ou saídas de teste sem filtro.
O Claude Code também permite trocar o modelo em uso, com o comando /model durante a sessão ou com a opção --model ao iniciar. A lógica é a mesma que você aplicaria a pessoas de um time. Tarefas mecânicas e bem definidas, como renomear, formatar, escrever uma mensagem de commit ou gerar um teste a partir de um exemplo claro, vão bem com o modelo mais rápido e mais barato. Tarefas que exigem raciocínio em várias etapas, como diagnosticar uma condição de corrida, planejar uma refatoração ampla ou avaliar trade-offs de arquitetura, merecem o modelo mais capaz. No capítulo catorze você viu que subagentes podem ter modelo próprio; aproveite isso para colocar o modelo barato nas buscas e o modelo forte nas decisões.
Para os problemas realmente difíceis existe o modo de pensamento estendido. Basta pedir explicitamente que ele pense mais antes de agir. As palavras-chave documentadas pela Anthropic são em inglês, em ordem crescente de esforço: think, think hard, think harder e ultrathink. Dependendo da versão instalada, o pensamento estendido também pode ser ligado e desligado por um atalho de teclado no próprio terminal, então confira o que a sua versão oferece em vez de confiar em uma expressão específica. Isso custa mais e demora mais, então reserve para bugs intermitentes, decisões arquiteturais e planos de migração, nunca para tarefas rotineiras.
Os erros típicos da inteligência artificial e como se defender
Quatro comportamentos aparecem com frequência suficiente para merecerem nome e antídoto.
Inventar APIs ou bibliotecas
O modelo pode chamar um método que não existe, usar uma opção de configuração inventada ou importar um pacote com nome plausível mas inexistente. Esse fenômeno é chamado de alucinação. A detecção é simples: código que não compila, teste que falha dizendo que algo não é uma função, ou instalação que não encontra o pacote. A prevenção é exigir verificação: peça que ele confirme a assinatura no código-fonte da dependência ou na documentação, use o servidor de documentação via Model Context Protocol do capítulo treze, e coloque no critério de pronto que o comando de build precisa rodar sem erro.
Apagar código sem avisar
Ao reescrever um arquivo, o Claude pode remover um tratamento de erro, um comentário importante ou um caso que julgou desnecessário. Diffs pequenos são a defesa. Quando o diff mostra trinta linhas removidas e você pediu uma linha nova, recuse e pergunte o motivo. Sua instrução deve dizer o que não tocar, como ensinado no capítulo quatro. O Git ajuda, mas ele só protege o que já foi commitado: o que ainda não entrou em um commit e for apagado se perde de vez. Por isso, faça commits pequenos e frequentes antes de pedir mudanças grandes. E cuidado com os comandos de recuperação: git restore (ou git checkout) em um arquivo descarta tudo o que não foi commitado nele, e git revert cria um commit desfazendo outro já registrado. Confira sempre o git status antes de rodar qualquer um dos dois.
Fazer mais do que foi pedido
Chamamos isso de escopo excedido: você pede para corrigir uma validação e recebe também um arquivo renomeado, uma dependência atualizada e três comentários reescritos. Cada mudança extra é um risco não revisado. Declare o escopo no pedido, com frases como apenas este arquivo e não altere nada além do necessário, e recuse diffs que ultrapassem o combinado, pedindo que as ideias extras sejam apenas listadas para uma próxima tarefa.
Testes forjados
Um teste forjado é aquele que passa sem verificar nada: uma asserção trivial, um mock que devolve exatamente o valor esperado ou um teste enfraquecido só para ficar verde. No capítulo nove você aprendeu a proibir a edição dos testes durante a implementação. Complemente lendo cada teste gerado com uma pergunta em mente: que bug este teste pegaria? Se a resposta for nenhum, o teste não existe de verdade.
Quando não usar o Claude Code
Nem toda tarefa se beneficia da ferramenta. Evite usá-la nestas situações:
- Quando você não conseguiria revisar o resultado, por não dominar o domínio ou a linguagem. Código que você não entende é código que você não pode assumir.
- Quando o projeto contém dados que não podem sair da máquina, como informações pessoais ou segredos, e não há permissão da empresa para envio a um serviço externo. Lembre que o Claude Code roda no seu computador, mas cada arquivo que ele lê e cada saída de comando que ele analisa são enviados para os servidores do modelo: não existe modo totalmente offline. Em ambientes regulados, verifique antes a política da sua organização e os termos do plano contratado.
- Quando a mudança é tão pequena que explicar o pedido leva mais tempo do que fazer. Uma linha alterada à mão não precisa de intermediário.
- Quando a decisão depende de conhecimento de negócio que não está no repositório nem no CLAUDE.md. Nesse caso, converse primeiro com as pessoas certas.
Revisar código gerado com o mesmo rigor
A tentação de aprovar rápido é grande, porque o código gerado costuma parecer limpo e confiante. Trate cada diff como o pull request de um colega recém-chegado: talentoso, rápido, mas sem histórico no projeto. Leia a lógica, não apenas o formato. Pergunte o que acontece com entrada vazia, com valor nulo, com falha de rede. Verifique se o comportamento antigo foi preservado quando não deveria mudar. Rode a aplicação, não só a suíte. E lembre que a responsabilidade pelo que entra no repositório é sua, não da ferramenta.
Checklist de um fluxo de trabalho diário
Este checklist reúne o que o livro ensinou em uma rotina que cabe em um dia comum:
- Antes de começar, confira que o Git está limpo e que você está em uma branch de trabalho, como no capítulo onze.
- Abra uma sessão nova para a tarefa do dia e confirme que o CLAUDE.md do projeto está atualizado com comandos de build e teste, conforme o capítulo cinco.
- Revise as regras de permissão do capítulo seis: arquivos de segredo negados, comandos destrutivos bloqueados e o modo de permissão adequado ao ambiente.
- Em tarefas não triviais, comece no modo de planejamento e critique o plano antes de qualquer edição.
- Implemente em etapas pequenas, revisando cada diff e recusando o que ultrapassar o escopo.
- Rode a suíte de testes ao fim de cada etapa e exija testes novos que peguem bugs reais.
- Faça commits pequenos com mensagens geradas a partir do diff, e abra o pull request pelo GitHub CLI quando a tarefa fechar.
- Deixe hooks cuidando do que deve ser determinístico, como formatação e bloqueios, e comandos personalizados cuidando do que é repetitivo, como ensinado no capítulo doze.
- Ao trocar de tarefa, olhe o /cost, anote o que aprendeu no CLAUDE.md se for permanente, e use /clear.
Recapitulando
Neste capítulo você consolidou o uso maduro do Claude Code. Viu que a janela de contexto é um recurso finito e que sessões longas degradam a qualidade, o que se resolve com uma sessão por tarefa, /clear entre tarefas e /compact com instrução de resumo dentro delas. Aprendeu a acompanhar o consumo com /cost, a escolher entre o modelo mais barato e o mais capaz conforme a complexidade e a reservar o pensamento estendido para problemas difíceis. Conheceu os quatro erros típicos, alucinação de APIs, remoção silenciosa de código, escopo excedido e testes forjados, e as defesas de verificação, diffs pequenos e critérios de pronto. Por fim, identificou quando a ferramenta não deve ser usada, como revisar código gerado com o mesmo rigor de código humano, e reuniu CLAUDE.md, permissões, testes, Git e automação em um checklist diário.
