Entiende qué eliminó Anthropic
Boris Cherny creó Claude Code dentro de Anthropic. Un día, durante una charla en la Y Combinator — grabada un día después del lanzamiento de Opus 5 — contó algo que suena extraño para quien cuida con esmero su propia configuración: el harness del Claude Code nunca está listo. Y, con Opus 5, el equipo eliminó más del 80% del prompt del sistema.
🆕 ¿Nuevo aquí? Tres palabras antes de seguir
- Harness: la «carcasa» alrededor del modelo: el programa que decide qué herramientas tiene, cómo las llama y qué lee antes de responder. Claude Code es un harness; su configuración es el harness que tú escribió.
- Prompt de sistema: el texto fijo que el producto envía al modelo antes de tu pregunta, en cada ejecución. Tu
CLAUDE.mdes tu prompt de sistema personal. - Ablación: término de búsqueda: tú elimina una parte para medir su impacto. Es el método que da nombre a este curso.
El motivo es simple e incómodo: cada modelo es diferente. Una instrucción escrita para el modelo de hace tres meses puede no tener ningún efecto en el siguiente. Por eso, con cada lanzamiento, el equipo cambia cuatro cosas.
Reescriben el prompt del sistema
No es un ajuste fino: es una reescritura grande con cada lanzamiento de modelo.
Cambian el conjunto de herramientas
Lo que el modelo puede hacer cambia: se incorporan herramientas y se quitan herramientas.
Reescriben el prompt de cada herramienta
Cada herramienta tiene su propio textito de instrucciones, y envejece igual.
Descontinúan herramientas y eliminan partes del harness
El código completo queda fuera. Nadie trata el harness como un patrimonio: lo trata como un andamio.
💡 La pregunta que abre el curso
Si quien construye el producto reescribe todo con cada modelo, ¿por qué tu configuración —escrita a lo largo de meses, acumulada línea a línea, nunca revisada— seguiría siendo válida? No es que esté equivocada. Es que se escribió para un modelo que ya no existe.
Mira por qué una instrucción es una solución fechada
Boris fue explícito sobre la naturaleza de lo que se eliminó: buena parte del prompt anterior existía solo para corregir comportamientos que el modelo debería saber ejecutar por su cuenta — y no sabía. "Lee siempre el archivo antes de editarlo." "No te detengas a mitad de la tarea." "Comprueba si la prueba pasó." Cada una de estas líneas se escribió porque, un día, algún modelo falló en eso. Opus 5 lo hace por sí solo. Así que esas líneas se convirtieron en peso muerto.
Qué observar: la línea no cambia de forma en ninguno de los tres cuadros: el texto es exactamente el mismo que el día 1. Lo que cambia es el mundo que lo rodea. Fíjate en las etiquetas de abajo: útil → inerte → costo puro. Ningún evento en tu editor marca esta transición; ocurre fuera de él, cuando se lanza un modelo, sin avisarle a nadie. Por eso el peso muerto solo se encuentra cuando lo buscas a propósito.
El salto que provocó el recorte no fue cosmético. Conviene mirar las cifras, porque explican por qué las instrucciones de «no te rindas, continúa» dejaron de tener sentido.
📊 Lo que cambió en Opus 5, según la charla
- 30% en Arc AGI 3. O Arc AGI es una prueba de razonamiento abstracto, diseñada para que sea difícil memorizarla. Los mejores resultados anteriores iban desde un dígito hasta alrededor del 10 %.
- Se ejecuta durante días, semanas o meses. Combinado con el modo automático, el modelo puede mantener una tarea larga sin detenerse a mitad de camino.
- Ya no necesitas scaffolding para continuar. Scaffolding es el andamiaje: esos empujoncitos del tipo «continúa», «no te detengas», «ahora haz la siguiente etapa». El modelo entiende por sí solo que la tarea debe terminar.
✓ Instrucción que todavía corrige algo
- ✓"La base de datos de producción es
db-prod-2; nunca ejecutes una migración en él.» - ✓"El deploy de este proyecto se hace solo con git push: el panel de la nube está prohibido."
- ✓"La fuente de verdad de los precios es
/data/precos.json, no el README."
✗ Reparación que el modelo ya no necesita
- ✗"Lee todo el archivo antes de editar."
- ✗"No inventes nombres de funciones; comprueba si existen."
- ✗"Continúa hasta terminar, no te detengas a la mitad."
Descubre qué sobrevivió al recorte
Reducir el 80 % no es lo mismo que reducirlo todo. Lo que se mantuvo en Claude Code, después de todas las eliminaciones, es casi todo de cuatro tipos: seguridad, permisos, análisis estático y un conjunto de código de interfaz. Vuelve a mirar la lista y busca el patrón. Todo es aquello que el modelo no hay forma de inferirlo por sí solo.
Qué observar: la proporción entre las dos franjas superiores: la rayada, enorme, es lo que salió; la iluminada, pequeña, es lo que quedó. Y, sobre todo, los cuatro bloques de abajo: ninguno le enseña al modelo a razonar. Todos dicen hechos del mundo que no puede descubrir por deducción: qué está prohibido, quién autoriza, con qué herramienta comprobarlo, cómo debe aparecer el resultado para la persona. Usa estos cuatro como filtro cuando surja la duda «¿puedo eliminar esto?».
🎯 Lo que nunca se corta por reflejo
Al traducir el criterio de Anthropic a tu config, esta es la lista de lo que se mantiene incluso en una auditoría agresiva, porque ningún modelo, por capaz que sea, puede adivinarlo:
- •Identidad del proyecto — qué es, para quién y con qué restricción.
- •Rutas y fuentes de verdad — dónde está el dato correcto cuando hay dos candidatos.
- •Branding — nombre, tono, color, lo que nunca se escribe.
- •Seguridad y cumplimiento — qué está prohibido tocar, quién autoriza, qué no puede salir del entorno.
- •Contratos de interfaz — formatos que consume otra persona u otro sistema.
- •Integraciones — qué servicio, qué cuenta, qué clave, qué endpoint.
- •Convenciones internas — acuerdos de tu equipo que no están en ninguna parte del código.
💡 La prueba de una pregunta
Ante cualquier línea, pregunta: "¿un profesional competente, sin ningún contexto de mi mundo, descubriría esto por su cuenta al revisar el repositorio?" Si la respuesta es sí, la línea es candidata a eliminar. Si es no, es contexto, y el contexto se queda. Todo el curso es una forma disciplinada de hacerse esa pregunta sin engañarse.
Calcula el costo de una línea zombi
La objeción más común es: "está bien, quedó obsoleta, pero no molesta; déjala ahí". Sí molesta. Una línea zombi cobra en cuatro monedas distintas al mismo tiempo, y tres de ellas no las ves en el extracto. Antes: una aclaración de vocabulario. Contexto es todo lo que el modelo lee antes de responder: tu configuración, los archivos abiertos y el historial de la conversación. Es finito y está en disputa.
✗ Lo que exige la línea zombi
- ✗Contexto que se consume en TODA ejecución — incluso en ~90% de las tareas que no tienen nada que ver con la regla.
- ✗Autonomía reducida — la regla cierra rutas mejores que el modelo habría elegido.
- ✗Comportamiento inconsistente — cuando una regla entra en conflicto con otra, el modelo elige una y no sabes cuál.
- ✗Temor institucional — nadie la borra porque nadie recuerda ya qué estaba conteniendo.
✓ Lo que ganas al recortar
- ✓Contexto libre para lo que importa en esa tarea específica.
- ✓Mejor ruta permitida — el modelo lo resuelve a su manera, que a veces es mejor que la tuya.
- ✓Comportamiento predecible — menos reglas, menos posibilidades de contradicción silenciosa.
- ✓Configuración auditable — sabes decir por qué sobrevivió cada línea restante.
Fíjate en el detalle que hace que el costo sea compuesto y no lineal: la regla se lee en 100% de las ejecuciones, pero sirve en una pequeña fracción de ellas. Una instrucción sobre deploy se vuelve a leer cuando pides renombrar una variable, cuando pides un resumen del log, cuando pides una prueba. Nunca se queda quieta: solo se vuelve invisible.
💡 La cuenta aproximada que basta
Uno CLAUDE.md de 300 líneas entra completo en cada pedido que haces.
Si 200 de esas líneas solo aplican a situaciones poco frecuentes, estás pagando un impuesto de 200 líneas en cada
«renombra esta función». Lo que duele no es el costo en dinero, sino el costo en atención: lo importante para esa tarea
compite por espacio con lo que no importa.
⚠️ Atención: la regla que nadie se atreve a borrar
Esta es la etapa terminal del sedimento. La línea lleva tanto tiempo ahí que se convirtió en superstición: «creo que esto evita aquel bug extraño de antes». Nadie sabe si el bug todavía existe, nadie sabe si la línea lo resuelve, y nadie quiere ser responsable de averiguarlo. Toda regla que no puedes explicar ya falló la prueba. No lo borres por impulso: márcalo para probarlo. Para eso existe el método del módulo 1.2.
Reconoce los 6 síntomas de sedimentos
El sedimento es lo que se deposita en el fondo con el tiempo, sin que nadie haya decidido ponerlo allí. La configuración acumula sedimento del mismo modo. Todavía no vas a auditar nada; eso corresponde a la Trilha 2. Aquí el objetivo es solo entrenar la mirada: seis formas visibles del problema y lo que suele haber detrás de cada una.
| Síntoma visible | Lo que suele ser |
|---|---|
CLAUDE.md de 300 líneas con excepciones fechadas |
Correcciones escritas para modelos que ya quedaron atrás. Cada «excepto cuando...» marca una falla que quizá ya no exista. |
La misma regla en el CLAUDE.md y en 3 skills |
Redundancia. Parece seguridad ("reforzar no hace daño"), pero las copias divergen con el tiempo y la redundancia se convierte en conflicto. |
| Skill de 400 líneas que enseña «cómo pensar» | Razonamiento genérico que el modelo ya realiza. La skill debe incluir procedimiento de tu mundo, no un método de pensamiento. |
| Paso a paso rígido de 12 etapas | Microgestión. Funcionaba con modelos antiguos; hoy bloquea la ruta mejor que el modelo habría encontrado. |
| Dos reglas que se contradicen | Conflicto. El modelo elige una — y tú no sabes cuál ni cuándo. Es el origen del «a veces lo hace bien, a veces no». |
| Nada que decir cómo comprobar que quedó bien | El vacío más costoso de todos. No es exceso, sino ausencia: sin un criterio de verificación, el modelo no puede saber si terminó bien. |
🎯 El sexto síntoma es diferente de los demás
Los cinco primeros son demasiado. El sexto es muy poco — y es lo que más cuesta. Boris llamó a la verificación lo más importante que la gente no hace bien: un prompt corto con una forma real de que el modelo revise su propio trabajo supera a un prompt enorme sin ninguna. Recuérdalo: una auditoría de ablación no consiste solo en recortar. En muchas configuraciones, el resultado de la auditoría es recortar un 40% y añadir una línea de verificación donde no había ninguna.
Conceptos clave
Se acumuló sin tomar una decisión
Se convierte en un conflicto con el tiempo
Receta en lugar de criterio
El vacío más costoso
Encuentra 3 instrucciones heredadas en tu configuración
Ahora pasemos de la teoría a la práctica. El ejercicio de este módulo es un inventario, no una limpieza: hoy no vas a eliminar nada. Solo vas a mirar de frente el tamaño de lo que cargas y elegir tres líneas sospechosas. Empieza midiendo: la mayoría se sorprende con el número.
🧪 Inventario de la propia config
Objetivo: saber cuántas líneas cargas en cada ejecución y localizar los fragmentos que parecen excepciones fechadas. Copia y ejecútalo en tu terminal. Nada de esto modifica archivos: todo es de solo lectura.
# 1) Quantas linhas você carrega em TODA execução? wc -l ~/.claude/CLAUDE.md # 2) E no projeto em que você está agora? wc -l ./CLAUDE.md 2>/dev/null || echo "sem CLAUDE.md de projeto" # 3) Quantas skills existem, e qual o peso de cada uma? ls ~/.claude/skills/ wc -l ~/.claude/skills/*/SKILL.md | sort -n | tail -20 # 4) Onde estão as exceções datadas (o cheiro mais forte de legado)? grep -n -iE "20(2[0-9])|antes|antigamente|corrigido em|mudou em|nao esqueca|sempre lembre|nunca esqueca" ~/.claude/CLAUDE.md # 5) Onde está o microgerenciamento (listas numeradas longas)? grep -n -E "^[[:space:]]*[0-9]+\." ~/.claude/CLAUDE.md | head -30 # 6) Qual regra aparece no CLAUDE.md E nas skills (redundância)? grep -rn -iE "sempre|nunca|obrigatorio|obrigatório" ~/.claude/CLAUDE.md ~/.claude/skills/ | wc -l
Cómo verificar que funcionó: debes terminar con
tres números a mano: líneas del CLAUDE.md global, cantidad de skills y cantidad de
apariciones de "siempre/nunca" — y con al menos una línea numerada como resultado del comando 4. Si el comando 4 no devuelve nada,
ejecútalo también en tus skills: al sedimento le gusta esconderse ahí.
Si usas otro camino: cambia
~/.claude/ por <a pasta de config que você usa>.
Lo que importa no es el camino: es ver el número.
Con la lista en pantalla, elige tres fragmentos sospechosos y completa la tabla de abajo (en un archivo, en un cuaderno, como prefieras). La columna que duele es la tercera: si no puedes fechar la línea ni siquiera aproximadamente, eso ya es información; significa que sobrevivió sin que nadie la reevaluara.
| Fragmento (archivo:línea) | Lo que intenta evitar | Cuándo nació | ¿Todavía hace falta? |
|---|---|---|---|
CLAUDE.md:42 |
"Lee el archivo antes de editar" — evitaba editar a ciegas | Época en que el modelo editaba sin leer | Probablemente no — probar |
| … | … | … | … |
| … | … | … | … |
| … | … | … | … |
✅ Criterio de salida de este módulo
Puedes señalar tres líneas concretas de tu configuración y decir, para cada una: lo que intenta evitar e de qué época es. Solo eso. Ninguna línea eliminada, ninguna decisión tomada: la decisión viene después de la prueba, en el módulo 1.2.
Revisión rápida (no bloquea nada): Anthropic recortó más del 80% del prompt de sistema en Opus 5. ¿Cuál fue el criterio para decidir qué se quedó?
📌 Resumen del Módulo
Próximo módulo:
1.2 — El método de ablación: borrar todo, usarlo en trabajo real y devolver una instrucción solo después de ver que la misma falla se repite.