Módulo 1.1 — Configuração envelhece

Entenda o que a Anthropic apagou

Boris Cherny criou o Claude Code dentro da Anthropic. Num dia de palestra na Y Combinator — gravada um dia depois do lançamento do Opus 5 — ele contou uma coisa que soa estranha para quem cuida da própria configuração com carinho: o harness do Claude Code nunca está pronto. E, com o Opus 5, o time removeu mais de 80% do prompt de sistema.

🆕 Novo aqui? Três palavras antes de seguir

Harness: a "carcaça" em volta do modelo — o programa que decide quais ferramentas ele tem, como as chama e o que lê antes de responder. O Claude Code é um harness; sua configuração é o harness que você escreveu.
Prompt de sistema: o texto fixo que o produto envia ao modelo antes da sua pergunta, em toda execução. Seu CLAUDE.md é o seu prompt de sistema pessoal.
Ablação: termo de pesquisa — você remove uma parte para medir o impacto dela. É o método que dá nome a este curso.

O motivo é simples e desconfortável: cada modelo é diferente. Uma instrução escrita para o modelo de três meses atrás pode não fazer efeito nenhum no próximo. Por isso, a cada lançamento, o time mexe em quatro coisas.

Reescrevem o prompt de sistema

Não é ajuste fino: é reescrita grande a cada lançamento de modelo.

Trocam o conjunto de ferramentas

O que o modelo pode fazer muda: ferramentas entram, ferramentas saem.

Reescrevem o prompt de cada ferramenta

Toda ferramenta tem seu próprio textinho de instrução — e ele envelhece igual.

Descontinuam ferramentas e apagam partes do harness

Código inteiro sai fora. Ninguém trata o harness como patrimônio — trata como andaime.

💡 A pergunta que abre o curso

Se quem constrói o produto reescreve tudo a cada modelo, por que a sua configuração — escrita ao longo de meses, empilhada linha a linha, nunca revisada — continuaria válida? Não é que ela esteja errada. É que ela foi escrita para um modelo que não existe mais.

Veja por que instrução é conserto datado

Boris foi explícito sobre a natureza do que foi cortado: boa parte do prompt antigo existia só para corrigir comportamentos que o modelo deveria saber executar sozinho — e não sabia. "Sempre leia o arquivo antes de editar." "Não pare no meio da tarefa." "Confira se o teste passou." Cada uma dessas linhas foi escrita porque, um dia, algum modelo falhou naquilo. O Opus 5 faz sozinho. Logo, aquelas linhas viraram peso morto.

O que olhar: a linha não muda de forma em nenhum dos três quadros — o texto dela é exatamente o mesmo do dia 1. O que muda é o mundo em volta. Repare nos rótulos de baixo: útil → inerte → custo puro. Nenhum evento no seu editor marca essa transição; ela acontece do lado de fora, num lançamento de modelo, sem avisar ninguém. É por isso que peso morto só é encontrado quando você procura de propósito.

O salto que provocou o corte não foi cosmético. Vale olhar os números, porque eles explicam por que instruções de "não desista, continue" deixaram de fazer sentido.

📊 O que mudou no Opus 5, segundo a palestra

30% no Arc AGI 3. O Arc AGI é um teste de raciocínio abstrato, feito de propósito para ser difícil de decorar. Os melhores resultados anteriores iam de dígito único até a casa dos 10%.
Roda por dias, semanas ou meses. Combinado com o modo automático, o modelo sustenta uma tarefa longa sem parar no meio.
Não precisa mais de scaffolding para continuar. Scaffolding é o andaime: aqueles empurrõezinhos do tipo "continue", "não pare", "agora faça a próxima etapa". O modelo entende sozinho que a tarefa precisa terminar.

✓ Instrução que ainda conserta algo

✓"O banco de produção é db-prod-2; nunca rode migração nele."
✓"Deploy neste projeto é só via git push — o painel da nuvem é proibido."
✓"A fonte de verdade dos preços é /data/precos.json, não o README."

✗ Conserto que o modelo já não precisa

✗"Leia o arquivo inteiro antes de editar."
✗"Não invente nomes de função; confira se existem."
✗"Continue até terminar, não pare na metade."

Saiba o que sobreviveu ao corte

Cortar 80% não é o mesmo que cortar tudo. O que ficou de pé no Claude Code, depois de todas as remoções, é quase todo de quatro naturezas: segurança, permissões, análise estática e um conjunto de código de interface. Olhe a lista de novo e procure o padrão. É tudo aquilo que o modelo não tem como inferir sozinho.

O que olhar: a proporção entre as duas faixas de cima — a hachurada, enorme, é o que saiu; a acesa, pequena, é o que ficou. E principalmente os quatro blocos de baixo: nenhum deles ensina o modelo a raciocinar. Todos dizem fatos do mundo que ele não tem como descobrir por dedução: o que é proibido, quem autoriza, com que ferramenta conferir, como a saída deve aparecer para a pessoa. Use esses quatro como filtro quando bater a dúvida "posso cortar isso?".

🎯 O que nunca se corta por reflexo

