Módulo 1.2 — O método de ablação

🔬 Entenda o que ablação significa

Ablação é um termo emprestado da pesquisa: você remove um componente de um sistema para medir o impacto que ele tinha. Não é faxina, não é opinião — é experimento. A pergunta que a ablação responde é sempre a mesma: o que muda quando isso não está mais aqui?

Aplicado a prompt e configuração, o método é literal: apaga-se o prompt de sistema inteiro e depois traz-se cada linha de volta, uma por vez, para descobrir o que cada linha realmente faz. Foi assim que a equipe do Claude Code descobriu que mais de 80% do próprio prompt de sistema não estava fazendo nada — o modelo já resolvia aquilo sozinho.

🆕 Novo aqui? Três palavras deste módulo

Ablação: remover um pedaço do sistema de propósito para medir quanto ele contribuía.
Hook: um gancho de automação do Claude Code — um comando que dispara sozinho antes ou depois de uma ação (ex.: rodar o formatador toda vez que um arquivo é salvo).
Linha de base (baseline): a medição de referência — como o sistema se comporta sem nada por cima. É contra ela que você compara tudo o mais.

O que olhar: as duas rotas têm o mesmo número de passos e a de cima até parece mais responsável (“eu li tudo com atenção”). Mas repare na última caixa de cada linha: só a de baixo termina em um dado. Revisar o prompt lendo produz opinião; remover e usar produz evidência. Repare também que o passo em ciano — “usar de verdade” — é o único que não acontece na sua cabeça.

✓ Isso é ablação

✓Tirar a instrução e rodar a mesma tarefa real de novo
✓Comparar o resultado com e sem, na mesma tarefa
✓Concluir “empatou” e deixar removido

✗ Isso não é ablação

✗Reler o CLAUDE.md e achar que a linha 42 é importante
✗Pedir ao modelo para “revisar meu prompt” — ele também está adivinhando
✗Cortar tudo de uma vez e nunca usar a config cortada em trabalho real

📅 Marque quando apagar

O conselho de Boris Cherny para quem usa Claude Code — e não constrói produtos agênticos — é inconfortavelmente direto: aproximadamente a cada seis meses, e principalmente em um lançamento grande de modelo, apague o CLAUDE.md, apague as skills, apague os hooks — e veja o que o modelo faz sem eles. Não é retórica. É a recomendação literal.

Duas razões sustentam esse calendário, e vale entender as duas porque elas puxam na mesma direção.

📊 As duas razões, em números

Você é péssimo previsor. Nem a equipe que construiu o Claude Code acertava: quando mediram, mais de 80% do prompt de sistema era peso morto. Se quem escreveu o harness errou por 80%, sua intuição sobre o próprio CLAUDE.md não é melhor.
Cada linha custa em toda execução. Uma regra no CLAUDE.md não é lida “quando for necessária”. Ela entra no contexto em 100% das execuções, inclusive nas 95% em que é irrelevante. O custo não é o de escrever a linha — é o de relê-la para sempre.
O gatilho não é o calendário sozinho. Lançamento grande de modelo vale mais que a data: é exatamente aí que fraquezas antigas desaparecem e as correções escritas para elas viram lastro.

💡 "Apagar" aqui é reversível

Apagar não significa destruir. Significa tirar de circulação por um período de trabalho real, com a versão antiga guardada e recuperável — em git, ou simplesmente renomeando o arquivo. Se você não consegue voltar em 30 segundos, você não está fazendo um experimento: está fazendo um risco. O tópico 4 mostra como montar essa rede.

🔁 Siga as 4 etapas da reconstrução

Apagar é só a primeira metade. A reconstrução é o que decide se a nova configuração vai ficar realmente menor ou apenas diferente. São quatro etapas, e a quarta é a única que costuma ser pulada — que é exatamente por que a maioria das configs volta ao tamanho original em duas semanas.

O ciclo, etapa por etapa

1
Apague a configuração

CLAUDE.md, skills, hooks. Fora de circulação, com a versão antiga guardada. Sem meio-termo: cortar “só as piores” não mede nada, porque você continua confiando na sua previsão sobre quais eram as piores.
2
Use em trabalho real — nunca em teste hipotético

O produto de verdade, a base de código de verdade, a tarefa que você faria hoje de qualquer jeito. Teste inventado produz falha inventada: você acaba devolvendo instruções para problemas que nunca teria na prática.
3
Observe onde vai bem e onde tropeça

Registre os dois lados. Anotar só os tropeços enviesa a leitura — você termina o experimento convencido de que tudo piorou, quando 90% ficou igual. O acerto sem instrução é a evidência mais valiosa que existe.
4
Devolva uma instrução só depois de ver a falha REPETIR

Esta é a etapa que importa. Uma falha isolada pode ser ruído: contexto ruim, pedido ambíguo, dia estranho. Só a repetição da mesma classe de falha prova que existe uma lacuna estrutural — e só uma lacuna estrutural justifica pagar contexto para sempre.

