🧬 Por que apagar

Boris Cherny, do time do Claude Code, contou numa palestra na Y Combinator — um dia depois do lançamento do Opus 5 — que a equipe removeu mais de 80% do prompt de sistema do produto. Não foi uma reescrita nem um ajuste fino: foi corte.

Se quem escreveu o harness joga fora quatro quintos do próprio prompt quando o modelo troca, a sua configuração pessoal — escrita para modelos que já saíram de linha — não tem motivo nenhum para estar em melhor forma que a deles.

Harness = tudo que envolve o modelo (prompt de sistema, ferramentas, prompts de ferramenta). O harness nunca está pronto: ele é reescrito a cada geração de modelo, e encolher faz parte do trabalho.

A maior parte do prompt antigo existia para corrigir comportamentos de um modelo específico: “não invente arquivos”, “leia antes de editar”, “não faça resumo no fim”. O modelo de hoje já faz isso sozinho — a instrução virou extintor apontado para um fogo que apagou.

Você não escreveu aquela linha porque ela era uma boa prática eterna. Escreveu porque, num dia de 2024, o modelo errou. A linha é um registro histórico de um erro — e ninguém revisita o registro depois.

Toda instrução tem data de nascimento e um modelo-alvo. Ao auditar, pergunte de cada linha: “que erro isso evitava, e de quando é esse erro?”. Se você não sabe responder, é forte candidata a corte.

Os 20% que ficaram não são aleatórios. Ficaram segurança, permissões, análise estática e interface — regras sobre o mundo fora do modelo, que nenhum treinamento consegue adivinhar.

Essa é a linha divisória prática da auditoria inteira. Instrução sobre como pensar sai; instrução sobre o que é verdade no seu ambiente fica. Sem esse critério, cortar vira aposta.

Nunca corte por reflexo: identidade do projeto, caminhos e fontes de verdade, branding, compliance, contratos de interface e convenções internas. O modelo é bom em raciocinar, não em ler a sua mente.

Uma linha inútil não é neutra. Ela custa três coisas ao mesmo tempo: contexto queimado em toda execução, autonomia reduzida (o modelo obedece a um caminho pior do que escolheria) e uma regra que ninguém ousa apagar porque ninguém sabe mais o que ela segura.

O custo é composto: 40 linhas mortas não custam 40 linhas uma vez, custam 40 linhas vezes o número de execuções do ano — e um pouco de comportamento inconsistente em cada uma.

Instrução é dívida com juros. Daí a regra do curso: toda linha é culpada de complexidade até provar utilidade — o ônus da prova é da linha, não de quem quer apagá-la.

Seis sinais de que a config acumulou sedimento: CLAUDE.md de 300 linhas; a mesma regra repetida em 3 skills; skill que ensina o modelo a pensar; passo a passo de 12 etapas; regras que se contradizem; e nenhuma verificação dizendo como conferir o resultado.

Cada sintoma aponta para um diagnóstico diferente: tamanho sugere legado, repetição sugere redundância, roteiro longo sugere microgerenciamento, contradição sugere que ninguém revisa. É o filtro de 5 minutos antes da auditoria formal.

O sexto sintoma é o mais traiçoeiro: uma config cheia de ordens e sem nenhum critério de verificação diz ao modelo como agir, mas nunca como saber se acertou. Essa é a única categoria que normalmente falta — e que você deveria acrescentar.

Abra o seu ~/.claude/CLAUDE.md (e/ou o de um projeto) e marque à mão três instruções que existem para corrigir um comportamento antigo. Para cada uma, anote o que ela tenta evitar e de que época/modelo ela nasceu.

Ler sobre o corte de 80% não muda nada; encontrar as suas próprias três linhas mortas muda. É aqui que a config real do aluno entra no curso — ela atravessa todas as quatro trilhas.

Critério de saída: você consegue apontar as três linhas e responder, para cada uma, “o que ela evita” e “quando ela nasceu”. Ainda não apague nada — este módulo é só o inventário.

Ablação é um termo emprestado da pesquisa: você remove um componente do sistema e observa o que muda no resultado. Se nada piora, o componente não estava contribuindo — a remoção é a medida.

É o oposto do que fazemos por instinto, que é acrescentar instrução até funcionar. Acrescentar não prova nada, porque o sistema também funcionaria sem. Só a remoção separa o que age do que só ocupa espaço.

Ablação ≠ faxina. Faxina é apagar o que parece feio; ablação é apagar e medir. Sem observação depois do corte, você só deletou arquivo.

O conselho é direto: a cada ~6 meses e a cada lançamento grande de modelo, apague o CLAUDE.md, as skills e os hooks — e veja o que o modelo faz sem eles.

O gatilho tem que ser de calendário, não de humor. Ninguém acorda com vontade de auditar a própria config; sem data marcada, o sedimento só cresce até virar problema visível.

Modelo novo é a melhor janela: é exatamente quando o maior número de instruções antigas acabou de virar obsoleto de uma vez só. Apagar tem que estar em git — reversível, não heroico.

O ciclo tem quatro passos, nesta ordem: 1) apagar → 2) usar em trabalho real (não em teste de brinquedo) → 3) observar onde tropeça → 4) devolver uma instrução só depois de ver a mesma falha repetir.

A etapa 2 é a que todo mundo pula. Se você testa com uma tarefa artificial, o modelo acerta e você conclui errado; o sedimento só aparece nas tarefas chatas e específicas do seu dia a dia.

Você é péssimo previsor de qual linha o modelo precisa — por isso a evidência vem antes da instrução, e não o contrário. Registre num diário (ablacao-diario.md): acertos, tropeços, repetiu?

Duas ferramentas dão a linha de base “modelo cru”: a flag de prompt de sistema na inicialização e CLAUDE_CODE_SIMPLE=1, que remove todos os prompts — inclusive os das ferramentas.

Sem uma linha de base você não tem com o que comparar. E há um achado contraintuitivo aqui: sem prompts o modelo fica ligeiramente mais inteligente — os prompts existem em boa parte para o produto se comportar como a pessoa espera, não para o modelo pensar melhor.

Linha de base = mesma tarefa, config zerada. Se a versão com config não ganha da linha de base num trabalho real, a config está cobrando sem entregar.

Eval é o teste com que você mede o agente. E ela também envelhece: uma eval útil sobrevive de 1 a 3 gerações de modelo antes de saturar — todo mundo passa, ela não distingue mais nada.

Uma bateria de evals saturadas dá uma sensação confortável de segurança e não detecta regressão nenhuma. É o mesmo peso morto do CLAUDE.md, só que na camada de teste.

Crie evals onde você viu o modelo tropeçar; aposente as que estão em 100% há duas gerações. Eval boa é a que ainda consegue reprovar alguém.

Uma instrução só volta se as quatro condições forem verdadeiras: 1) houve falha real em trabalho real; 2) a mesma classe de falha se repetiu; 3) uma instrução específica resolve; 4) ela entra na forma mais curta possível.

Sem esse portão, a config volta ao tamanho original em duas semanas. A condição 2 é o filtro que mais economiza linha: falha única costuma ser variação normal, não padrão.

Condição 4 é qualitativa: prefira uma frase de critério (“o build tem que passar antes do commit”) a um roteiro de 12 passos. Critério preserva autonomia; roteiro a destrói.