Traduzindo o critério da Anthropic para a sua config, esta é a lista do que fica mesmo numa auditoria agressiva — porque nenhum modelo, por mais capaz que seja, adivinha isso:

•Identidade do projeto — o que ele é, para quem, com que restrição.
•Caminhos e fontes de verdade — onde mora o dado certo quando existem dois candidatos.
•Branding — nome, tom, cor, o que nunca se escreve.
•Segurança e compliance — o que é proibido tocar, quem autoriza, o que não pode sair do ambiente.
•Contratos de interface — formatos que outra pessoa ou outro sistema consome.
•Integrações — qual serviço, qual conta, qual chave, qual endpoint.
•Convenções internas — combinados do seu time que não estão em lugar nenhum do código.

💡 O teste de uma pergunta

Diante de qualquer linha, pergunte: "um profissional competente, sem nenhum contexto do meu mundo, descobriria isso sozinho olhando o repositório?" Se a resposta é sim, a linha é candidata a corte. Se é não, ela é contexto — e contexto fica. O curso inteiro é uma forma disciplinada de fazer essa pergunta sem se enganar.

Calcule o custo de uma linha zumbi

A objeção mais comum é: "tudo bem, ficou obsoleta, mas ela não atrapalha — deixa lá". Atrapalha. Uma linha zumbi cobra em quatro moedas diferentes ao mesmo tempo, e três delas você não vê no extrato. Antes: um esclarecimento de vocabulário. Contexto é tudo que o modelo lê antes de responder — sua config, os arquivos abertos, o histórico da conversa. É finito e é disputado.

✗ O que a linha zumbi cobra

✗Contexto queimado em TODA execução — inclusive nas ~90% de tarefas que não têm nada a ver com a regra.
✗Autonomia reduzida — a regra fecha rotas melhores que o modelo teria escolhido.
✗Comportamento inconsistente — quando a regra briga com outra, o modelo escolhe uma e você não sabe qual.
✗Medo institucional — ninguém apaga porque ninguém lembra mais o que ela segurava.

✓ O que você ganha ao cortar

✓Contexto livre para o que importa naquela tarefa específica.
✓Rota melhor permitida — o modelo resolve do jeito dele, que às vezes é melhor que o seu.
✓Comportamento previsível — menos regras, menos chance de contradição silenciosa.
✓Config auditável — você sabe dizer por que cada linha restante sobreviveu.

Repare no detalhe que faz o custo ser composto e não linear: a regra é lida em 100% das execuções, mas serve em uma fração pequena delas. Uma instrução sobre deploy é relida quando você pede para renomear uma variável, quando pede um resumo de log, quando pede um teste. Ela nunca fica quieta — só fica invisível.

💡 A conta grosseira que basta

Um CLAUDE.md de 300 linhas entra inteiro em cada pedido que você faz. Se 200 dessas linhas só se aplicam a situações raras, você está pagando 200 linhas de imposto em cada "renomeia essa função". Não é o custo em dinheiro que dói — é o custo em atenção: o que importa naquela tarefa disputa espaço com o que não importa.

⚠️ Atenção: a regra que ninguém ousa apagar

Este é o estágio terminal do sedimento. A linha está lá há tanto tempo que virou superstição: "acho que isso evita aquele bug estranho de antigamente". Ninguém sabe se o bug ainda existe, ninguém sabe se a linha resolve, e ninguém quer ser o responsável por descobrir. Toda regra que você não consegue explicar já falhou no teste. Não apague por impulso — marque para testar. É exatamente para isso que existe o método do módulo 1.2.

Reconheça os 6 sintomas de sedimento

Sedimento é o que se deposita no fundo com o tempo, sem que ninguém tenha decidido colocar ali. Configuração acumula sedimento do mesmo jeito. Você não vai auditar nada ainda — isso é a Trilha 2. Aqui o objetivo é só treinar o olho: seis formas visíveis do problema, e o que cada uma costuma ser por baixo.

Sintoma visível	O que costuma ser
`CLAUDE.md` de 300 linhas com exceções datadas	Correções escritas para modelos que já saíram de cena. Cada "exceto quando..." marca uma falha que talvez não exista mais.
A mesma regra no `CLAUDE.md` e em 3 skills	Redundância. Parece segurança ("reforçar não faz mal"), mas as cópias divergem com o tempo e a redundância vira conflito.
Skill de 400 linhas ensinando "como pensar"	Raciocínio genérico que o modelo já faz. Skill deve carregar procedimento do seu mundo, não método de pensamento.
Passo a passo rígido de 12 etapas	Microgerenciamento. Funcionava com modelos antigos; hoje trava a rota melhor que o modelo teria encontrado.
Duas regras que se contradizem	Conflito. O modelo escolhe uma — e você não sabe qual, nem quando. É a origem do "às vezes ele faz certo, às vezes não".
Nada dizendo como conferir que ficou certo	O buraco mais caro de todos. Não é excesso, é ausência: sem critério de verificação, o modelo não tem como saber que terminou bem.

🎯 O sexto sintoma é diferente dos outros

