📊 Demostrar y mantener

A es tu configuración actual, intacta. B mantiene aproximadamente la mitad de las instrucciones: las que la auditoría clasificó como más defendibles. C es la versión mínima: contexto del proyecto, objetivo, guardrails innegociables, criterios de calidad y verificación. Nada más.

Dos versiones solo responden «¿mejoró o empeoró?». Tres responden «¿dónde está la rodilla de la curva?» —si B y C empatan con A, el recorte puede llegar más lejos de lo que imaginabas; si C baja y B no, el límite está entre ambas.

Versiona las tres en git antes de empezar. C no es la config vacía: es la config que solo tiene lo que ningún modelo puede adivinar por sí mismo — tu contexto y tus reglas.

El conjunto de tareas de prueba sale de tu historial de trabajo real: la corrección de errores que hiciste la semana pasada, el refactor tedioso, la página que necesitó tres idas y vueltas. Cinco es el mínimo para no decidir al azar; diez ya cansa y dejas de tomar notas correctamente.

Una tarea de juguete («escribe una función que sume dos números») funciona con cualquier configuración. No distingue entre A y C: solo genera la falsa seguridad de que «lo probé». La prueba solo sirve si las tareas pueden fallar.

Cubre los tipos de trabajo que realmente haces, no solo el más común. Incluye al menos una tarea en la que la configuración actual ya haya dado problemas: ahí es donde se nota la diferencia.

Nueve columnas en tu tabla: calidad del resultado, cumplimiento de tus reglas, autonomía (cuántas veces tuvo que preguntar), correcciones humanas necesarias, consistencia entre ejecuciones, tiempo hasta la entrega, uso de herramientas, complejidad de la solución propuesta y autoverificación (¿revisó su propio trabajo?).

Una sola nota oculta los intercambios. Es común que la versión C entregue la misma calidad en menos tiempo y con una solución más simple; eso solo se hace visible si el tiempo y la complejidad están en columnas separadas.

Las correcciones humanas son la dimensión más honesta: muestran el trabajo que te quedó. La complejidad de la solución suele empeorar con instrucciones excesivas, no mejorar.

La misma tarea, el mismo modelo y el mismo estado del repositorio en las tres versiones. Y, antes de ejecutar cualquier cosa, escribe qué sería una respuesta «buena» para esa tarea. Solo después lees los resultados.

Si defines el criterio después de ver la respuesta, el criterio se adapta a ella: apruebas lo que apareció en vez de evaluar lo que debía aparecer. Es el sesgo que arruina la mayoría de las pruebas caseras de prompts.

Cambiar de modelo a mitad de la ronda invalida toda la comparación. Si puedes, lee los resultados sin saber qué versión los generó —y anótalo en el momento, no de memoria al final del día.

Un empate entre A y C significa que todo lo que existe en A y no en C es peso muerto: consume contexto y atención sin aportar nada. Un empeoramiento aislado en una tarea es ruido. Un empeoramiento repetido, en la misma dimensión, en distintas tareas, activa la regla de reintroducción.

La regla de reintroducción evita los dos errores opuestos: devolver todo ante el primer susto o insistir en la versión mínima ignorando un fallo real. Devuelve una instrucción a la vez, lo más específica posible, citando el fallo que la justifica.

Una instrucción devuelta sin un fallo registrado es fe, no evidencia. Y la versión que vuelve no es la antigua: es la antigua menos todo lo que las pruebas ya demostraron que se puede quitar.

Cada fallo que observaste en la prueba se convierte en un caso guardado: la tarea, lo que salió mal y lo que sería correcto. Ese conjunto es tu batería de evals, y crece a partir del trabajo real, no de un catálogo genérico.

Así es como la prueba deja de ser un evento único. La próxima vez que cambie el modelo, no empiezas de cero: ejecutas la batería y ves, en minutos, qué puede resolver por sí solo el nuevo modelo.

