Le borré el 80% a mi CLAUDE.md y Claude mejoró

Tenía 212 líneas en el archivo de instrucciones de mi proyecto. Lo había ido engordando durante meses: cada vez que Claude hacía algo que no me gustaba, yo añadía una regla. Parecía lo lógico. Si se equivoca, se lo explico mejor. Hoy tiene 32 líneas. Y trabaja mejor. No lo decidí yo por intuición. El 24 de julio de 2026 Anthropic publicó cómo cambió su forma de escribir instrucciones para la generación Claude 5, y la frase que lo resume es esta: *"We removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations."* Más del 80% del system prompt fuera. Sin pérdida medible en sus evaluaciones de código. Cuando lo leí fui directo a mi archivo. Esto es lo que encontré.

Por qué las reglas de más te frenan en vez de ayudarte

La explicación no es que escribas mal las reglas. Es que se pisan entre ellas. Anthropic leyó las transcripciones de su propio uso interno de Claude Code y encontró el problema apilado dentro de una sola petición: el system prompt decía una cosa, las skills decían otra, y encima llegaba lo que pedía el usuario. El ejemplo que citan es literal: *"leave documentation as appropriate"* contra *"DO NOT add comments"*. Ninguna de las dos está mal escrita. Las dos son razonables por separado. El problema es que llegan juntas y alguien tiene que decidir. El modelo casi siempre acierta con lo que tú querías. Pero antes de empezar gasta atención desatando el nudo que tú mismo le pusiste. Y aquí está lo incómodo, que es lo que a mí me tocó: tu archivo puede estar impecable y aun así chocar con una skill que instalaste hace tres semanas y de la que ya ni te acuerdas. Nadie escribió nada mal. Simplemente hay demasiadas capas hablando a la vez.

El cambio que mejor lo explica: una sola línea

De los seis cambios que describe el post, el que me hizo entenderlo fue un antes y un después de una línea. Antes decía: *"default to writing no comments. Never write multi-paragraph docstrings."* Ahora dice: *"write code that reads like the surrounding code: match its comment density, naming, and idiom."* Léelas dos veces, porque la diferencia no es de estilo. La primera es una orden. Para que acierte, tú tienes que adivinar hoy lo que va a hacer falta en cualquier repositorio del futuro. En un proyecto sin comentarios acierta de casualidad; en uno lleno de docstrings te obliga a pelearte con tu propio agente para que haga lo obvio. La segunda es un criterio. El modelo mira el código que tiene al lado y decide ahí mismo. Funciona en los dos repos sin que tú toques nada. Esa es toda la idea: dejaste de darle la respuesta y le diste dónde mirar.

Los tres tipos de línea que borré primero

Con ese filtro, la limpieza fue rápida. De las 212 líneas, las que se fueron caían casi todas en tres montones. Lo que puede ver solo. Qué framework uso, cómo se llaman mis tests, que hay una carpeta `src`. Todo eso lo averigua abriendo el repositorio. Escribirlo no le enseña nada: solo ocupa sitio. El post lo dice sin rodeos: evita afirmar *"lo obvio"*, lo que Claude puede saber mirando tu sistema de archivos o tu repositorio. Las órdenes absolutas. "Nunca", "siempre", "jamás". Son las que más chocan, porque no admiten el caso raro donde tú mismo harías lo contrario. Casi todas se pueden reescribir como criterio, igual que la de los comentarios. Los ejemplos de más. Tenía bloques enteros mostrando cómo quería el output. Esta generación de modelos es más imaginativa que mis ejemplos: cada uno de más lo encerraba en mi manera de hacerlo en vez de dejarlo resolver. Lo que quedó son 32 líneas de otra cosa. No es "lo mismo pero más corto".

Qué NO borrar (esta es la parte que se salta todo el mundo)

Si te quedas solo con "escribe menos", acabas con un archivo inútil. La recomendación del post es concreta: mantén tu CLAUDE.md ligero y describe brevemente para qué sirve el repositorio, pero *"spend most of the tokens on gotchas inside of the codebase"*. Gasta la mayoría en las trampas. Las trampas son lo que no puede deducir mirando. Que ese endpoint devuelve 200 aunque haya fallado. Que esa migración hay que correrla dos veces. Que esa carpeta parece muerta pero producción la lee. Lo que a ti te costó una tarde descubrir y no está escrito en ningún sitio del código. Por eso la pregunta buena para tu archivo no es cuántas líneas tiene. Es cuántas de esas líneas te costaron una tarde aprenderlas. Esas son las que valen, y esas se quedan aunque el archivo entero adelgace.

El dato honesto: esto es para la generación Claude 5

No quiero que borres media configuración y luego te enfades conmigo. El cambio vale para los modelos de la generación Claude 5, que tienen mejor criterio propio. Sobre los anteriores el propio post reconoce que *"earlier Claude models could sometimes need repeated instructions"*: ahí las reglas largas y repetidas todavía están trabajando a tu favor. Y una segunda honestidad: el "sin pérdida medible" sale de las evaluaciones internas de código de Anthropic, no de una promesa universal. Tu proyecto no es su evaluación. Por eso yo no borré 180 líneas de golpe: fui por tandas, y dejé el archivo viejo guardado por si tenía que volver. No tuve que volver.

Cómo hacerlo tú esta semana

Si quieres el atajo, hay un comando dentro de Claude Code que revisa tu configuración y te señala qué sobra, y lo cuento paso a paso en la guía de la máquina. Pero puedes empezar hoy sin instalar nada:

1. Abre tu archivo de instrucciones y cuenta las líneas. Ese número es tu punto de partida.
2. Marca las que describen algo que el modelo vería solo abriendo el repositorio. Esas se van.
3. Marca las órdenes absolutas. Reescribe cada una como criterio: en vez de "nunca hagas X", "haz que encaje con Y".
4. Lo que sobreviva, ordénalo así: dos líneas de para qué es el proyecto, y el resto trampas reales.
5. Guarda el archivo viejo. Trabaja una semana con el nuevo y compara.

A mí me quedaron 32 líneas de 212. No sé cuántas te quedarán a ti, y ese es justo el punto: el número correcto no lo decide una regla, lo decide tu repositorio.