O que olhar: a seta ciano tracejada é a mais larga do desenho por um motivo. Na prática, a maioria das observações termina nela — o tropeço não se repete, e você simplesmente continua trabalhando sem escrever regra nenhuma. A caixa 4, com o brilho, parece o destino do fluxo, mas está marcada como “saída rara”. Uma config que cresce toda semana é uma config em que essa volta nunca é usada.

⚙️ Monte sua linha de base

Existem dois mecanismos para rodar sua própria ablação. O primeiro é a flag de prompt de sistema na inicialização do Claude Code: ela substitui o prompt de sistema pelo que você quiser — inclusive por nada. O segundo é a variável de ambiente CLAUDE_CODE_SIMPLE=1, pouco documentada, que remove todos os prompts de sistema — inclusive os prompts associados a cada ferramenta. É a linha de base de ablação usada internamente na Anthropic.

Uma variável de ambiente é um valor que você define no terminal e que o programa lê ao iniciar; escrevê-la na frente do comando (VAR=1 comando) vale só para aquela execução — nada fica configurado permanentemente. É por isso que ela é o instrumento perfeito para um experimento.

🧪 Copie e rode: a linha de base

Objetivo: abrir uma sessão sem prompt de sistema nenhum e, em seguida, uma sessão sem o seu CLAUDE.md. As duas são reversíveis.

# 1) Linha de base total — remove TODOS os prompts de sistema,
#    inclusive os das ferramentas. Vale só para esta sessão.
CLAUDE_CODE_SIMPLE=1 claude

# 2) Alternativa mais segura — mantém o produto normal,
#    mas tira só a SUA configuração do caminho.
mv ~/.claude/CLAUDE.md ~/.claude/CLAUDE.md.bak
claude          # trabalhe normalmente por alguns dias

# 3) Restaurar quando quiser (ou quando o experimento acabar)
mv ~/.claude/CLAUDE.md.bak ~/.claude/CLAUDE.md

Como verificar: três sinais de que a ablação realmente está ativa — (1) ls ~/.claude/CLAUDE.md retorna “No such file” durante o experimento; (2) na sessão, peça “resuma em uma frase as regras que você recebeu neste projeto” — se ele repetir as suas regras de sempre, alguma coisa não foi removida (checar o CLAUDE.md do projeto, além do global); (3) o comportamento muda em algo — se nada mudou em nada, ótimo: esse já é o primeiro resultado do experimento.

Troque: o caminho global por ./CLAUDE.md se o que você quer ablacionar é a config de um projeto específico.

⚠️ Faça isso com a config sob git

Antes de mover ou apagar qualquer coisa, garanta que ~/.claude/ (ou a pasta .claude/ do projeto) esteja versionada e com tudo commitado. Um mv mal digitado num diretório sem git leva embora meses de skills e hooks sem aviso — e o experimento vira prejuízo.

Regra prática: se você não consegue restaurar tudo com um comando, não comece. Skills e hooks também entram nessa conta, não só o CLAUDE.md.

💡 O detalhe contraintuitivo

Sem os prompts de sistema, o modelo fica ligeiramente mais inteligente. Não é erro de leitura: menos instrução, resultado um pouco melhor. O prompt custa atenção, e parte dele empurra o modelo para caminhos que ele não precisaria mais seguir.

Então por que os prompts continuam lá? Porque eles fazem o Claude Code se comportar como a pessoa espera ao usar um produto: formato de saída previsível, permissões, tom, uso de ferramentas. A conclusão prática para você é boa: se nem o prompt oficial existe por causa de capacidade, muito menos as suas 300 linhas de CLAUDE.md.

🎯 Aposente suas evals no tempo certo

Se instruções envelhecem rápido, o que dura? Evals duram mais — mas não para sempre. Uma eval sobrevive tipicamente de uma a três gerações de modelo antes de o modelo saturá-la; nesse ponto ela é descartada e substituída por outra, mais difícil.

🆕 Novo aqui? Eval e saturação

Eval: um caso de teste para o modelo. Uma tarefa concreta, com um jeito claro de dizer se o resultado passou ou não. É o “teste automatizado” do seu trabalho com o agente — mede capacidade, não corrige comportamento.
Saturar uma eval: o modelo passa a acertá-la sempre. A partir daí ela para de informar qualquer coisa: seja o modelo bom ou ótimo, o resultado é o mesmo. Uma eval saturada é ruído travestido de métrica.

✓ Eval que vale manter

✓Nasceu de um ponto onde você realmente observou o modelo tropeçar
✓Ainda falha às vezes — o resultado varia, então ainda mede algo
✓Usa uma tarefa do seu trabalho de verdade, com critério de aprovação escrito antes

✗ Eval para aposentar

