📊 Provar e manter

A é a sua configuração atual, intocada. B mantém aproximadamente metade das instruções — as que a auditoria classificou como mais defensáveis. C é a versão mínima: contexto do projeto, objetivo, guardrails inegociáveis, critérios de qualidade e verificação. Nada além disso.

Duas versões só respondem "melhorou ou piorou?". Três respondem "onde está o joelho da curva?" — se B e C empatam com A, o corte pode ir mais fundo do que você imaginava; se C cai e B não, o limite está entre elas.

Versione as três em git antes de começar. C não é a config vazia: é a config que só tem o que nenhum modelo consegue adivinhar sozinho — o seu contexto e as suas regras.

O conjunto de tarefas do teste sai do seu histórico de trabalho de verdade: a correção de bug que você fez semana passada, o refactor chato, a página que precisou de três idas e vindas. Cinco é o mínimo para não decidir por acaso; dez já cansa e você para de anotar direito.

Tarefa de brinquedo ("escreva uma função que soma dois números") passa em qualquer configuração. Ela não distingue A de C — só produz a falsa segurança de que "testei". O teste só tem valor se as tarefas puderem falhar.

Cubra os tipos de trabalho que você realmente faz, não só o mais comum. Inclua ao menos uma tarefa em que a config atual já deu problema — é ali que a diferença aparece.

Nove colunas na sua tabela: qualidade do resultado, aderência às suas regras, autonomia (quantas vezes precisou perguntar), correções humanas necessárias, consistência entre execuções, tempo até a entrega, uso de ferramentas, complexidade da solução proposta e autoverificação (ele conferiu o próprio trabalho?).

Uma nota única esconde trocas. É comum a versão C entregar a mesma qualidade em menos tempo e com uma solução mais simples — e isso só fica visível se tempo e complexidade forem colunas separadas.

Correções humanas é a dimensão mais honesta: conta o trabalho que sobrou pra você. Complexidade da solução costuma piorar com excesso de instrução, não melhorar.

Mesma tarefa, mesmo modelo, mesmo estado do repositório nas três versões. E, antes de rodar qualquer coisa, escreva o que seria uma resposta "boa" para aquela tarefa. Só depois você lê as saídas.

Se você define o critério depois de ver a resposta, o critério se molda à resposta — você aprova o que apareceu em vez de avaliar o que precisava aparecer. É o viés que arruína a maioria dos testes caseiros de prompt.

Trocar de modelo no meio invalida a comparação inteira. Se puder, leia as saídas sem saber qual versão as gerou — e anote na hora, não de memória no fim do dia.

Empate entre A e C significa que tudo que existe em A e não existe em C é peso morto: custa contexto e atenção sem comprar nada. Piora isolada em uma tarefa é ruído. Piora repetida, na mesma dimensão, em tarefas diferentes, aciona a regra de reintrodução.

A regra de reintrodução evita os dois erros opostos: devolver tudo ao primeiro susto, ou insistir na versão mínima ignorando uma falha real. Devolva uma instrução por vez, a mais específica possível, citando a falha que a justifica.

Instrução devolvida sem falha registrada é fé, não evidência. E a versão que volta não é a antiga: é a antiga menos tudo que o teste já provou dispensável.

Toda falha que você observou no teste vira um caso guardado: a tarefa, o que deu errado e o que seria o certo. Esse conjunto é a sua bateria de evals — e ela cresce a partir do trabalho real, não de um catálogo genérico.

É assim que o teste deixa de ser um evento único. Na próxima troca de modelo, você não recomeça do zero: roda a bateria e vê, em minutos, o que o modelo novo já resolve sozinho.

Eval saturada — que passa sempre, em qualquer versão — se aposenta. Ela virou peso morto do mesmo jeito que a instrução que a originou; manter tudo pra sempre é recriar o problema em outro arquivo.

Auditar a configuração; cortar o que o diagnóstico marcou como removível; usar a versão cortada em trabalho real por alguns dias; anotar as falhas que aparecerem; repetir. Cinco passos, sem etapa extra.

O passo que quase todo mundo pula é o terceiro. Cortar e reler o arquivo não prova nada — só o uso em trabalho real revela se faltou alguma coisa, e revela em dias, não em minutos.

O ciclo é curto de propósito. Uma volta pequena e frequente descobre problemas quando eles ainda são baratos de desfazer.

Três sinais objetivos: saiu um modelo novo; o seu CLAUDE.md passou de aproximadamente 150 linhas; duas ou mais skills começaram a brigar pelo mesmo gatilho de ativação.

Sem gatilho explícito, a re-auditoria acontece quando a irritação acumula — ou seja, tarde demais. Modelo novo é o gatilho mais forte: metade das suas instruções foi escrita para consertar fraquezas que ele talvez não tenha mais.

150 linhas não é lei, é alarme. Skills competindo pelo mesmo gatilho não é problema de descrição: é sinal de que você tem skills demais para o mesmo trabalho.

Tratar a própria configuração como ciência empírica: você não sabe o que o modelo precisa, você testa. Observa o que acontece. E reteste o que falhou antes, porque a falha de ontem pode ter sido resolvida pelo modelo de hoje.

Instruções nascem quase sempre de uma frustração pontual, viram permanentes e nunca mais são checadas. A maior parte do peso morto de um CLAUDE.md foi útil — dois modelos atrás.

Escrever mais instrução é o reflexo fácil e quase sempre errado. A pergunta certa é "isso ainda é necessário?", e ela só se responde rodando de novo.

Há três terrenos em que a versão mínima ainda costuma sofrer: sistemas profundos e muito acoplados, arquiteturas distribuídas com estado espalhado, e verificação visual fina (um pixel fora do lugar, um contraste ruim).

Saber onde o método aperta evita duas bobagens: cortar contexto que é genuinamente necessário nesses casos, e concluir que "ablação não funciona" por ter testado justamente no terreno mais difícil.

Nesses casos o que fica não é microgerenciamento: é contexto factual que o modelo não tem como descobrir sozinho — e critério de verificação, não passo a passo.

Routine é uma tarefa agendada cujo conteúdo é um único prompt. Na Anthropic, times rodam de 20 a 30 delas por dia — triagem de issues, checagem de builds, resumos — e cada uma cabe em uma frase.

É a prova prática do curso inteiro: trabalho de verdade, recorrente, rodando com uma frase de instrução. Se o padrão profissional é esse, o seu CLAUDE.md de 400 linhas precisa justificar cada uma delas.

Boa candidata a routine: tarefa repetitiva, com critério de sucesso claro e baixo custo de erro. A própria re-auditoria periódica pode virar uma.

Dez linhas suas respondendo: quando eu re-audito, o que nunca corto, como decido reintroduzir, qual é o meu conjunto de tarefas de teste, e quando uma eval se aposenta.

Sem política escrita, cada re-auditoria recomeça a discussão do zero e as decisões variam com o humor do dia. Com ela, o critério é anterior ao caso concreto — que é exatamente o que impede o viés de aprovar o que já está lá.

Guarde-a onde você vai reler — um arquivo próprio, um card, o topo do checklist de release. Nunca como mais um parágrafo dentro do CLAUDE.md: seria virar exatamente o tipo de sedimento que o curso ensinou a cortar.