Context Engineering para Claude 5: Anthropic Borró el 80 % de su System Prompt

Anthropic ha borrado más del 80 % del system prompt de Claude Code para los modelos Claude 5. ¿El resultado en sus evals de coding? Ninguna pérdida medible, según cuentan ellos mismos. Cuando lo leí, hice lo que toca: pasar la auditoría por mi propia configuración antes de escribir sobre ella. Y me llevé una sorpresa de las malas: de los ~10.100 tokens que mi setup cargaba en cada sesión, unos 5.800 eran basura. Un 57 %.

Este artículo va de por qué pasa esto, qué reglas han cambiado con la generación Claude 5, y qué encontré al auditar mi configuración y un repositorio de laboratorio que monté para verlo con datos. Si usas Claude Code a diario y tu CLAUDE.md lleva meses engordando, te vas a ver reflejado.

De prompt engineering a context engineering

El 19 de junio de 2025, Tobi Lütke (CEO de Shopify) escribió en X que prefería “context engineering” a “prompt engineering”: describe mejor la habilidad real, que es darle al modelo todo el contexto para que la tarea sea resoluble. Seis días después, Karpathy lo amplificó con la definición que se quedó: el arte y la ciencia de llenar la ventana de contexto con la información justa para el siguiente paso.

Fíjate en el matiz entre los dos: Lütke habla de darle todo el contexto, Karpathy del justo. La habilidad no es acumular, es elegir.

Cuando escribes a Claude, tu prompt es la punta del iceberg. Lo que el modelo recibe es un contexto ensamblado: system prompt, tu CLAUDE.md global, el del proyecto, skills, memoria, descripciones de herramientas. Diseñar ese ensamblaje es la ingeniería de contexto. Y tiene una dificultad que el prompting no tenía: el contexto es general, se aplica a peticiones que aún no conoces. ¿Cómo escribes instrucciones para lo que no sabes que te van a pedir?

Durante dos años lo resolvimos acumulando reglas. Ahora resulta que toca lo contrario.

Menos contexto rinde más

Esto no es una preferencia de Anthropic: es comportamiento medido del transformer.

Chroma lo midió con 18 modelos de frontera y le puso nombre: context rot. El rendimiento cae de forma monótona a medida que crece el input, incluso lejos de llenar la ventana. Y un resultado que no me esperaba: en sus pruebas los modelos rindieron mejor con el texto desordenado que con documentos coherentes.

Drew Breunig agrupó los fallos en cuatro tipos, y el cuarto es el que nos importa hoy: context clash, instrucciones que chocan entre sí dentro de la misma ventana. Dex Horthy (HumanLayer) analizó unas 100.000 sesiones de desarrolladores y localizó lo que llama la dumb zone: la franja central de una ventana grande donde el recall se degrada y el razonamiento flojea.

Con ese marco, lo que cuenta Anthropic deja de sonar a marketing. Leyeron las transcripciones de su propio uso interno de Claude Code y encontraron mensajes en conflicto dentro de una misma petición: el system prompt diciendo “no escribas comentarios”, una skill diciendo “documenta según convenga”, el usuario pidiendo otra cosa. El modelo gastaba razonamiento en resolver el choque de reglas antes de ponerse a trabajar. Es el context clash de Breunig, medido en producción.

Las reglas duras existían porque los modelos de 2023 las necesitaban. Sin ellas escribían comentarios malos, borraban ficheros, se iban por las ramas. Era un trade-off aceptado. Pero una regla escrita para un modelo torpe estorba a un modelo con criterio. Anthropic llama a quitárselas unhobbling —dejar de atarle las manos—.

Las seis reglas que han cambiado

El post de Anthropic las presenta como mitos de antes contra prácticas de ahora:

Antes	Ahora
Darle reglas	Dejar que use su criterio
Darle ejemplos	Diseñar mejores interfaces
Todo el contexto por delante	Progressive disclosure
Repetir las instrucciones	Decirlas una vez, en la herramienta
Memoria manual en CLAUDE.md	Auto-memory
Specs en markdown	Referencias ricas

Tres merecen desarrollo.