✗Passa 100% das vezes há três gerações de modelo
✗Foi inventada em teoria (“seria bom testar isso”), sem falha observada por trás
✗Testa uma fraqueza de um modelo que você nem usa mais

📊 A curva de vida de uma eval

Geração 0: você vê a falha em trabalho real e transforma o caso numa eval. Ela reprova com frequência.
Geração 1 a 3: a taxa de acerto sobe, mas oscila. É a fase útil — a eval ainda separa modelo bom de modelo ótimo.
Saturação: acerto constante em 100%. A eval não distingue mais nada; mantê-la só gasta tempo de execução e dá falsa sensação de cobertura.
Aposentadoria: arquive (não delete o histórico — ele documenta o que já foi difícil) e escreva uma nova a partir do tropeço mais recente que você observou.

💡 Eval não é instrução

Confusão comum: “se o modelo erra X, escrevo uma regra sobre X”. Mas eval e instrução resolvem coisas diferentes. A eval detecta o problema e custa zero contexto — ela roda quando você a roda. A instrução tenta corrigir o problema e custa contexto em toda execução. Diante de uma falha nova, a eval vem primeiro; a instrução, só se a regra de reintrodução do próximo tópico autorizar.

📓 Aplique a regra de reintrodução

Uma instrução removida não volta porque você sentiu falta dela. Ela volta quando passa por quatro condições, todas juntas. Se qualquer uma faltar, a instrução continua fora — e o trabalho continua normalmente sem ela.

✓ As 4 condições para devolver

✓1. Falha real: aconteceu em trabalho seu, não num teste inventado
✓2. Repetição: a mesma classe de falha voltou pelo menos uma segunda vez
✓3. Instrução específica resolve: dá para apontar qual frase evitaria aquilo
✓4. Forma mais curta possível: uma linha, não um procedimento de 12 passos

✗ Motivos que não contam

✗“Eu me sinto mais seguro com essa regra lá”
✗Errou uma vez, num pedido que você mesmo escreveu mal
✗“Já que estou mexendo, aproveito e devolvo as outras três”
✗A falha era outra e você devolveu a regra antiga por associação

📝 Exercício: crie seu `ablacao-diario.md`

Objetivo: registrar uma tarefa real feita com a config ablacionada. Sem diário, a etapa 4 do ciclo é impossível — você não tem como saber se a falha repetiu.

# Diário de ablação

Config ablacionada em: 2026-08-18
O que saiu: CLAUDE.md global · skills X e Y · hook de pre-commit
Como restauro: `mv ~/.claude/CLAUDE.md.bak ~/.claude/CLAUDE.md`

---

## Tarefa 1 — <o que você realmente precisava fazer>
- **Data:** 2026-08-18
- **Tarefa real:** refatorar o módulo de export do projeto Z
- **Acertos (foi bem sem instrução):**
  - encontrou os arquivos certos sozinho
  - rodou os testes sem eu pedir
- **Tropeços (onde falhou):**
  - commitou sem eu autorizar
- **Classe do tropeço:** permissão / commit não solicitado
- **Repetiu?** ainda não (1ª ocorrência)
- **Instrução devolvida:** NENHUMA — aguardando repetição

Como verificar: o campo “Classe do tropeço” é o que faz o diário funcionar. Ele precisa ser genérico o bastante para você reconhecer a mesma falha daqui a uma semana num contexto diferente — “commitou sem autorizar” é classe; “commitou o arquivo utils.ts às 14h” é anedota. Se você não consegue nomear a classe, o tropeço provavelmente foi ruído.

Critério de saída deste módulo: diário com ≥1 tarefa real registrada, com acertos, tropeços e “repetiu?” preenchidos — e nenhuma instrução devolvida ainda. Devolver na primeira ocorrência é o erro que este módulo inteiro existe para evitar.

Você apagou o CLAUDE.md e, na primeira tarefa real, o modelo commitou sem autorização. O que a regra de reintrodução manda fazer?

📌 Resumo do Módulo

✓

Ablação é apagar para medir — remover um componente para descobrir o impacto real dele. Reler o prompt não mede nada.

✓

A cada ~6 meses e em lançamento grande de modelo — apague CLAUDE.md, skills e hooks e veja o que o modelo faz sem eles.

✓

Quatro etapas, e a quarta é a que importa — apagar, usar em trabalho real, observar, devolver só depois da falha repetir.

✓

CLAUDE_CODE_SIMPLE=1 é a linha de base — remove todos os prompts de sistema; sem eles o modelo fica ligeiramente mais inteligente.

✓

Evals duram 1 a 3 gerações — crie-as onde observou o tropeço; aposente as que o modelo saturou.

✓

Reintrodução exige as 4 condições — falha real, repetida, com instrução específica, na forma mais curta possível.

Próximo Módulo:

2.1 — A taxonomia: o que cada linha é. Dez categorias, seis decisões e as sete perguntas que classificam qualquer instrução da sua config.

← Voltar para Trilha Próximo Módulo →