🧬 Por qué eliminar

Boris Cherny, del equipo de Claude Code, contó en una charla en Y Combinator —un día después del lanzamiento de Opus 5— que el equipo eliminó más del 80% del prompt del sistema del producto. No fue una reescritura ni un ajuste fino: fue un recorte.

Si quien escribió el harness descarta cuatro quintas partes de su propio prompt cuando cambia el modelo, no hay motivo para que tu configuración personal —escrita para modelos que ya quedaron obsoletos— esté en mejor estado que la suya.

Harness = todo lo que rodea al modelo (prompt del sistema, herramientas, prompts de herramientas). El harness nunca está listo: se reescribe con cada generación de modelos, y reducirlo también forma parte del trabajo.

La mayor parte del prompt antiguo existía para corregir comportamientos de un modelo específico: “no inventes archivos”, “lee antes de editar”, “no hagas un resumen al final”. El modelo de hoy ya hace eso por sí solo: la instrucción se convirtió en un extintor apuntando a un fuego que ya se apagó.

No escribiste esa línea porque fuera una buena práctica eterna. La escribiste porque, un día de 2024, el modelo se equivocó. La línea es un registro histórico de un error — y nadie vuelve a revisar el registro después.

Cada instrucción tiene una fecha de origen y un modelo objetivo. Al auditar, pregúntate sobre cada línea: «¿Qué error evitaba y de cuándo es ese error?». Si no sabes responder, es una firme candidata a eliminar.

El 20% que quedó no es aleatorio. Quedó seguridad, permisos, análisis estático e interfaz — reglas sobre el mundo fuera del modelo, que ningún entrenamiento puede adivinar.

Esta es la línea divisoria práctica de toda la auditoría. Las instrucciones sobre cómo pensar termina; instrucción sobre lo que es verdad en tu entorno se queda. Sin este criterio, recortar es una apuesta.

Nunca recortes por reflejo: identidad del proyecto, rutas y fuentes de verdad, branding, cumplimiento, contratos de interfaz y convenciones internas. El modelo es bueno razonando, pero no leyendo tu mente.

Una línea inútil no es neutra. Cuesta tres cosas al mismo tiempo: contexto consumido en cada ejecución, autonomía reducida (el modelo obedece un camino peor que el que elegiría) y una regla que nadie se atreve a borrar porque nadie sabe ya qué protege.

El costo es compuesto: 40 líneas obsoletas no cuestan 40 líneas una sola vez, sino 40 líneas multiplicadas por el número de ejecuciones del año — y un poco de comportamiento inconsistente en cada una.

La instrucción es una deuda con intereses. De ahí la regla del curso: cada línea es culpable de complejidad hasta que demuestre su utilidad — la carga de la prueba recae en la línea, no en quien quiere borrarla.

Seis señales de que la config acumuló sedimento: CLAUDE.md de 300 líneas; la misma regla repetida en 3 skills; habilidad que enseña al modelo a pensar; paso a paso de 12 etapas; reglas que se contradicen; e ninguna verificación diciendo cómo comprobar el resultado.

Cada síntoma apunta a un diagnóstico distinto: el tamaño sugiere legado, la repetición sugiere redundancia, un guion largo sugiere microgestión y las contradicciones sugieren que nadie revisa. Es el filtro de 5 minutos antes de la auditoría formal.

El sexto síntoma es el más engañoso: una configuración llena de órdenes y sin ninguno el criterio de verificación le dice al modelo cómo actuar, pero nunca cómo saber si acertó. Esta es la única categoría que normalmente falta — y que deberías añadir.

Abre tu ~/.claude/CLAUDE.md (y/o el de un proyecto) y marca a mano tres instrucciones que existen para corregir un comportamiento antiguo. Para cada una, anota qué intenta evitar y de qué época/modelo surgió.

Leer sobre el recorte del 80% no cambia nada; encontrar tus propias tres líneas inútiles sí. Aquí es donde la config real del alumno entra en el curso: atraviesa las cuatro rutas.

