Anthropic borró el 80% del prompt de Claude Code

Borraron el 80% de su propio prompt y el modelo no empeoró

Anthropic ha eliminado más del 80% del system prompt de Claude Code y, en sus propias evaluaciones de código, la pérdida medible ha sido cero.

Párate un segundo a pensar lo que eso significa. Ese prompt lo llevábamos un año diseccionando, copiando y metiendo en nuestras propias herramientas. Era la referencia. Y resulta que lo han quitado casi entero y funciona igual de bien.

Si tú tienes un CLAUDE.md que has ido engordando durante meses, cuatro o cinco skills y un fichero de reglas al que añades una línea cada vez que la IA hace algo que no te gusta, tengo malas noticias: probablemente la mitad de todo eso ya no te está ayudando, te está estorbando.

De dónde sale esto (y por qué no es marketing)

La fuente es una guía de context engineering que Anthropic publicó el 24 de julio de 2026, firmada por Thariq Shihipar, que trabaja dentro de la propia Anthropic. No es un bloguero probando cosas: es la empresa desmontando sus propias buenas prácticas.

El texto salió el mismo día que Opus 5, y eso no es casualidad. Todo lo que cuenta va referido a los modelos de la generación 5 — Opus 5, Sonnet 5, Fable 5. Es una consecuencia directa de que los modelos han mejorado, no un cambio de opinión sobre cómo escribir prompts.

El diagnóstico que hacen es incómodo: al revisar sus propias transcripciones internas encontraron al modelo recibiendo instrucciones que se contradecían entre ellas. Le pedían dejar documentación cuando fuera apropiado y, unas líneas más abajo, le prohibían añadir comentarios. El propio prompt tirando de él hacia dos sitios a la vez.

De ahí sale el cambio de fondo: estaban sobrerrigiendo al modelo.

El cambio de fondo: de darle reglas a darle criterio

Todos los cambios que proponen se resumen en uno solo. Antes le dábamos reglas exactas. Ahora le damos contexto y dejamos que use su criterio.

El símil de la oficina

Cuando alguien entra nuevo en una empresa, hay dos formas de explicarle cómo vestir.

La primera: “aquí se viene en vaquero y camisa, sin corbata”. Es una regla. Funciona hasta que llega un día que no encaja en la regla — una visita importante, un evento, un viernes de verano — y la persona se queda bloqueada o hace el ridículo.

La segunda: “mira cómo va vestido el resto de la oficina y vístete de forma similar”. Le estás dando criterio, no una regla. Con eso resuelve el día normal y también el día raro.

Antes, Claude Code era un becario al que había que decirle exactamente qué hacer. Ahora tiene comprensión de su entorno: ve el repositorio, ve el estilo del código que hay alrededor y decide. Cada regla que le pones por encima de eso es una regla que le impide usar lo que ya sabe.

Los seis cambios, uno a uno

La guía propone seis desplazamientos concretos. Los traduzco a lo que significan en tu proyecto.

1. De reglas a criterio

No escribas “nunca hagas X” salvo que tengas un fallo demostrado y concreto que lo justifique. Una regla dura solo se sostiene si hay un modo de fallo real detrás. Si no lo hay, la regla solo sirve para atar al modelo y para chocar con otra regla que escribiste hace tres meses.

Este es el punto que más CLAUDE.md va a adelgazar. Casi todas esas líneas que fuimos añadiendo “por si acaso” caen aquí.

2. De dar ejemplos a diseñar interfaces

Antes le dábamos ejemplos de uso. El problema es que cuando llega un caso que no se parece a ninguno de los ejemplos, el modelo se encalla.

Es mejor explicar cómo funciona la interfaz o la herramienta que enseñar tres ejemplos de cómo se usa. Con la explicación, el modelo interpreta el caso nuevo. Con los ejemplos, solo sabe repetir. Una herramienta bien descrita se explica sola y no necesita muestrario.

3. De cargarlo todo por adelantado a divulgación progresiva

Este merece otro símil. Imagina que contratas a un cocinero para tu restaurante.

El primer día le explicas lo básico: dónde está cada cosa, que el horno calienta un poco más de lo que marca, qué día llega el pescado y qué día la carne. Todo eso lo necesita desde el minuto cero porque es cómo funciona la casa.

