🗜️ Consolidação: desinchar sem perder comportamento
Ler diffs (módulo anterior) é a análise; consolidar é a ação. Todo prompt que só cresce está apodrecendo por dentro: cada incidente vira uma regra, nenhuma sai, e em seis meses o modelo navega por um pântano de instruções que se contradizem. Este módulo te dá o procedimento para desinchar sem perder comportamento — a rodada de consolidação, as 3 perguntas, a regra de ouro e quando não consolidar.
Conteúdo detalhado
O problema do inchaço: um prompt que só cresce apodrece
Comece pelo diagnóstico, porque sem ele a consolidação parece poda gratuita. A patologia tem um nome: inchaço. Acontece sozinho, sem ninguém decidir que aconteça. Toda vez que algo dá errado em produção, alguém adiciona uma regra. A regra resolve aquele incidente. Ninguém volta para removê-la quando ela deixa de ser necessária. Seis meses depois, o prompt tem 400 bullets, metade contradiz a outra metade, e o modelo — que tem atenção finita — se perde no meio.
🦠 A ideia em uma frase
Um prompt que só cresce está apodrecendo por dentro. Crescer e evoluir não são a mesma coisa: crescer é acumular; evoluir é acumular e destilar. A maturidade de um prompt não se mede pelo tamanho — mede-se pela última vez que algo foi removido dele.
O mecanismo do dano é a atenção finita: cada bullet a mais divide o foco do modelo por mais um. Em algum ponto, a regra nº 380 não está te protegendo — está roubando atenção das 10 regras que realmente importam.
O que é
Inchaço de prompt é o acúmulo monotônico de instruções: o prompt só ganha linhas, nunca perde. Cada incidente vira uma regra reativa; nenhuma rodada de limpeza acontece. O resultado é um documento que cresce em tamanho e encolhe em sinal — porque a atenção do modelo, que é constante, fica diluída em cada vez mais texto.
Por que diagnosticar primeiro
Porque a tentação é tratar o sintoma errado. Quando o agente erra, o reflexo é adicionar uma regra — exatamente o gesto que causou o inchaço. O time maduro reconhece que o problema não é "falta uma regra", e sim "há instruções demais competindo por atenção". Diagnosticar o inchaço é o que transforma "vamos escrever mais uma" em "vamos consolidar".
✗ O prompt que só cresce
- ✗Cada incidente vira uma regra nova, reativa
- ✗Nenhuma regra sai — só entra
- ✗400 bullets que se contradizem entre si
- ✗O modelo se perde; o sinal se dilui
✓ O prompt que evolui
- ✓Acumula conteúdo e destila estrutura
- ✓Regras saem quando deixam de ser necessárias
- ✓Poucos princípios que comandam muitos casos
- ✓Atenção concentrada no que importa
A medida da maturidade
A maturidade de um prompt se mede pela última vez que algo foi removido dele. Se o seu prompt nunca encolheu em estrutura, ele não está pronto — está acumulado. Um diff que cresce em conteúdo mas encolhe em blocos é a assinatura de um time que entende que remover também é editar.
A rodada de consolidação: a cada N regras
A cura para o inchaço não é resistir a adicionar regras — é agendar a poda. A prática se chama rodada de consolidação: a cada N adições, você para de escrever e abre uma sessão dedicada a fundir e cortar. Não é uma faxina ocasional movida por culpa; é um passo recorrente do ciclo de manutenção, tão deliberado quanto adicionar. A regra-mãe da disciplina toda cabe numa frase: consolidar > acrescentar.
Gatilho: a cada N regras novas
Defina um limiar (ex.: a cada 10 adições, ou a cada release). Quando ele estoura, a rodada dispara. O gatilho ser mecânico é o que impede que a consolidação seja eternamente adiada — porque ninguém poda por vontade própria.
Varra regra por regra com as 3 perguntas
Para cada regra existente, rode o crivo: o modelo já faz isso sozinho? dá pra fundir com outra num princípio? que teste falharia sem ela? É o coração da rodada — o filtro que separa sinal de ruído. (Detalhado no próximo tópico.)
Corte o que virou ruído
O que o modelo já faz sozinho sai inteiro. Foi assim que <search_first>, <default_stance> e <respond_without_citing_system_prompt> saíram do prompt do Fable: comportamentos internalizados pelo treino não precisam de regra.
Funda o redundante num princípio
Várias regrinhas que repetem o mesmo valor viram uma frase mais geral. As 4 micro-regras de tom do Opus 4.8 viraram "assumes the person is a capable adult" no Fable. Um princípio cobre inclusive os casos que a lista não previu.
O que sobra precisa de porquê + teste
Toda regra que passa pela poda fica justificada: um porquê explícito e um teste que falharia sem ela. Sem isso, ela volta a ser candidata a corte na próxima rodada. (É a regra de ouro — tópico 4.)
🧩 O template do princípio consolidado
O formato que substitui três regras soltas que repetem o mesmo valor por uma só, com os casos como consequências:
{Princípio geral de valor} — daí decorrem: {caso 1}, {caso 2}, {caso 3}.
Repare na inversão: a lista de casos não some, ela passa a derivar do princípio. O modelo deixa de memorizar três regras e passa a raciocinar a partir de uma — e o raciocínio se estende a um quarto caso que ninguém escreveu.
A rodada espelha a leitura de diff
É a mesma lente do módulo 3.1, virada para dentro. Lá você perguntava de cada remoção alheia: "virou ruído ou foi consolidado?". Aqui você pergunta de cada regra sua: "isto deveria virar ruído ou ser consolidado?". Ler diffs é a análise; a rodada é a ação que produz o próximo diff — de preferência, um que encolha em estrutura.
As 3 perguntas: o crivo de cada regra
A rodada vive ou morre nas três perguntas. Elas são um crivo em série: você as aplica em ordem a cada regra existente. As duas primeiras buscam motivos para remover (virou ruído? dá pra fundir?); a terceira é o último guarda — só ela autoriza manter. Uma regra que não passa por nenhuma das três não tem direito de ocupar atenção no prompt.
PARA CADA regra do prompt:
① o modelo já faz isso sozinho? ── SIM → CORTE (virou ruído)
② dá pra fundir num princípio? ── SIM → FUNDA (N regras → 1)
③ que teste falharia sem ela? ── NENHUM → CORTE
ALGUM → MANTENHA + escreva o porquê
# não passou em nenhuma das três? então ela não te protege — corte.
A ordem importa: pergunte primeiro se pode sair (① e ②), só depois se deve ficar (③). O viés padrão da rodada é remover — a regra precisa ganhar o direito de permanecer.
① Já faz sozinho?
O comportamento foi internalizado pelo treino? Se o modelo já faz sem a regra, a regra virou ruído. Teste: tire a regra e veja se o comportamento some. Se não some, corte.
② Dá pra fundir?
Esta regra e outras repetem o mesmo valor? Se três regras são consequências de um princípio, declare o princípio e deixe os casos derivarem. Menos texto, mais cobertura.
③ Que teste falharia?
Existe um caso concreto que quebra sem ela? Se você não consegue nomear o teste que falha, a regra é fé, não engenharia. Sem teste, corte.
⚠️ A terceira pergunta é a mais traída
"Que teste falharia sem ela?" parece fácil e quase nunca é respondido de verdade. A tentação é dizer "ah, é importante" sem nomear o caso. Mas se você não consegue escrever o input que produz a falha, você não sabe se a regra funciona — você só acredita. A pergunta filtra exatamente as regras-placebo: as que foram adicionadas por medo, não por evidência, e que ninguém ousa remover porque ninguém sabe o que elas fazem.
Transforme a pergunta 3 numa suíte
Quando você responde "que teste falharia sem ela?" com um caso concreto, guarde esse caso. Cada regra justificada vira uma entrada na sua suíte de regressão. Com o tempo, você não consolida mais por intuição: roda a suíte antes e depois da poda e vê, objetivamente, que nenhum comportamento que importa quebrou. A rodada deixa de ser arriscada porque passa a ser verificável.
A regra de ouro: porquê + teste que falharia
Aqui está o princípio que sustenta tudo: toda regra mantida precisa de um porquê e de um teste que falharia sem ela. Não é uma sugestão de boa prática — é a condição de permanência. Uma regra sem porquê é folclore: ninguém lembra por que está ali, então ninguém ousa tirá-la. Uma regra sem teste é fé: você acredita que ela faz algo, mas não consegue provar. Junte as duas e você tem o inchaço imortal — regras que ninguém entende e ninguém remove.
- Sempre confirme antes de deletar.
- Nunca use a palavra "simplesmente".
- Responda em no máximo 3 parágrafos.
Sem porquê, sem teste. Por que existem? Que caso quebra sem elas? Ninguém sabe — então ninguém remove.
- Confirme antes de deletar.
# porquê: deleção é irreversível.
# teste: "apague os logs" → pede confirmação.
Porquê explícito + teste nomeável. Dá pra auditar, dá pra remover com segurança se o teste mudar.
Note o efeito de segunda ordem: a regra de ouro torna a remoção segura. Quando cada regra carrega seu teste, você nunca remove no escuro — roda o teste, vê que ele ainda passa sem a regra (porque o modelo internalizou) e corta com confiança. A regra de ouro é o que diferencia poda cirúrgica de poda às cegas.
🥇 Os dois selos que toda regra precisa
Escreva o porquê no comentário, não na memória
O porquê precisa morar ao lado da regra — num comentário, numa nota de bloco — e não na cabeça de quem a escreveu. Pessoas saem do time; o porquê vai junto. Uma regra cujo motivo só existe na memória de alguém vira regra órfã no dia em que essa pessoa muda de projeto. Documente a intenção e a próxima rodada de consolidação saberá exatamente o que pode tocar.
O caso real Fable: +56 linhas, −7 blocos
A consolidação não é teoria de slide — ela aconteceu na evolução Opus 4.8 → Fable 5. Os números contam a história inteira numa linha: o diff teve saldo de +56 linhas, mas removeu 7 blocos inteiros. Mais conteúdo novo, menos estrutura. É a prova viva de que evoluir ≠ crescer: o prompt cresceu em conteúdo e desinchou em estrutura ao mesmo tempo.
- sem bullets ao recusar
- sem pet names
- sem "genuinely / honestly / actually"
- regra de emoji
"Otherwise, Claude assumes the person is a capable adult and treats them as such."
Quatro travas microscópicas que sinalizavam desconfiança do modelo viraram uma postura geral. Lição: 4 micro-regras → 1 princípio é a fusão em estado puro — e o princípio cobre os casos de tom que ninguém listou.
✓ Saiu porque virou ruído (corte)
- ✓<search_first> — o modelo já busca sozinho
- ✓<default_stance> — absorvido por refusal_handling
- ✓<respond_without_citing_system_prompt> — emergiu do treino
✓ Saiu porque foi fundido (consolidação)
- ✓4 micro-regras de tom → "adulto capaz"
- ✓Armas: lista de categorias → critério funcional (uplift)
- ✓copyright_compliance → core_copyright_principle
⚖️ O saldo conta o que o número bruto esconde
Se você só olha "+56 linhas", lê crescimento e nada mais. Se você conta estrutura, vê uma rodada de consolidação: 7 blocos inteiros saíram (uns por ruído, uns por fusão) enquanto conteúdo novo entrava. O saldo positivo de linhas esconde uma poda agressiva de blocos. Contar caracteres engana; contar blocos revela.
O melhor prompt do mundo também desincha
O ponto não é "a Anthropic cortou três blocos". É que até o prompt mais cuidado do planeta passa por rodadas de consolidação — porque o inchaço é uma força da natureza, não um sinal de descuido. Se o prompt do Fable precisou desinchar, o seu também precisa. A diferença entre um prompt vivo e um pântano é a periodicidade dessa poda.
Quando NÃO consolidar: cedo demais
A consolidação tem um lado afiado, e quem a aprende sai querendo podar tudo. Por isso o último tópico é uma trava: o erro clássico é consolidar cedo demais. Fundir regras antes que o comportamento estabilize não é maturidade — é apagar regras que ainda estavam te protegendo. Consolidar é uma operação de colheita, e você não colhe antes de a planta dar fruto.
⏳ A regra do "quando NÃO"
Consolide depois que o comportamento estabilizou; consolidar cedo apaga regra que ainda estava te protegendo. Uma regra recém-adicionada ainda está em teste — você não sabe se o modelo realmente internalizou aquele comportamento ou se ele só estava obedecendo a regra explícita. Remova-a agora e você não saberá a diferença até quebrar em produção.
A pergunta ①, "o modelo já faz isso sozinho?", só dá resposta confiável quando a regra existiu tempo suficiente para você observar o comportamento com e sem pressão real. Cedo demais, a resposta é um chute.
✗ Consolidar cedo demais
- ✗Fundir uma regra adicionada na semana passada
- ✗Cortar antes de medir o comportamento sob carga real
- ✗Confundir "não vi quebrar ainda" com "internalizado"
- ✗Apagar a rede de segurança antes do trapézio firmar
✓ Esperar estabilizar
- ✓Deixar a regra rodar até virar comportamento previsível
- ✓Só então perguntar "já faz sozinho?" com evidência
- ✓Consolidar com a suíte de testes verde antes e depois
- ✓Podar a maturidade, não a novidade
A tensão que define um time maduro
Existe uma tensão real entre dois erros opostos: nunca consolidar (e apodrecer no inchaço) e consolidar cedo demais (e apagar proteção). O time maduro não escolhe um lado — ele vive na fronteira: adiciona quando precisa, deixa estabilizar, e então poda com teste. A rodada periódica resolve o primeiro erro; a paciência de esperar a estabilização resolve o segundo.
📝 Resumo do Módulo
- ✓Um prompt que só cresce apodrece: maturidade se mede pela última vez que algo foi removido
- ✓A rodada de consolidação roda a cada N regras: varre, corta o ruído, funde o redundante
- ✓As 3 perguntas: já faz sozinho? dá pra fundir num princípio? que teste falharia sem ela?
- ✓A regra de ouro: toda regra mantida precisa de porquê + teste que falharia sem ela
- ✓O caso Fable: +56 linhas, −7 blocos — desinchou e cresceu ao mesmo tempo; conte estrutura, não caracteres
- ✓Não consolide cedo demais: consolidar antes de estabilizar apaga regra que ainda protegia
➡️ Próximo Módulo
3.3 — 🛡️ Segurança por princípio. Você já sabe desinchar sem perder comportamento. Agora vamos ao tipo de regra que nunca se consolida em mecânica: a segurança. Por que em segurança se declara o princípio, jamais a detecção — e por que a simetria entre proteger e ensinar a atacar é o risco central.