Criterio de salida: puedes señalar las tres líneas y responder, para cada una, «qué evita» y «cuándo surgió». Aún no borres nada: este módulo es solo el inventario.

Ablación es un término tomado de la investigación: tú elimina un componente del sistema y observa qué cambia en el resultado. Si nada empeora, el componente no estaba contribuyendo: eliminarlo es la medida.

Es lo contrario de lo que hacemos por instinto: agregar instrucciones hasta que funcione. Agregar no demuestra nada, porque el sistema también funcionaría sin ellas. Solo quitarlas permite distinguir lo que actúa de lo que solo ocupa espacio.

Ablación ≠ limpieza. Limpiar es borrar lo que parece feo; la ablación es borrar y medir. Sin observaciones después del recorte, solo eliminaste un archivo.

El consejo es directo: cada ~6 meses y cada gran lanzamiento de modelo, elimina el CLAUDE.md, las skills y los hooks, y mira qué hace el modelo sin ellos.

El desencadenante debe depender del calendario, no del estado de ánimo. Nadie se despierta con ganas de auditar su propia configuración; sin una fecha marcada, el sedimento solo crece hasta convertirse en un problema visible.

Un modelo nuevo es la mejor oportunidad: es justo cuando la mayor cantidad de instrucciones antiguas acaba de quedar obsoleta de una sola vez. Borrar tiene que hacerse en git: reversible, no heroico.

El ciclo tiene cuatro pasos, en este orden: 1) borrar → 2) usar en trabajo real (no en una prueba de juguete) → 3) observa dónde tropieza → 4) devolver una instrucción solo después de ver que el mismo fallo se repite.

La etapa 2 es la que todos se saltan. Si pruebas con una tarea artificial, el modelo acierta y llegas a una conclusión equivocada; el sedimento solo aparece en las tareas tediosas y específicas de tu día a día.

Eres pésimo prediciendo qué línea necesita el modelo; por eso la evidencia va antes de la instrucción, y no al revés. Registra en un diario (ablacao-diario.md): aciertos, tropiezos, ¿se repitió?

Dos herramientas establecen la línea de base del «modelo sin modificar»: la flag de prompt del sistema al iniciar y CLAUDE_CODE_SIMPLE=1, que elimina todos los prompts, incluidos los de las herramientas.

Sin una línea de base no tienes con qué comparar. Y aquí hay un hallazgo contraintuitivo: sin prompts, el modelo se vuelve ligeramente más inteligente — los prompts existen en buena medida para que el producto se comporte como la persona espera, no para que el modelo piense mejor.

Línea de base = misma tarea, config vacía. Si la versión con config no supera la línea de base en un trabajo real, la config está cobrando sin aportar nada.

Eval es la prueba con la que mides al agente. Y también envejece: una eval útil sobrevive de 1 a 3 generaciones de modelo antes de saturarse — todos pasan por eso, ya no distingue nada.

Una batería de evals saturadas da una sensación cómoda de seguridad y no detecta ninguna regresión. Es el mismo peso muerto que CLAUDE.md, pero en la capa de pruebas.

Crea evals donde tú viste que el modelo tropiece; retira las que llevan dos generaciones en 100%. Una buena eval todavía puede reprobar a alguien.

Una instrucción solo vuelve si se cumplen las cuatro condiciones: 1) hubo un fallo real en un trabajo real; 2) se repitió la misma clase de falla; 3) una instrucción específica lo resuelve; 4) entra en la forma más breve posible.

Sin este filtro, la config vuelve a su tamaño original en dos semanas. La condición 2 es el filtro que más líneas ahorra: un fallo aislado suele ser una variación normal, no un patrón.

La condición 4 es cualitativa: prefiere una frase de criterio («el build tiene que pasar antes del commit») a un procedimiento de 12 pasos. El criterio preserva la autonomía; el procedimiento la destruye.