Pero si el restaurante tiene 60 recetas, no le haces memorizar las 60 el primer día. Las consulta cuando se las piden. Y las hace.

Pues igual con tu proyecto: en el contexto permanente va cómo funciona el proyecto. Las 60 recetas — las skills, los procedimientos concretos — se cargan en el momento en que hacen falta, no antes. Eso es lo que hacen las skills y la carga contextual de herramientas.

4. De repetir instrucciones a decirlas una vez

Durante mucho tiempo se recomendaba poner lo importante al principio del prompt y repetirlo al final, porque el modelo “recordaba mejor” los extremos. Se ha comprobado que eso ya no es más eficiente.

Y es peor que ineficiente. Piensa en un contrato: si una cláusula aparece escrita tres veces con palabras distintas, primero te expones a que una de las tres esté mal redactada, y segundo, el día que tengas que cambiarla y solo la cambies en una, tienes una contradicción metida en casa.

Exactamente eso es lo que pasa en un CLAUDE.md de 300 líneas. Dilo una vez, en la descripción de la herramienta, y confía en que lo va a leer.

5. De memoria manual a auto-memoria

Buena parte de lo que anotábamos a mano en el CLAUDE.md — datos del proyecto, decisiones tomadas, cosas que aprendimos por el camino — ya se guarda por defecto con la memoria automática.

Si además lo mantienes escrito a mano, estás duplicando: dos fuentes para el mismo dato, que tarde o temprano se separan. Limpiar el CLAUDE.md no es solo ahorrar tokens, es quitar de en medio una fuente de contradicciones.

6. De especificaciones en prosa a referencias ricas

En vez de describirle con palabras lo que quieres, entrégale el artefacto: una rúbrica, una batería de tests, un mockup en HTML.

El símil aquí es directo. Si ya tienes los planos de una casa y viene un arquitecto, no le explicas la casa de palabra: le das los planos. Siendo arquitecto, los entiende mejor que a ti. Menos prosa y más referencias concretas.

Los tres que de verdad te cambian el día a día

Si solo vas a aplicar tres, aplica estos:

• El 1 (reglas → criterio), porque es el que quita más peso muerto y el que elimina las contradicciones.
• El 3 (progresivo), porque es el que reordena de verdad cómo montas el proyecto: qué es contexto permanente y qué es una skill que se carga cuando toca.
• El 5 (auto-memoria), porque es el que evita que mantengas a mano algo que el sistema ya guarda solo.

Los otros tres son importantes, pero se aplican prácticamente solos en cuanto interiorizas los tres primeros.

Antes de tocar nada: comprueba tu versión

Esto es un aviso serio. Todo lo anterior funciona con los modelos de la generación 5. No aplica a un agente en n8n conectado a un modelo antiguo, ni a automatizaciones que corran con otra cosa.

Antes de ejecutar nada, abre tu proyecto y comprueba en qué versión de Claude Code estás. En la sesión que grabé estaba en la 2.1.220, que es más que suficiente. Si cuando lees esto hay versiones posteriores, mejor: lo importante es no estar por debajo.

Actualiza antes de lanzar los comandos que vienen ahora. Si lo haces al revés, la limpieza no va a aplicar la lógica nueva.

/context: la foto de lo que ocupa tu contexto

El primer comando no toca nada, solo mide. Escribe /context en tu proyecto y te devuelve el desglose de qué ocupa el contexto ahora mismo:

• el system prompt,
• las herramientas del sistema,
• los agentes personalizados,
• las herramientas MCP, si tienes,
• los ficheros de memoria,
• y las skills.

Anota esos números. Son tu punto de partida y los vas a necesitar para comparar después. Sin esta foto previa, la limpieza es fe ciega.

/doctor: la auditoría que borra lo que sobra

El segundo comando es /doctor. Existía de versiones anteriores como comprobación de salud de la instalación, pero en las versiones actuales se ha convertido en una auditoría de contexto: lee todo lo que tienes montado y aplica las reglas nuevas.

Lo lanzas y tarda unos minutos. Lo que devuelve es un informe con varios bloques de comprobación: estado de la instalación, skills que no se usan, memoria local, recorte del CLAUDE.md, versión instalada, estado de los hooks y peso total del contexto.

Y luego te pide confirmación antes de borrar nada. Esa parte importa: no es un comando destructivo a ciegas, te enseña los cuatro o cinco grupos de cambios que propone y decides.