Una eval saturada —que siempre pasa, en cualquier versión— se jubila. Se convirtió en peso muerto, igual que la instrucción que la originó; mantenerlo todo para siempre es recrear el problema en otro archivo.

Auditar la configuración; recortar lo que el diagnóstico marcó como eliminable; usar la versión recortada en trabajo real durante unos días; anotar los fallos que aparezcan; repetir. Cinco pasos, sin pasos adicionales.

El paso que casi todo el mundo se salta es el tercero. Cortar y volver a leer el archivo no demuestra nada: solo el uso en trabajo real revela si faltó algo, y lo revela en días, no en minutos.

El ciclo es breve a propósito. Una vuelta corta y frecuente detecta problemas cuando todavía es barato revertirlos.

Tres señales objetivas: salió un modelo nuevo; tu CLAUDE.md superó aproximadamente las 150 líneas; dos o más skills empezaron a competir por el mismo disparador de activación.

Sin un disparador explícito, la nueva auditoría ocurre cuando la irritación se acumula; es decir, demasiado tarde. Un modelo nuevo es el disparador más fuerte: la mitad de tus instrucciones se escribió para corregir debilidades que quizá ya no tenga.

150 líneas no es una ley, es una alarma. Que varias skills compitan por el mismo disparador no es un problema de descripción: es señal de que tienes demasiadas skills para el mismo trabajo.

Tratar la configuración como ciencia empírica: no sabes qué necesita el modelo, así que haces pruebas. Observas lo que ocurre. Y vuelves a probar lo que falló antes, porque el fallo de ayer puede haberse resuelto con el modelo de hoy.

Las instrucciones casi siempre nacen de una frustración puntual, se vuelven permanentes y nunca más se revisan. La mayor parte del peso muerto de un CLAUDE.md fue útil — hace dos modelos.

Escribir más instrucciones es el reflejo fácil y casi siempre equivocado. La pregunta correcta es «¿esto sigue siendo necesario?», y solo se responde volviendo a ejecutar.

Hay tres terrenos en los que la versión mínima todavía suele tener dificultades: sistemas profundos y muy acoplados, arquitecturas distribuidas con el estado disperso y verificación visual minuciosa (un píxel fuera de lugar, un contraste deficiente).

Saber dónde el método se tensa evita dos tonterías: recortar contexto que es realmente necesario en estos casos y concluir que "la ablación no funciona" por haberla probado justo en el terreno más difícil.

En estos casos, lo que queda no es microgestión: es contexto factual que el modelo no puede descubrir por sí solo, y criterios de verificación, no un paso a paso.

Routine es una tarea programada cuyo contenido es un único prompt. En Anthropic, los equipos ejecutan entre 20 y 30 al día —clasificación de issues, comprobación de builds, resúmenes— y cada una cabe en una frase.

Es la prueba práctica de todo el curso: trabajo real y recurrente que se ejecuta con una frase de instrucción. Si ese es el estándar profesional, el tuyo CLAUDE.md de 400 líneas necesita justificar cada una de ellas.

Buena candidata a routine: tarea repetitiva, con un criterio de éxito claro y un bajo costo de error. La propia reauditoría periódica puede convertirse en una.

Diez líneas tuyas que respondan: cuándo vuelvo a auditar, qué nunca elimino, cómo decido reintroducir algo, cuál es mi conjunto de tareas de prueba y cuándo se retira una eval.

Sin una política escrita, cada nueva auditoría vuelve a empezar la discusión desde cero y las decisiones varían según el humor del día. Con ella, el criterio es anterior al caso concreto, que es justamente lo que impide el sesgo de aprobar lo que ya está ahí.

Guárdalo donde lo vayas a releer: un archivo propio, una tarjeta, la parte superior de la lista de verificación de lanzamiento. Nunca como un párrafo más dentro del CLAUDE.md: sería convertirse exactamente en el tipo de sedimento que el curso enseñó a eliminar.