Reglas → criterio. El ejemplo que pone Anthropic es su propia regla de comentarios: pasaron de “default to writing no comments. Never write multi-paragraph docstrings” a “write code that reads like the surrounding code: match its comment density, naming, and idiom”. La primera intenta cubrir todos los casos; la segunda describe la intención y deja que el modelo decida. Me tocó de lleno: yo tengo en mi CLAUDE.md global un “NUNCA añadas comentarios en el código”.

Ejemplos → interfaces. Esta es la que más me sorprendió, porque va contra la regla número uno del tool use de los últimos dos años. Cita textual: “giving examples actually constrains them to a certain exploration space”. En la charla que grabaron con Simon Willison, Thariq cuenta que al quitar los ejemplos el modelo resultó más creativo que los ejemplos que le daban. La alternativa es invertir en el diseño de la herramienta: un parámetro enum pending / in_progress / completed ya explica cómo se usa, sin ejemplo ninguno.

Todo por delante → progressive disclosure. El contexto correcto en el momento correcto: skills que se cargan solas cuando tocan, herramientas en carga diferida que el agente busca cuando las necesita, y el CLAUDE.md como árbol de ficheros en vez de almacén central de toda práctica conocida. La guía oficial lo resume en una línea que deberías grabarte: CLAUDE.md ligero, y los tokens gastados en las trampas del repo. Lo que el modelo no puede deducir mirando tu repo.

No es cosa de Anthropic: OpenAI llegó a lo mismo

Aquí está el dato que hace que esto deje de ser la opinión de una sola empresa. La guía de prompting de OpenAI para GPT-5.6 dice, cito textual: “configurations with leaner system prompts improved evaluation scores by roughly 10-15% while reducing total tokens by 41-66% and cost by 33-67%”. Y su consejo estrella es idéntico al de Anthropic: “state each instruction once”.

Las dos empresas líderes —el mismo mes, con datos propios— llegando a la misma conclusión: sobre-instruir a los modelos de 2026 los empeora. Y de propina los encarece.

El experimento: un laboratorio para ver /doctor trabajando

Anthropic ha metido estas prácticas en un comando, /doctor, que audita tu instalación y propone recortes. Leer lo que hace está bien; verlo trabajar está mejor. Así que monté context-doctor-lab: un proyecto TypeScript pequeño y real (los tests pasan con npm test, sin dependencias) cuyo CLAUDE.md inflé a propósito con los antipatrones exactos del post. Árbol de directorios, lista de dependencias, overview de arquitectura de un módulo de 60 líneas, la instrucción de tests repetida tres veces, ejemplos de uso de herramientas, un “session log” mantenido a mano y tres pares de reglas en conflicto. Entre medias sembré cuatro trampas reales: cosas que el modelo no puede deducir del código, como que los estados de las tareas los hardcodea una app móvil.

Lo que hizo /doctor con el laboratorio:

• Cortó todo lo plantado. El árbol de directorios (“es un ls”), las dependencias (“están en package.json”), el overview (“describe 60 líneas de código que se leen en 5 segundos”), los ejemplos de herramientas (“ruido puro”) y el session log (“eso es git log”).
• Conservó las cuatro trampas íntegras. Es justo lo que un modelo no puede saber mirando src/store.ts.
• Resolvió las contradicciones con evidencia. Ante “anota todos los tipos” contra “prefiere inferencia”, fue al código, vio que anota retornos explícitos, y se quedó con la regla que el código ya cumple. El código manda.
• Y mi favorita: una de las reglas falsas decía “maximum line length is 100 characters (prettier default in this repo)”. El doctor fue a verificar que no existe configuración de prettier en el repo y propuso borrar la regla por fundarse en una premisa falsa. No es pattern matching: es verificación.

El repo es público. Clónalo, pasa /doctor y compara lo que corta con la tabla del README. Es la forma más rápida que conozco de interiorizar las seis reglas.

Lo que encontré al auditar mi configuración real

El laboratorio es didáctico porque está preparado. Mi configuración no lo estaba, y por eso sus números valen más:

