Tus instrucciones también envejecen

El consejo que parece una locura

En julio de 2026, Boris Cherny —creador de Claude Code— propuso una prueba bastante incómoda: cada seis meses, borrar temporalmente tu CLAUDE.md, tus Skills y tus hooks para ver qué puede hacer el modelo nuevo sin el andamiaje que construiste para el anterior.

La palabra importante es prueba. No estaba diciendo que el contexto dejó de importar ni que debés destruir un sistema de producción. Estaba señalando algo que nos pasa a todas: cada vez que la IA falla, agregamos otra regla. El archivo crece, el modelo cambia y rara vez volvemos a preguntar si esa cicatriz todavía sirve.

El dato que cambia la conversación

Anthropic contó que eliminó más del 80% del system prompt interno de Claude Code al preparar la generación Claude 5, sin una pérdida medible en sus evaluaciones de coding. Muchas instrucciones existían para corregir comportamientos que los modelos nuevos ya resolvían por sí solos.

Eso no convierte el 80% en una fórmula para tu proyecto. Sí cambia la pregunta. En vez de “¿qué más debería decirle?”, conviene preguntar “¿qué información no puede descubrir y qué regla sigue demostrando valor?”.

Un prompt enorme también puede sobre-restringir. Si CLAUDE.md, una Skill, una regla y tu solicitud dicen versiones ligeramente distintas de lo mismo, el modelo tiene que decidir cuál priorizar antes de empezar el trabajo.

Tu archivo de instrucciones también envejece

Pensá en CLAUDE.md como un manual escrito por varias versiones tuyas para varias versiones del modelo. Ahí pueden convivir:

• una convención real del equipo;
• un workaround para un modelo que ya no usás;
• una preferencia repetida tres veces;
• un procedimiento de treinta pasos que solo aplica una vez al mes;
• y una regla de seguridad que, en realidad, debería ser un control técnico.

Más texto no siempre significa más contexto. El contexto útil es información de alta señal que aparece en el momento correcto.

Qué sí debería quedarse

El archivo principal todavía es valioso para datos persistentes que el modelo no puede inferir con seguridad:

• el propósito breve del proyecto;
• comandos reales para ejecutar, probar y construir;
• arquitectura o convenciones particulares del repositorio;
• restricciones del negocio, legales o de marca;
• gotchas que ya causaron fallos y siguen vigentes;
• una definición concreta de terminado.

La documentación de Claude Code recomienda mantener cada CLAUDE.md por debajo de 200 líneas. No es una competencia por llegar a 199: es una señal para mantenerlo específico, conciso y legible.

Qué debería salir

Estas son las primeras candidatas para una prueba sin instrucciones:

• consejos genéricos como “escribí buen código” o “sé profesional”;
• recordatorios para capacidades que el modelo actual ya ejecuta bien;
• procedimientos largos que solo se usan en una tarea;
• documentación que ya existe en una fuente confiable;
• reglas duplicadas o contradictorias;
• instrucciones imposibles de comprobar;
• prohibiciones que deberían vivir en permisos o controles deterministas.

Menos reglas no significa un pedido vago. La tarea todavía necesita un objetivo, alcance, entregable y criterio de éxito claros.

Dónde poner lo demás

La arquitectura de 2026 se parece menos a un manual gigante y más a un clóset bien organizado:

Las Skills funcionan por progressive disclosure: el modelo ve primero su nombre y descripción; carga el procedimiento completo cuando la tarea lo necesita. Es una mejor casa para un checklist de deploy, una revisión de seguridad o un flujo de contenido que no debería ocupar contexto durante todo el día.

El protocolo de poda semestral

No borres nada a ciegas. Hacé una pequeña evaluación.

1. Guardá una copia versionada de tu configuración actual.
2. Elegí tres a cinco tareas representativas, incluyendo una difícil.
3. Ejecutalas con el modelo actual y el sistema completo.
4. Repetilas con un CLAUDE.md mínimo y sin los procedimientos heredados.
5. Compará calidad, correcciones, tiempo, costo y cumplimiento de restricciones.
6. Reincorporá una regla solo cuando resuelva un fallo observado.
7. Mové procedimientos y controles al mecanismo que les corresponde.

La verificación no desaparece. Lo que cambia es la forma: tests, revisiones, criterios de aceptación y límites reales pesan más que repetir “verificá todo” dentro del prompt.

Lo que esto significa si no sos developer

La misma idea aplica a marketing, diseño, operaciones o educación. Si tu archivo de marca intenta contener toda la personalidad, cada campaña, cada plataforma y cada checklist, el modelo recibe una mezcla de identidad, datos y procedimientos que compiten entre sí.

Separá cuatro capas:

• identidad: quién sos y qué no cambia;
• estándares: cómo se ve un resultado aprobado;
• procesos: pasos reusables que se activan cuando hacen falta;
• referencias: ejemplos y fuentes que se consultan bajo demanda.

La ventaja en 2026 no está en escribir el manual más largo. Está en saber qué contexto merece entrar, cuándo debe aparecer y cómo comprobar el resultado.

Volver arriba