🔄 Rode o ciclo de 5 passos
Tudo o que você aprendeu nas três primeiras trilhas cabe num ciclo de cinco passos que se repete. Ele não termina: cada volta devolve uma configuração menor do que a anterior, e cada modelo novo reabre o ciclo. O ponto do módulo não é fazer a auditoria uma vez — é montar a engrenagem que faz você fazer de novo daqui a seis meses, sem depender de vontade nem de crise.
O que olhar: a linha ciano pontilhada é a única aresta que fecha o anel — sem ela, você fez uma faxina, não instalou um ciclo. E repare no destaque do nó 4: é ali que a maioria falha, porque devolver instrução na primeira falha parece cuidado e é, na prática, como a configuração volta a inchar. A disciplina inteira do curso mora nessa caixa.
Rodar /audit-ablacao no escopo escolhido
Global, um projeto, ou um conjunto de skills. A skill só diagnostica: ela lê, classifica e propõe — não edita, não move, não apaga. O produto é o relatório de 10 seções.
Cortar o Top 10 por impacto ÷ risco — em sessão separada
A skill não aplica nada. Aplicar é decisão sua, num pedido novo, com a config sob git para poder voltar. Primeiro redundâncias e conflitos (risco quase zero), depois legado, depois microgerenciamento.
Usar em trabalho real por alguns dias
Não em teste hipotético. Teste inventado exercita o que você imagina que importa; trabalho real exercita o que de fato importa — e é lá que a falha aparece.
Anotar as falhas e devolver só quando repetir
Este é o passo que quase todo mundo pula. Anote a falha; só devolva uma instrução quando a mesma classe de falha se repetir — e na forma mais curta possível. Uma falha isolada é ruído; falha repetida é sinal.
Repetir a cada ~6 meses ou a cada lançamento grande de modelo
O que sobreviveu à última volta pode não sobreviver à próxima: a instrução que corrigia uma fraqueza real vira peso morto quando aquela fraqueza deixa de existir.
💡 Por que o passo 4 é o mais pulado
Porque doer uma vez já parece justificativa suficiente. O modelo erra numa tarefa, você escreve a regra na hora — e acabou de trocar um erro pontual por um custo permanente: aquela linha vai ser lida em 100% das execuções futuras, inclusive nas que não têm nada a ver. Anotar e esperar a repetição custa três dias de paciência e economiza anos de contexto queimado.
Conceitos-chave
Volta, não evento único
Auditar ≠ aplicar
Teste hipotético não vale
Único gatilho de reintrodução
🚨 Reconheça os gatilhos de re-auditoria
O calendário de seis meses é o piso, não o teto. Existem sinais que dizem "audite agora, não espere a data" — e quase todos são observáveis sem esforço: um número que passou de um limite, um comportamento que ficou imprevisível, ou uma frase que alguém disse na sua frente. A tabela abaixo liga cada gatilho ao escopo que ele pede: nem todo sinal manda auditar tudo.
| Gatilho observado | Escopo a auditar | Por quê |
|---|---|---|
| Modelo novo lançado | Tudo: global + projetos + skills | Toda instrução escrita para corrigir a fraqueza do modelo anterior virou candidata a peso morto. |
CLAUDE.md passou de ~150 linhas | Só aquele arquivo | Acima disso, quase sempre há procedimento disfarçado de regra global — material de MOVE para skill. |
| 3+ skills brigando pelo mesmo gatilho | O conjunto de skills, não o CLAUDE.md | Disparo virou loteria. Solução costuma ser MERGE, escopo mais estreito ou invocação direta. |
| "Ninguém sabe mais o que essa regra segura" | O bloco que contém a regra | Regra que ninguém ousa apagar é regra sem dono. Vai para TEST, nunca para KEEP por medo. |
| Você explicou a mesma regra duas vezes a outra pessoa | A regra e suas vizinhas | Se precisa de explicação humana para ser entendida, está mal escrita — ou não deveria existir. |
📌 O gatilho mais subestimado
O último da tabela. Quando você explica a mesma regra pela segunda vez a um colega, ela falhou como texto — e se falha com um humano que pode perguntar de volta, falha ainda mais com o modelo, que não pergunta. Esse gatilho não aparece em métrica nenhuma; ele aparece na sua boca. Preste atenção nele.
✓ Re-auditar agora
- ✓Saiu modelo novo e sua config é a mesma de dois modelos atrás
- ✓Você acrescentou regras nos últimos meses e nunca removeu nenhuma
- ✓Duas regras da sua config se contradizem e você não sabe qual vence
✗ Não é gatilho de re-auditoria
- ✗Uma tarefa deu errado hoje — isso pede diagnóstico, não faxina geral
- ✗Você leu um post dizendo que "CLAUDE.md grande é ruim" — mede a sua, não a média
- ✗Vontade de mexer numa sexta-feira sem trabalho real para testar depois
🧪 Desaprenda o overengineering
Boris volta a um mesmo tema o tempo todo: trabalhar com modelo virou ciência empírica, não teórica. Você não deduz o que o modelo precisa a partir de princípios — você testa, observa onde ele tem dificuldade e ajusta com base no que viu. Isso exige largar duas bagagens: o que você aprendeu sobre o comportamento de modelos anteriores, e as suposições da teoria da computação sobre o que "deveria" ser difícil.
A terceira exigência é a mais desconfortável: continuar disposto a retestar ideias que falharam no passado, porque o motivo da falha pode ter desaparecido. Boris descreve overengineering como um modo de falha recorrente — e desaprender esse hábito como uma jornada real para builders experientes. Quanto mais anos de engenharia você tem, mais forte o reflexo de especificar tudo, e mais trabalho dá desmontá-lo.
🆕 Duas palavras antes de seguir
- Overengineering: engenharia em excesso — resolver com muita estrutura, muita regra e muito passo a passo um problema que pedia menos. Na config de agente, aparece como instrução que roteiriza cada etapa em vez de dar objetivo e critério.
- Eval: abreviação de evaluation — um caso de teste do seu agente: uma tarefa com um resultado esperado, que você reroda a cada versão de modelo para ver se melhorou ou piorou. Evals também envelhecem: aposente as que o modelo já satura sempre.
✗ Mentalidade antiga (teórica)
- ✗"Isso é difícil para modelos" — dedução a partir do que você viu há dois modelos atrás
- ✗"Pela teoria, esse problema é intratável, então preciso decompor à mão"
- ✗"Já tentei isso uma vez e não funcionou" — arquivado para sempre
- ✗Escrever a regra antes de ver a falha, por precaução
- ✗Medir a qualidade do prompt pelo tamanho e pelo detalhe
✓ Mentalidade empírica
- ✓"Vamos ver" — roda a tarefa e observa onde o modelo de fato tropeça
- ✓Dá a tarefa inteira primeiro; decompõe só se a observação exigir
- ✓Reteste programado dos fracassos antigos a cada versão nova
- ✓Escreve a regra depois da segunda ocorrência da mesma falha
- ✓Mede a qualidade do prompt pelo resultado verificado
🎯 O detalhe que faz diferença: reteste o que falhou
A lista de "coisas que não dão certo com IA" que você carrega na cabeça foi montada com modelos que não existem mais. Cada item dela é uma hipótese vencida, não um fato. Escolha um item dessa lista a cada modelo novo e reteste — é a forma mais barata de descobrir capacidade nova, e a única que não depende de alguém te avisar.
🧭 Calibre onde ainda não está resolvido
Boris já disse publicamente que programação está resolvida — e fez a ressalva que costuma sumir na citação: resolvida para o tipo de programação que ele faz, não para todo mundo. A ressalva importa para você por um motivo prático: nas áreas onde o modelo ainda tem dificuldade, o remédio não é escrever instrução mais longa. É apertar a verificação.
| Área ainda difícil | Como isso aparece na prática | Verificação que compensa |
|---|---|---|
| Bases de código de sistemas muito profundas | Mudança plausível que viola uma invariante enterrada em outra camada. | Teste de integração que exercita a camada de baixo, não só a alterada. |
| Sistemas distribuídos | Funciona na máquina, falha sob concorrência, ordem de mensagens ou partição de rede. | Rodar sob carga e sob falha injetada; conferir estado final, não só o retorno. |
| Verificação visual detalhada | Algo deslocado por um pixel passa como "igual". O Opus 5 foi um grande avanço em visão e uso de computador, mas ainda não é perfeito. | Comparação de imagem automatizada com limiar, screenshot de referência, e olho humano no final. |
⚠️ Atenção: a armadilha desta seção
Ler "aqui ainda é difícil" e responder com mais três parágrafos de instrução no CLAUDE.md é exatamente o reflexo que o curso inteiro tentou desmontar. Instrução longa não conserta um limite de capacidade; ela só queima contexto enquanto o limite continua lá. Nessas áreas: verificação mais forte, escopo menor, revisão humana no ponto certo. Nunca prosa mais longa.
🔭 Calibrar não é desistir
Esta lista é um retrato de hoje, e a regra do tópico 3 vale aqui também: reteste. A verificação visual, que era um beco sem saída, virou uma área que avançou muito de um modelo para o outro. Trate cada item como "ainda não" com data de revisão marcada — não como "nunca".
⚙️ Automatize com routines de uma frase (bônus)
Este tópico é bônus: resolve um problema diferente do resto do curso. Loops e routines não tratam de uma tarefa grande dividida em partes — tratam de uma tarefa repetitiva executada num cronograma. Um loop é essencialmente um cron job rodando Claude localmente. Uma routine é a mesma coisa na nuvem, para você poder fechar o notebook.
🆕 Quatro palavras antes de seguir
- Cron job: tarefa agendada que o sistema dispara sozinho num horário fixo — "todo dia às 3h", "de hora em hora". Vem do
cron, o agendador clássico do Unix. - Routine: o mesmo agendamento, mas rodando na nuvem — não depende do seu computador estar ligado.
- PR (pull request): proposta de mudança de código aberta num repositório, com o diff visível, para alguém revisar e aprovar antes de entrar. É como a routine entrega trabalho sem aplicar nada sozinha.
- Scaffolding: andaime — código temporário que existe só para sustentar algo durante uma fase (o liga-desliga de um experimento, por exemplo) e vira lixo quando a fase acaba.
Duas propriedades importam: cada execução não compartilha contexto com a anterior, embora possa compartilhar memória; e o agendamento pode ser a cada cinco minutos, a cada hora ou diariamente. A Anthropic roda hoje de 20 a 30 routines diárias sobre os próprios produtos — e o detalhe que muda tudo: cada uma é um único prompt, frequentemente de uma frase. O modelo descobre sozinho os detalhes da implementação.
O que olhar: repare no tamanho das caixas do meio — é o prompt inteiro de cada routine, uma frase. Ninguém escreveu "use análise estática e dinâmica" na routine de código morto; o modelo escolheu esses métodos sozinho. E olhe a etiqueta da direita: a entrega é um PR, não uma alteração aplicada. É a mesma disciplina da skill de auditoria — propor e deixar a decisão com um humano.
As cinco routines que a Anthropic roda
- Limpar código morto. Roda diariamente, usa análise estática e dinâmica e abre um PR removendo o que encontra. Ninguém pediu explicitamente esses métodos — o modelo descobriu sozinho.
- Publicar experimentos concluídos. Acha experimentos já liberados para 100% dos usuários, remove o scaffolding do experimento e publica o resultado.
- Escrever testes ausentes em áreas da base de código com baixa cobertura.
- Apagar testes inúteis — incluindo testes de baixo valor adicionados por modelos antigos ou por pessoas ao longo do tempo.
- Polícia de abstrações. Encontra abstrações quase duplicadas que divergiram com o tempo e as unifica de volta numa só.
O padrão que vale copiar: as routines de maior alavancagem são as tarefas de manutenção óbvias, repetitivas e fáceis de deixar para depois. Auditar a própria config é exatamente esse tipo de tarefa.
🧪 Copie e rode: sua re-auditoria como lembrete periódico
Objetivo: transformar o passo 5 do ciclo em algo que acontece sem depender da sua memória. Duas formas — a de uma linha, que funciona em qualquer máquina, e a versão routine, para quem já usa agendamento na nuvem.
# --- Opção A: cron job local (roda no seu computador) --- # abre o editor de agendamentos: crontab -e # cola esta linha: dia 1, a cada 6 meses (janeiro e julho), 9h 0 9 1 1,7 * echo "ABLACAO: rodar /audit-ablacao na config global" >> ~/ablacao-lembretes.txt # --- Opção B: routine (roda na nuvem, notebook fechado) --- # o prompt inteiro da routine é UMA frase: "Rode uma auditoria de ablação em ~/.claude/CLAUDE.md e ~/.claude/skills/, e me entregue o Top 10 por impacto ÷ risco. Não altere nenhum arquivo." # --- Opção C: sem nada instalado --- # evento recorrente semestral no calendário, com este título: "Ablação: rodar /audit-ablacao + abrir ablacao-diario.md"
Como verificar:
- 1. Rode
crontab -le confirme que a linha aparece na listagem. - 2. Troque temporariamente o agendamento para daqui a 2 minutos e confira que
~/ablacao-lembretes.txtganhou uma linha. Depois volte para o semestral. - 3. Se usou a opção B, confirme que a frase da routine contém a proibição explícita de alterar arquivos — auditoria que já sai mexendo é auditoria em que você não confia.
Agora troque pelo seu: substitua os caminhos por
<a config que você realmente audita> e o mês por
<seus dois meses do ano>. Se você tem mais de um projeto ativo, faça uma linha por escopo — auditoria de tudo junto vira relatório que ninguém lê.
📎 Por que "uma frase" e não um manual
A routine é o teste final da tese do curso: se um prompt de uma frase, sem passo a passo, produz PRs úteis diariamente numa base de código do tamanho da do Claude Code, o seu procedimento de 12 etapas não estava garantindo qualidade — estava só te fazendo sentir no controle.
📝 Escreva sua política de ablação
Exercício final do módulo e do curso: escrever sua política de ablação pessoal em ≤10 linhas. Quatro coisas precisam estar nela: quando re-auditar, o que você nunca corta, a regra de reintrodução, e onde ficam os diários e evals. Menos que isso não é política; mais que isso não é lido.
E ela vai onde será relida — como skill ou nota separada, com data marcada,
não como mais um parágrafo no CLAUDE.md. Se você colar a política lá, acabou de
criar a linha zumbi número 1 da próxima auditoria: um texto sobre ablação sendo carregado em 100% das execuções,
inclusive nas que não têm nada a ver com auditar configuração.
⚠️ A ironia que fecha o curso
Terminar oito módulos sobre não inflar o CLAUDE.md e comemorar acrescentando dez linhas nele seria um final perfeito — de comédia. Política é procedimento com gatilho conhecido, então é skill (ou nota com lembrete). Você já sabe a regra: o que é verdade sempre fica no CLAUDE.md; o que é verdade só quando a tarefa é aquela vira skill.
📋 Copie e preencha: template da política (≤10 linhas)
Objetivo: salvar como ~/.claude/skills/politica-ablacao/SKILL.md (ou como nota fixada, se preferir). Preencha tudo entre < > com o seu caso real.
## Política de ablação — <seu nome> 1. Re-auditar: a cada 6 meses (próxima: <DD/MM/AAAA>) e a cada modelo novo. 2. Gatilho extra: CLAUDE.md > 150 linhas, 3+ skills no mesmo gatilho, regra sem dono. 3. Escopo padrão: <global | projeto X | conjunto de skills Y>. 4. Nunca cortar sem teste: identidade, caminhos/fontes de verdade, segurança, compliance, contratos de interface, integrações, convenções internas. 5. Reintrodução: só após a MESMA falha repetir 2x em trabalho real, e na forma mais curta possível. 6. Aplicar cortes sempre em sessão separada da auditoria, com a config sob git. 7. Diário de falhas: <caminho/ablacao-diario.md>. 8. Evals pessoais: <caminho/evals/> — aposentar as saturadas a cada re-auditoria. 9. Toda remoção aplicada registra: trecho citado + risco + como testar. 10. Toda versão nova precisa ter pelo menos uma verificação objetiva.
Como verificar:
- 1. Não sobrou nenhum
< >no arquivo — se sobrou, a política ainda é template, não é sua. - 2. A linha 1 tem uma data concreta, não "daqui a uns meses".
- 3. O arquivo NÃO está dentro do
CLAUDE.md. Rodegrep -c "Política de ablação" ~/.claude/CLAUDE.md— precisa retornar0. - 4. Os caminhos das linhas 7 e 8 existem de verdade:
ls <caminho>responde sem erro.
🎓 Projeto final do curso
Você entrega quatro itens, todos sobre a sua própria configuração — nada hipotético:
As 10 seções, salvo em .md (módulo 3.1)
Com o diff visível (módulo 3.2)
≥2 tarefas reais × 3 versões (módulo 4.1)
≤10 linhas, fora do CLAUDE.md (este módulo)
Critérios de aprovação
- •Os quatro itens existem.
- •Toda remoção aplicada tem trecho citado + risco + como testar.
- •Toda instrução devolvida tem falha repetida registrada — nada de reintrodução por precaução.
- •A versão final tem pelo menos uma verificação objetiva onde antes não havia nenhuma.
✓ Critério de saída deste módulo
Política escrita, com a data da próxima re-auditoria marcada — e você consegue dizer, olhando para o CLAUDE.md final, por que cada linha restante sobreviveu. Se houver uma linha para a qual a resposta é "sei lá, sempre esteve aí", ela é a primeira da sua próxima auditoria.
Checagem rápida (não bloqueia nada): você terminou a auditoria, cortou o Top 10 e escreveu sua política em 8 linhas. Onde ela deve morar?
🏁 Resumo do Módulo e fim do curso
O curso inteiro, em quatro linhas
- T1Por que apagar — configuração envelhece: cada instrução conserta a fraqueza de um modelo específico e vira peso morto quando aquela fraqueza some.
- T2Como diagnosticar — 10 categorias, 6 decisões, 7 perguntas; e a conversão de microgerenciamento em objetivo + guardrails + critério + verificação.
- T3Auditar de verdade — a skill que lê, classifica e propõe sem tocar em nada; e o Top 10 virando cortes seguros, com skill como unidade de emagrecimento.
- T4Provar e manter — A/B/C em tarefas reais para provar que não piorou, e o ciclo contínuo para o sedimento não voltar.
Os quatro entregáveis do projeto final
10 seções, salvo em .md
CLAUDE.md com diff
≥2 tarefas reais
≤10 linhas, com data
É o fim do curso. Você entrou com uma configuração que crescia sozinha e sai com uma que você sabe defender linha por linha — e, mais importante, com o hábito de revisar essa defesa quando o mundo muda. A parte difícil não foi apagar; foi aguentar a vontade de escrever a regra na primeira falha. Guarde a data da próxima re-auditoria em algum lugar que te cobre. Ela vai chegar antes do que parece.