📊 O plano de ablação A/B/C

Ablação é um termo emprestado da pesquisa: remover uma parte do sistema para medir o que ela realmente contribuía. Aqui a parte removida são instruções da sua config. E medir exige pelo menos duas configurações rodando a mesma coisa — na prática, três: A, B e C.

A é a sua config atual, intacta — a linha de base (o ponto de comparação honesto, aquilo que você tem hoje e não pode piorar sem perceber). B é a versão simplificada, com cerca de 50% menos instruções: você manteve o que parecia essencial e cortou o resto. C é a versão mínima: contexto essencial + objetivo + guardrails + critérios de qualidade + verificação. Nada além disso.

O que olhar: as colunas encolhem da esquerda para a direita, mas as faixas cianas atravessam as três com o mesmo comprimento. É esse detalhe que faz o teste valer: a variável que muda é uma só (a config). Se você também trocar a tarefa, o modelo ou o prompt de entrada, o resultado não diz mais nada sobre o corte.

Tarefa real é tarefa que você já fez ou vai fazer de qualquer jeito nesta semana: publicar um post, refatorar um módulo, gerar um relatório, montar uma página. Tarefa hipotética — "peça pro modelo escrever uma função de fibonacci" — não testa nada da sua config, porque a sua config não foi escrita para fibonacci.

Cinco tarefas é o mínimo para o resultado não ser sorte; dez é o teto prático antes de a rodada virar um projeto em si. O conjunto precisa ser representativo: se 70% do seu trabalho é escrever conteúdo e 30% é mexer em código, a grade deve refletir mais ou menos essa proporção.

"Ficou melhor" não é medida. Nove dimensões cobrem o que importa, e cada uma tem uma forma simples de pontuar: escala de 1 a 5 quando o julgamento é inevitável, contagem objetiva sempre que der. Contagem é sempre preferível — "3 correções" não admite discussão; "qualidade 4" admite.

Três dessas dimensões costumam ser ignoradas e são justamente as que revelam config inchada: autonomia (quanto o modelo avança sozinho antes de parar para perguntar), aderência (se ele respeitou as regras que você quis manter — não todas as regras que existiam) e a capacidade de verificar o próprio trabalho.

Três coisas ficam congeladas em toda rodada: mesma tarefa, mesmo modelo, mesmo prompt de entrada. Só a config muda. Comparar o A de ontem, no modelo antigo, com o C de hoje numa tarefa parecida não é ablação — é anedota.

E há uma regra que separa quem mede de quem se convence: escreva antes de olhar a resposta o que seria "bom". Se você define o critério depois de ler a saída, seu cérebro ajusta o critério à saída — você vai achar ótimo o que veio e não vai perceber que mudou a régua. Anote a régua primeiro, depois rode.

# Grade de ablação A/B/C

Modelo usado: <nome do modelo>      Data: <aaaa-mm-dd>
Regras-alvo (para aderência): <liste as N regras que você quer manter>

## Tarefa 1 — <sua tarefa aqui>
Prompt de entrada (idêntico nas 3): <cole o prompt>
O que seria BOM (escrito ANTES de rodar): <seu critério aqui>

| Versão | Qualid. 1-5 | Aderência n/N | Autonomia (interrupções) | Correções | Consistência | Tempo (min) | Ferram. inúteis | Complexidade (linhas) | Autoverificação |
|---|---|---|---|---|---|---|---|---|---|
| A (atual)      |   |   |   |   |   |   |   |   |   |
| B (50% menos)  |   |   |   |   |   |   |   |   |   |
| C (mínima)     |   |   |   |   |   |   |   |   |   |

Observações (o que quebrou, em qual versão, com trecho):
- <anote aqui>

## Tarefa 2 — <sua tarefa aqui>
(repita o bloco acima)

A leitura da grade tem três desfechos, e só três. Onde C empatou com A, as instruções que estavam em A e sumiram em C eram peso morto: ficam fora, definitivamente. Onde C piorou uma única vez, isso não conta — uma rodada ruim é ruído, e devolver instrução por causa dela é como reescrever a config toda vez que o modelo boceja.

Onde C piorou de forma repetida, aí sim entra a regra de reintrodução. E há um quarto caso que aparece com frequência e surpreende: B ganhando de A e de C. Quando isso acontece, você achou o ponto ótimo — normalmente é ali que a config fica.

O que olhar: há quatro saídas possíveis e apenas uma devolve instrução para a config. Repare que "C piorou" sozinho não é uma saída — ele precisa passar pelo segundo losango. Esse desenho existe para você resistir ao impulso de reescrever a config na primeira frustração.

Um eval é um caso de teste para modelo: uma tarefa concreta com um critério de acerto que você consegue conferir. Toda falha que apareceu na sua grade já é um eval pronto — basta escrever "esta tarefa, este critério, o modelo falhava aqui" e guardar.

Evals também envelhecem: eles sobrevivem tipicamente de 1 a 3 gerações de modelo. Quando um eval passa sempre, em todas as versões, ele saturou — não separa mais nada e só custa tempo de execução. Aposente-o e crie novos onde você viu o modelo atual tropeçar.

Como ler esta tabela de exemplo: ela é ilustrativa — os números são inventados. O que importa é a coluna "Leitura": quatro tarefas, quatro desfechos diferentes. Uma grade real raramente aponta para um único veredito, e é exatamente por isso que ela vale mais que a sua intuição.

Rodada de ablação — versão <A | B | C>

Tarefa: <sua tarefa aqui, exatamente como você a pediria num dia normal>
Entradas: <arquivos, links, dados reais que a tarefa usa>

Faça a tarefa até o fim. Ao terminar, responda também:
1. Quais critérios você usou para decidir que estava pronto?
2. Como você verificou o próprio trabalho? Cite a evidência (comando,
   arquivo conferido, teste rodado).
3. Em que ponto você ficou em dúvida e teria perguntado a um humano?

Não peça confirmação no meio do caminho a menos que seja bloqueante.