Os cinco primeiros são coisa demais. O sexto é coisa de menos — e é o que mais custa. Boris chamou a verificação de a coisa mais importante que as pessoas não acertam: um prompt curto com uma forma real de o modelo conferir o próprio trabalho vence um prompt gigante sem nenhuma. Guarde isso: auditoria de ablação não é só cortar. Em várias configs, o resultado da auditoria é cortar 40% e acrescentar uma linha de verificação onde não havia nenhuma.

Conceitos-chave

Sedimento

Acumulou sem decisão

Redundância

Vira conflito com o tempo

Microgerenciamento

Receita no lugar de critério

Verificação ausente

O buraco mais caro

Ache 3 instruções legado na sua config

Agora sai da teoria. O exercício deste módulo é um inventário, não uma faxina: você não vai apagar nada hoje. Vai só olhar de frente o tamanho do que carrega e escolher três linhas suspeitas. Comece medindo — a maioria das pessoas se surpreende com o número.

🧪 Inventário da própria config

Objetivo: saber quantas linhas você carrega em toda execução e localizar os trechos com cara de exceção datada. Copie e rode no seu terminal. Nada aqui modifica arquivo — é tudo leitura.

# 1) Quantas linhas você carrega em TODA execução?
wc -l ~/.claude/CLAUDE.md

# 2) E no projeto em que você está agora?
wc -l ./CLAUDE.md 2>/dev/null || echo "sem CLAUDE.md de projeto"

# 3) Quantas skills existem, e qual o peso de cada uma?
ls ~/.claude/skills/
wc -l ~/.claude/skills/*/SKILL.md | sort -n | tail -20

# 4) Onde estão as exceções datadas (o cheiro mais forte de legado)?
grep -n -iE "20(2[0-9])|antes|antigamente|corrigido em|mudou em|nao esqueca|sempre lembre|nunca esqueca" ~/.claude/CLAUDE.md

# 5) Onde está o microgerenciamento (listas numeradas longas)?
grep -n -E "^[[:space:]]*[0-9]+\." ~/.claude/CLAUDE.md | head -30

# 6) Qual regra aparece no CLAUDE.md E nas skills (redundância)?
grep -rn -iE "sempre|nunca|obrigatorio|obrigatório" ~/.claude/CLAUDE.md ~/.claude/skills/ | wc -l

Como verificar que deu certo: você deve terminar com três números na mão — linhas do CLAUDE.md global, quantidade de skills e quantidade de ocorrências de "sempre/nunca" — e com pelo menos uma linha numerada saindo do comando 4. Se o comando 4 não retornar nada, rode-o também nas suas skills: sedimento gosta de se esconder ali.

Se você usa outro caminho: troque ~/.claude/ por <a pasta de config que você usa>. O que importa não é o caminho — é ver o número.

Com a lista na tela, escolha três trechos suspeitos e preencha a tabela abaixo (num arquivo, num caderno, tanto faz). A coluna que dói é a terceira: se você não consegue datar a linha nem aproximadamente, isso já é informação — significa que ela sobreviveu sem nunca ter sido reavaliada.

Trecho (arquivo:linha)	O que ela tenta evitar	Quando nasceu	Ainda precisa?
`CLAUDE.md:42`	"Leia o arquivo antes de editar" — evitava edição às cegas	Época em que o modelo editava sem ler	Provavelmente não — testar
…	…	…	…
…	…	…	…
…	…	…	…

✅ Critério de saída deste módulo

Você consegue apontar três linhas concretas da sua configuração e dizer, para cada uma: o que ela tenta evitar e de que época ela é. Só isso. Nenhuma linha apagada, nenhuma decisão tomada — a decisão vem depois do teste, no módulo 1.2.

Checagem rápida (não bloqueia nada): a Anthropic cortou mais de 80% do prompt de sistema no Opus 5. Qual foi o critério do que ficou?

📌 Resumo do Módulo

✓

O harness nunca está pronto — prompt de sistema, ferramentas e prompts de ferramenta mudam a cada modelo; partes inteiras são apagadas.

✓

Instrução é conserto datado — nasce da fraqueza de um modelo; quando a fraqueza some, ela vira peso morto e continua sendo relida.

✓

Sobrevive o que não se infere — segurança, permissões, análise estática, interface. Na sua config: identidade, caminhos, fontes de verdade, branding, compliance, contratos, integrações e convenções.

✓

O custo é composto — contexto queimado em 100% das execuções, autonomia reduzida, comportamento inconsistente e a regra que ninguém ousa apagar.

✓

Seis sintomas de sedimento — exceções datadas, regra em 3 lugares, skill que ensina a pensar, receita de 12 etapas, contradições e verificação ausente.

✓

Diagnóstico antes de corte — este módulo só inventaria. Nenhuma linha foi apagada, e é assim que tem que ser.

Próximo Módulo:

1.2 — O método de ablação: apagar tudo, usar em trabalho real, e devolver uma instrução só depois de ver a mesma falha repetir.

← Voltar para Trilha Próximo Módulo →