• ~10.100 tokens residentes por sesión, de los que ~5.800 no aportaban nada: una suite de 16 skills y 5 agentes de un experimento que abandoné hace un mes, cuatro plugins muertos y varios servidores MCP sin uso.
• La misma instrucción por triplicado. Tenía las indicaciones de una herramienta de documentación en tres sitios: mi CLAUDE.md global, un fichero de rules y las instrucciones que inyecta el propio servidor MCP. Y no eran copias: se contradecían entre sí (una obligaba a usar la CLI, otra exponía herramientas MCP distintas). Context clash de manual, autoinfligido.
• Un bloque entero de personalidad duplicado entre el CLAUDE.md global y el output style, casi palabra por palabra: 1.800 tokens pagados dos veces en cada sesión.
• Veredicto del doctor sobre mi CLAUDE.md global: recortar el 62 %. Lo que sobrevive es exactamente lo que predica la guía: seguridad, convenciones que difieren del default y trampas de infraestructura. Nada derivable.

La lección que me llevo no es “tenía basura” (eso le pasa a cualquier configuración con meses de vida). Es que la basura no se nota: ningún error, ningún aviso. Solo un modelo que razona un poco peor cada sesión. Y encima pagas esos tokens.

Los matices que el post oficial no cuenta

Me creo la tesis, y aun así hay tres matices que conviene tener delante.

El riesgo de lock-in. La crítica más afilada del hilo de Hacker News: un CLAUDE.md es un fichero de texto portable a cualquier herramienta; el auto-memory es del producto. Cita de un comentarista: “A CLAUDE.md file has no moat… Automemory can be weaved into the product in ways that make it harder to switch”. Quitar reglas de tu fichero y confiar en la memoria automática es también una transferencia de control. Me parece un trade-off razonable, pero hay que firmarlo sabiéndolo.

Esto es por generación de modelo. Anthropic mantiene prompts distintos según la generación del modelo: a los frontera les dan instrucciones escuetas, y los antiguos conservan las detalladas. Si usas modelos baratos para tareas mecánicas (yo lo hago, y en el vídeo del loop engineering se ve por qué compensa), sus reglas siguen haciendo falta. “Borra tus reglas” aplica al modelo que tiene criterio para sustituirlas.

Menos reglas no es cero contexto. El propio post lo dice: los tokens que sobreviven van a las trampas del repo. La habilidad no desaparece, se desplaza: de escribir normas a decidir qué es genuinamente no-derivable. Y para el prompt que sí escribes, me quedo con la heurística de Cat Wu en la charla con Willison: antes de añadir una regla, pregúntate cómo malinterpretaría tu petición una persona bienintencionada. Eso arregla el contexto mejor que otra norma.

Cómo aplicarlo hoy

Mi checklist después de esta semana:

1. Pasa /doctor. Reporta antes de tocar nada y pide confirmación para cada cambio. Mi consejo: no aceptes en bloque, lee sus veredictos, se aprende más de los porqués que del recorte.
2. Reescribe tu CLAUDE.md con una sola pregunta en la cabeza: ¿puede deducir esto mirando el repo? Si sí, fuera. Estructura de directorios, dependencias, comandos estándar: fuera. Convenciones que difieren del default, decisiones con motivo, límites de APIs externas: dentro.
3. Una instrucción, una vez. Si está en la descripción de la herramienta, no la repitas en el system prompt ni en el CLAUDE.md.
4. Ejemplos solo si codifican un requisito de producto. Para lo demás, mejora la interfaz: nombres de parámetros expresivos, enums que insinúan el uso.
5. Referencias ricas en vez de specs planas. Un mockup HTML rinde más que describir el diseño. Una suite de tests es una spec ejecutable. Esto conecta con todo lo que vengo escribiendo de harness engineering: la calidad no la pone la instrucción, la pone el sistema alrededor.

El péndulo completo se ve con distancia: primero optimizamos el prompt, luego el contexto, luego el arnés, ahora el bucle. Cada capa hizo obvia la siguiente. Lo curioso de esta parada es que por primera vez la mejora consiste en quitar.

---

P.D.: Si auditas tu configuración y te salen números peores que mi 57 %, me encantaría verlos. Cuéntamelo en X (@lm_martinbar), que estoy recopilando casos para el vídeo que acompaña a este artículo.