El criterio con el que decide es exactamente el de la guía: si algo no se ha usado nunca, lo quita. Si es un dato real del proyecto, se queda. Y si algo es un procedimiento que ya viene incluido en Claude, lo saca del contexto permanente y lo convierte en una skill que se carga cuando toca.

Qué pasó en un proyecto real

Lo lancé en un proyecto mío que uso a diario, y que además ya venía optimizado porque llevo tiempo cuidándolo. Estos son los números reales:

• Ocho skills sin usar en 239 ejecuciones, ocupando unos 1.100 tokens por sesión. Fuera.
• Dos ficheros sueltos que no pintaban nada.
• El CLAUDE.md pasó de unas 102 líneas y casi 5.000 caracteres a unos 3.800, unos 296 tokens menos por sesión.
• Las tres skills del proyecto que sí se usan quedaron con su frontmatter correcto.
• El bloque de skills bajó de unos 4.600 a 3.600 tokens.

Un detalle práctico para cuando lo hagas: si después de la limpieza vuelves a lanzar /context en la misma sesión, el apartado de mensajes habrá subido, porque en esa conversación se ha leído todo el proyecto y se han ejecutado tareas. Es normal y no significa nada. Para ver el estado real, abre una sesión nueva y lanza /context ahí. Ahí sí ves la foto limpia.

El resumen honesto: en un proyecto pequeño y ya cuidado, el ahorro es de unos cientos de tokens por sesión. No suena a mucho leído así. Pero es un coste que pagabas en cada arranque de sesión, todos los días, a cambio de nada — y encima con instrucciones que se pisaban entre ellas.

Si te interesa la disciplina de coste en serio, este es solo uno de los frentes: en su día conté cómo Graphify recorta hasta 70 veces el gasto de tokens en Claude Code, que ataca el otro lado del problema.

Dónde no aplica esto

Para que no haya malentendidos:

• No aplica a modelos anteriores. Si tienes automatizaciones corriendo con modelos que no son de la generación 5, las reglas viejas siguen siendo las buenas para ellos.
• No significa “borra tu CLAUDE.md”. Significa borrar las reglas sin fallo demostrado detrás y los procedimientos que ya viven en otro sitio. El contexto de negocio no se toca: quién es el cliente, qué stack usáis, qué convenciones tenéis, qué no se puede romper en producción. Eso es lo único que el modelo no puede saber por su cuenta, y es exactamente lo que debe quedarse.
• No sustituye a tener criterio. Las reglas que sí tienen un fallo demostrado detrás — un despliegue que se rompió, un patrón que hace daño en tu código concreto — se quedan. Y con la razón escrita al lado.

Qué te llevas de aquí

Resumido en pasos, para que lo hagas hoy mismo:

1. Actualiza Claude Code a la última versión.
2. Abre uno de tus proyectos reales y lanza /context. Apunta los números.
3. Lanza /doctor y lee el informe entero antes de aceptar nada.
4. Acepta la limpieza que te proponga.
5. Abre una sesión nueva y vuelve a lanzar /context para comparar de verdad.
6. Repasa a mano tu CLAUDE.md con una pregunta en la cabeza para cada línea: ¿esto lo puede saber el modelo por su cuenta? Si la respuesta es sí, fuera. Si es no, se queda.

Y a partir de ahora, cada vez que te den ganas de añadir una línea de reglas porque la IA ha hecho algo que no te gustó una vez: para. Pregúntate si es un fallo reproducible o fue un mal día. Solo el primero merece una línea en tu contexto.

Conclusión

Es una evolución importante, y va en la dirección contraria a la que llevábamos: durante dos años el consejo fue escribe más, sé más explícito, no dejes nada al azar. Con esta generación de modelos, el consejo se ha invertido. Cuanto menos les atas, mejor trabajan — siempre que lo que les des sea contexto real y no reglas de relleno.

Si quieres profundizar en cómo montar el sistema completo alrededor del modelo — memoria, subagentes, workflows y control de coste — lo tienes en la guía de las 6 herramientas que hacen que Claude Code trabaje solo.

En ExpertBrain montamos esta infraestructura de agentes de IA en empresas y organismos públicos, en producción y con la disciplina de coste que eso exige. Si quieres que tu equipo trabaje así, hablemos.