Skip to main content
Claude CodeCLAUDE.mdоптимизация токенов

Por qué reviso CLAUDE.md tras un lanzamiento

Tras cada nuevo modelo de Claude, trato CLAUDE.md como código que necesita revisión. Las reglas antiguas que antes eran necesarias ahora solo malgastan tokens y confunden al modelo. Podarlas hace que la integración de IA sea más predecible y ayuda a los equipos a evitar quemar contexto innecesario, incluso sin documentación oficial sobre modelos 'Fable'.

Contexto técnico

No lo convertiría en mitología, pero el consejo es sólido: después de que sale un nuevo modelo de Claude, casi siempre releo CLAUDE.md. En la automatización real con IA es un artefacto de trabajo como un prompt de sistema, un enrutamiento o un conjunto de tool calls. Si el modelo se vuelve más inteligente, algunos viejos parches solo estorban.

Ahí suelo frenar y recortar sin piedad. Si en el archivo se han acumulado prohibiciones largas, reglas repetitivas y microinstrucciones para cada situación, el modelo gasta contexto no en la tarea, sino en mantener los viejos miedos del equipo.

Una salvedad importante: no encontré documentación oficial de Anthropic que diga explícitamente que tras cada lanzamiento haya que reescribir CLAUDE.md. Y menos aún hay una línea pública confirmada sobre unos supuestos “Fable models”. Parece ser un nombre interno o terminología local de alguien.

Pero la conclusión práctica no cambia. Veo lo mismo en los proyectos: un modelo nuevo interpreta de otra forma las instrucciones antiguas, y un CLAUDE.md hinchado empieza a provocar rondas extra, aclaraciones y verificaciones innecesarias. Esto ya no es teoría, es pura mecánica de la ventana de contexto.

Lo que suelo comprobar: qué reglas realmente evitan errores y cuáles solo duplican el sentido común del modelo. Si una línea se puede eliminar sin consecuencias, la elimino. Los detalles de arquitectura, pruebas y casos de dominio los muevo a archivos separados, dejando solo un esqueleto corto en CLAUDE.md.

Otra prueba útil: ejecuto 2 o 3 tareas típicas tras el cambio de modelo y observo dónde tropieza. Solo después de un fallo real añado una nueva instrucción. No antes.

Impacto en negocio y automatización

Para el negocio esto no es filosofía, sino efectos muy concretos. El primero: menos tokens desperdiciados, sobre todo si el equipo usa con frecuencia a Claude en el IDE, CI o asistentes internos. El segundo: menos desviaciones extrañas en el comportamiento tras una actualización del modelo.

Ganan los equipos con muchos escenarios de ingeniería repetibles: código, revisión, soporte, agentes de conocimiento internos. Pierden quienes convierten CLAUDE.md en un vertedero de deseos corporativos.

En el desarrollo de soluciones de IA, yo trataría estos archivos como una parte viva del sistema, no como una nota que se escribe y se olvida. En Nahornyi AI Lab justamente analizamos esos cuellos de botella: dónde basta un esqueleto corto, dónde hace falta un skill, dónde una arquitectura de IA separada y dónde una instrucción solo infla el coste. Si sientes que Claude ha empezado a dar vueltas y a quemar contexto, podemos examinar rápidamente tu flujo de trabajo y construir una automatización de IA más limpia que se ajuste a tu proceso real.

Ya analizamos un caso en el que Anthropic degradó en secreto las respuestas de Claude, lo que obligó a los usuarios a revisar sus instrucciones. Este incidente ilustra de manera muy clara por qué actualizar claude.md justo después del lanzamiento de un nuevo modelo se ha convertido en una práctica fundamental.

Compartir este articulo