📊 El plan de ablación A/B/C

Ablación es un término tomado de la investigación: quitar una parte del sistema para medir cuánto contribuía realmente. Aquí, la parte que se quita son las instrucciones de tu configuración. Y medir exige que al menos dos configuraciones ejecuten lo mismo; en la práctica, tres: A, B e C.

A es tu configuración actual, intacta: la línea de base (el punto de comparación honesto, lo que tienes hoy y no puedes empeorar sin darte cuenta). B es la versión simplificada, con cerca de un 50 % menos de instrucciones: mantuviste lo que parecía esencial y recortaste el resto. C es la versión mínima: contexto esencial + objetivo + guardrails + criterios de calidad + verificación. Nada más.

Qué observar: las columnas se estrechan de izquierda a derecha, pero las franjas cian atraviesan las tres con la misma longitud. Ese detalle es lo que hace que la prueba sirva: solo cambia una variable (la config). Si también cambias la tarea, el modelo o el prompt de entrada, el resultado ya no dice nada sobre el recorte.

Una tarea real es una tarea que ya hiciste o que vas a hacer de todos modos esta semana: publicar una entrada, refactorizar un módulo, generar un informe, crear una página. Una tarea hipotética —«pídele al modelo que escriba una función de Fibonacci»— no prueba nada de tu configuración, porque esta no se diseñó para Fibonacci.

Cinco tareas es el mínimo para que el resultado no sea cuestión de suerte; diez es el límite práctico antes de que la ronda se convierta en un proyecto en sí misma. El conjunto debe estar representativo: si el 70% de tu trabajo es escribir contenido y el 30% es modificar código, la matriz debe reflejar más o menos esa proporción.

"Quedó mejor" no es una medida. Nueve dimensiones cubren lo que importa, y cada una tiene una forma sencilla de puntuar: escala de 1 a 5 cuando el juicio es inevitable, recuento objetivo siempre que se pueda. El recuento siempre es preferible: «3 correcciones» no admite discusión; «calidad 4» sí.

Hay tres de estas dimensiones que suelen ignorarse y que precisamente revelan una config recargada: autonomía (cuánto avanza el modelo por su cuenta antes de detenerse a preguntar), adhesión (si respetó las reglas que tú quiso mantener — no todas las reglas que existían) y la capacidad de verificar su propio trabajo.

Tres cosas se mantienen fijas en cada ronda: misma tarea, mismo modelo, mismo prompt de entrada. Solo cambia la configuración. Comparar el A de ayer, con el modelo anterior, con el C de hoy en una tarea parecida no es ablación: es una anécdota.

Y hay una regla que distingue a quien mide de quien se convence: escribe antes de mirar la respuesta qué sería «bueno». Si defines el criterio después de leer la salida, tu cerebro ajusta el criterio a la salida: te parecerá excelente lo que salió y no notarás que cambiaste la vara. Anota la vara primero, y luego ejecuta.

# 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)

La lectura de la tabla tiene tres desenlaces, y solo tres. Dónde C empató con A, las instrucciones que estaban en A y desaparecieron en C eran peso muerto: quedan fuera, definitivamente. Donde C empeoró una sola vez, eso no cuenta: una ronda mala es ruido, y devolver una instrucción por eso es como reescribir toda la configuración cada vez que el modelo bosteza.

Dónde C empeoró repetidamente, entonces sí se aplica la regla de reintroducción. Y hay un cuarto caso que aparece con frecuencia y sorprende: B supera a A y a C. Cuando esto ocurre, encontraste el punto óptimo; normalmente es ahí donde se queda la configuración.

Qué observar: hay cuatro resultados posibles y solo una devuelve instrucciones para la configuración. Observa que «C empeoró» por sí solo no es una salida: debe pasar por el segundo rombo. Este diagrama existe para que resistas el impulso de reescribir la configuración ante la primera frustración.

Uno eval es un caso de prueba para el modelo: una tarea concreta con un criterio de acierto que puedes verificar. Cada fallo que apareció en tu matriz ya es un eval listo; basta con escribir «en esta tarea, con este criterio, el modelo fallaba aquí» y guardarlo.

Las evals también envejecen: suelen sobrevivir de 1 a 3 generaciones de modelos. Cuando una eval siempre pasa, en todas las versiones, se saturó — ya no distingue nada y solo cuesta tiempo de ejecución. Retíralo y crea otros nuevos donde hayas visto tropezar al modelo actual.

Cómo leer esta tabla de ejemplo: es ilustrativa: los números son inventados. Lo que importa es la columna «Lectura»: cuatro tareas, cuatro desenlaces distintos. Una matriz real rara vez apunta a un único veredicto, y precisamente por eso vale más que tu intuición.

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.