Abre tu fichero de instrucciones. El CLAUDE.md, el prompt de sistema, el documento que le pegas a la IA cada mañana antes de empezar.

Cuenta las líneas. Ahora dime cuántas has borrado en el último año.

Casi seguro que ninguna. Ese documento sólo crece. Cada vez que el modelo mete la pata añades una regla, y esa regla se queda ahí para siempre, como los cables detrás del televisor.

El 27 de julio, Boris Cherny — el creador de Claude Code — contó en el podcast Root Access de Y Combinator qué hizo su equipo cuando llegó Claude Opus 5. No añadieron instrucciones.

Borraron más del 80% del prompt de sistema de su propia herramienta.

Y la herramienta mejoró.

Por qué tu prompt sólo crece

Empiezo por lo que no es técnico, porque es lo que de verdad te va a frenar. Y aquí hablo de psicólogo, que para algo lo soy.

Cada regla que tienes escrita te costó algo. Una tarde perdida, un entregable que salió mal, una reunión incómoda. Escribiste esa línea con la sensación de haber aprendido una lección. Borrarla se parece mucho a tirar la lección a la basura.

A eso se suma una asimetría que nos come a todos. El coste de dejar una regla que sobra es invisible; el coste de quitar una que hacía falta te lo imaginas al instante. Prefieres el daño que viene de no hacer nada al daño que viene de haber tocado algo. Es el mismo mecanismo por el que nadie cancela suscripciones.

Así que no quitas. Añades.

Y un año después tienes cuarenta líneas de las que sólo recuerdas el origen de seis.

Un prompt que sólo crece no es un prompt cuidado. Es un prompt que nadie se atreve a tocar.

El andamio y la pared

Piensa en esas reglas como el andamio de una obra.

Lo montaste porque la pared no se sostenía sola. El modelo se desviaba, se inventaba cosas, se saltaba pasos. Cada tubo que pusiste tapaba una grieta real y tú lo viste con tus ojos.

La pared de 2026 se sostiene sola.

Pero el andamio sigue montado, y ahora hace dos cosas malas: tapa la pared y te hace tropezar. No es que el modelo te desobedezca. Es justo lo contrario: te obedece con una literalidad que antes no tenía, así que las reglas viejas ahora se cumplen de verdad, incluidas las que ya no venían a cuento.

Es la misma incomodidad que conté cuando salió la guía de cómo promptear Claude Fable 5. Allí la conclusión era escribir menos. Aquí hay un paso más: el trabajo se muda de sitio.

Ablación: el método que te quita la decisión de las manos

Lo interesante de lo que cuenta Cherny no es el 80%. Es cómo llegaron a esa cifra.

No revisaron el documento línea a línea preguntándose "¿esto sigue haciendo falta?". Eso no funciona, y ya sabes por qué: repasando de una en una, todas parecen razonables y todas se quedan por si acaso.

Hicieron ablación. Borrar el prompt entero y devolver sólo las líneas donde el modelo falla repetidamente en el mismo punto concreto.

La diferencia es quién decide. Revisando, decides tú, y tú tienes el sesgo. Con ablación deciden los fallos. Una regla no vuelve porque suene sensata, vuelve porque hay un error observado que la reclama.

Te lo traduzco a una semana de tu vida:

Guarda una copia de tus instrucciones, tus skills y tus ficheros de contexto. Esto es lo que te permite hacer lo siguiente sin miedo.
Vacíalos del todo. No a la mitad. A la mitad no mides nada.
Trabaja una semana normal y apunta cada vez que el modelo falle. Sin corregirlo en el prompt, sólo apuntando.
Devuelve lo que aparezca dos veces. Un fallo suelto es ruido. Uno que se repite se ha ganado su línea.

Cherny recomienda repetirlo cada pocos meses. Yo lo tengo en el mismo cajón que la revisión de accesos y las copias de seguridad: se hace por calendario, nunca cuando te acuerdas.

Lo que he quitado yo, y lo que todavía no sé

Esto no te lo cuento desde la barrera.

Durante meses construí un sistema encima de Claude Code para que no se me olvidara nada. Lo llamé Sinapsis y lo conté aquí con bastante orgullo cuando lo estrené, en este artículo que sigue publicado y describe el sistema tal y como era. Esto de aquí es la continuación.

Por dentro tenía cinco tipos de pieza, y te las cuento sin nombres raros porque el nombre da igual:

Once disparadores automáticos. Se ejecutaban solos al abrir una sesión, al guardar un fichero o al terminar, sin que yo pidiera nada.
Treinta y seis reglas fijas. Recordatorios que se colaban en cada conversación para que no repitiera errores que ya había cometido.
Cuarenta y una notas aprendidas. El sistema observaba mis correcciones y las convertía en reglas nuevas por su cuenta.
Treinta y tres comandos propios para las tareas que repetía cada semana.
Siete modos de razonamiento, uno para cada fase de un proyecto.

El 30 de julio lo desmonté casi entero. Lo que ha quedado en pie es lo que uso todas las semanas y no me discute nadie.

Antes de borrar una sola línea hice lo que te pedía arriba. Está todo respaldado en un repositorio privado y en un disco aparte, verificado. Esa copia es lo único que me permitió atreverme, y por eso es el primer paso del método y no el último. Sin red debajo, nadie salta.

Al repasar el inventario me encontré con lo previsible. Varias reglas protegían de fallos de herramientas que ya ni uso. Otras avisaban de limitaciones de plataformas que se habían corregido hacía meses.

Todas eran verdad el día que las escribí. Muchas llevaban meses siendo peso muerto. Y ninguna molestaba lo suficiente como para que yo la borrara.

Ese es el punto exacto: una regla no avisa cuando caduca. Se queda ahí, con el mismo aspecto de regla útil que tenía el primer día.

Tengo fecha de revisión en el calendario: el 28 de octubre. Lo que no haya echado de menos para entonces se archiva en firme.

Y ahora la parte honesta: no tengo resultados todavía, y no me los voy a inventar. Llevo un día. Lo que voy a medir es simple — cuántas de esas piezas acabo echando de menos de verdad, cuáles vuelvo a montar y cuáles descubro que llevaban meses estorbando sin que yo lo supiera. Cuando tenga números lo publico aquí, salga como salga. Si resulta que me he equivocado y tengo que volver a montarlo todo, también lo vas a leer.

Lo que ha cambiado por debajo

Tres cosas de Opus 5 que conviene saber antes de tocar nada. Te las cuento sin jerga.

Ahora piensa siempre. Antes, si no configurabas nada, el modelo respondía directo. Ahora razona antes de contestar aunque tú no le pidas nada. Eso ocupa espacio: si tenías el límite de respuesta ajustado al milímetro, ahora ese límite tiene que dar para el razonamiento y para la respuesta.

Escribe más largo. Responde más y, cuando genera documentos, los genera más extensos. No es un defecto, es su tendencia por defecto.

Delega más. Cuando puede repartir el trabajo entre varios agentes, lo hace con demasiada alegría. Cada uno de esos agentes vuelve a leerlo todo, vuelve a explorar y luego te toca leer su informe.

Si tu integración empieza a cortar respuestas a medias, ya sabes por dónde mirar. No se ha vuelto verboso porque sí: hay un razonamiento compitiendo por el mismo espacio. Amplía el límite antes de culpar a nadie.

El dial que todo el mundo sube y hay que bajar

Opus 5 tiene un mando de esfuerzo con cinco posiciones. Anthropic recomienda empezar arriba para programación y para agentes.

La parte útil viene después: baja y mide. Las posiciones bajas rinden en Opus 5 muchísimo mejor de lo que rendían en la generación anterior. Trabajo que jamás habrías dejado en "medio" hace tres meses sale bien ahora, y te cuesta bastante menos.

Lo que no funciona es usar ese mando para acortar respuestas. Cambia cuánto piensa, no cuánto escribe. Para que escriba menos hay que pedírselo con palabras.

La trampa de la verificación

Esta es la parte que casi todo el mundo va a entender al revés, y es la que más dinero vale.

Cherny dice que los mecanismos de verificación son lo que más gente sigue haciendo mal. La documentación de Anthropic dice que borres tus instrucciones de verificación.

Parece una contradicción. No lo es. Hablan de dos cosas distintas y sólo suena igual.

Verificación como entorno. Tests que se ejecutan, un compilador, una hoja de cálculo que cuadra, alguna forma real de comprobar si el resultado vale. Esto hay que construirlo. Es lo que separa a un agente que trabaja solo tres horas de uno que se atasca a los diez minutos.
Verificación como frase. El clásico "revisa tu trabajo antes de responder" pegado en el prompt. Esto hay que borrarlo. Opus 5 ya se revisa solo, y pedírselo otra vez provoca revisión de más: más tiempo, más gasto, mismo resultado.

Anthropic lo dice con todas las letras en su guía de migración: quitar esas frases reduce la sobre-verificación sin perder calidad. Es un borrado, no una reescritura.

Y fíjate en lo que acaba de pasar, porque es incómodo: "pídele que se autoevalúe" ha sido buena práctica durante años. En este modelo, ya no.

Invierte en el espejo, no en la frase que le pide mirarse. Es exactamente la idea de loop, la palabra que explica la IA: un loop sin espejo no es un agente, es un microondas con ínfulas.

Qué quitas y qué pones en su sitio

Resumido, y todo sale de la guía oficial de migración:

Fuera "verifica tu trabajo" y cualquier paso de comprobación que hayas duplicado tú por encima del modelo. Fuera también las guías que animaban a repartir tarea entre agentes, si las escribiste para la generación anterior.

Dentro tres frases cortas:

Concisión. En las pruebas de Anthropic, una sola instrucción de brevedad recortó la longitud de las respuestas alrededor de un 20%.
Alcance. Algo del estilo de "entrega lo que te he pedido; si crees que el enfoque está mal, dilo en una línea y sigue". Reduce a casi cero que el modelo amplíe la tarea por su cuenta.
Un techo de agentes. Un número, no una recomendación.

Al final del artículo te dejo el prompt con el que audito todo esto, por si prefieres no hacerlo a mano.

Dónde no se aplica nada de esto

Todo lo anterior vale para trabajo interno y reversible: código con tests, borradores, análisis, investigación.

Mantén tu propio "sí" en todo lo externo o permanente. Correos a clientes, gastos, publicaciones, borrados, cualquier cosa con efecto legal o financiero. Un modelo más capaz merece más autonomía, no un cheque en blanco. Esa línea no la mueve ninguna versión.

Y una nota de método, porque aquí los datos van con su origen. Las cifras de Cherny salen del episodio de Root Access del 27 de julio de 2026; las recomendaciones de configuración, de la documentación de migración de Anthropic. Dejé fuera un par de números del podcast que no pude contrastar en ninguna otra parte, que es la misma disciplina del método brújula: si no lo puedo comprobar, no lo escribo.

Vuelve un momento al andamio. Lo difícil no es desmontarlo: son cuatro tubos y una tarde. Lo difícil es aceptar que la pared aguanta sin él, porque el andamio lo montaste tú y te costó lo suyo.

Empieza por una copia de seguridad y un fichero vacío. El resto lo deciden los fallos.

Si estás adaptando tus instrucciones o las de tu equipo a esta generación de modelos, es justo lo que trabajo en las formaciones in-company. Y si prefieres mirarlo sobre tu caso, reserva una sesión de diagnóstico gratuita de 30 minutos y lo vemos juntos.

El prompt, por si quieres hacerlo con red

Todo esto se puede hacer a mano, pero es tedioso y se abandona a la tercera carpeta. Así que te dejo el prompt con el que audito una configuración antes de decidir qué se borra. Pégalo en una sesión de Claude Code, dentro del proyecto que quieras revisar.

Tres cosas antes de que lo uses:

No borra nada, ni edita nada. Entrega un inventario y un plan, y te pide aprobación explícita antes de tocar un fichero. Puedes lanzarlo sin miedo.
Está atado a la documentación oficial, no a mi opinión. El umbral de 200 líneas por fichero, la pregunta de si quitar una línea provocaría errores, la diferencia entre un hook y una instrucción: todo eso sale de ahí, y las fuentes van dentro del propio prompt para que las compruebes.
Distingue lo que no se toca. Hay líneas que parecen prescindibles y no lo son: el nombre exacto de una marca, un campo obligatorio de tu CRM, una herramienta que retiraste. Quitar eso no libera razonamiento, produce invención. El prompt las aparta antes de proponer nada.

Y si tu configuración está sana, el informe correcto es "no hay nada que recortar". Un auditor que siempre encuentra algo que cortar no está auditando.

# Auditoría de configuración de Claude Code

Audita la capa de usuario de esta instalación de Claude Code y propón un plan de
recorte que la deje alineada con las buenas prácticas oficiales de Anthropic.

El objetivo no es recortar. Es que sobreviva sólo lo que hace que Claude acierte.
Si la configuración ya está sana, dilo y no propongas nada: un auditor que siempre
encuentra algo que cortar no está auditando.

## Alcance

Inventaría lo que se carga en cada sesión, y sólo eso:

- `CLAUDE.md` en todos sus ámbitos (managed policy, `~/.claude/`, proyecto, local)
- `.claude/rules/` de usuario y de proyecto, separando las que tienen `paths` de
  las que no
- la memoria automática del proyecto (`MEMORY.md`), de la que se cargan las
  primeras 200 líneas o 25 KB en cada sesión y que por tanto compite por el mismo
  espacio que un `CLAUDE.md`
- hooks en `settings.json` de todos los ámbitos
- comandos, skills y subagentes definidos localmente
- servidores MCP conectados

Mide y reporta: líneas y caracteres de cada `CLAUDE.md`, número de hooks, de reglas
que cargan siempre, y de skills y comandos. El umbral oficial es 200 líneas por
`CLAUDE.md`; por encima, la adherencia cae y Claude empieza a ignorar reglas reales.

## Criterio de clasificación

Clasifica cada bloque en una de tres categorías. Esta es la parte que decide la
auditoría entera, y confundir A con B es el fallo que la arruina.

**A. Datos canónicos.** Hechos que el modelo no puede derivar de ninguna parte:
nombres exactos de marcas o productos, campos obligatorios de sistemas internos,
identificadores fiscales o bancarios, rutas de infraestructura, convenciones que
difieren del comportamiento por defecto, herramientas prohibidas o retiradas.

Se quedan siempre. Recortar un dato no libera razonamiento: produce alucinación.
Un modelo sin la línea que dice cómo se escribe una marca no improvisa mejor,
inventa el nombre en un entregable de cliente.

**B. Guía de comportamiento.** Preferencias de estilo y proceso: formato de
respuesta, convenciones de commit, cómo estructurar tests o PRs.

A examen, una por una. Pregunta el test oficial de Anthropic: ¿quitar esta línea
haría que Claude cometa errores? Si el modelo actual ya lo hace de forma nativa,
sobra: cada generación absorbe parches que la anterior necesitaba.

**C. Narrativa, histórico y derivable.** Explicaciones largas, historia de
decisiones, descripciones de la estructura del código, tutoriales, información que
cambia con frecuencia.

Fuera del contexto permanente. No se borra: se mueve a un fichero consultable, a
una skill que cargue bajo demanda, o a un comentario HTML de bloque dentro del
propio `CLAUDE.md` (los comentarios de bloque se eliminan antes de inyectar el
contenido, así que quedan legibles para humanos y cuestan cero tokens). Si mueves
algo, deja una línea de puntero fuera del comentario para que siga siendo
encontrable.

## Criterio para el andamiaje

Hooks, comandos, subagentes y reglas se juzgan aparte. El fallo típico aquí es un
sistema de decenas de piezas que se construyó para modelos anteriores y que ahora
compite con la inteligencia del modelo en vez de complementarla.

- Hook: se queda sólo si impone algo que debe ocurrir siempre, con cero
  excepciones, y que fallaría si dependiera del criterio del modelo. Un hook que
  formatea o bloquea escrituras es legítimo. Un hook que "recuerda" un
  comportamiento es una instrucción disfrazada: va a `CLAUDE.md` o a ningún sitio.
- Regla sin `paths`: carga en cada sesión, así que cuenta como `CLAUDE.md` y se
  juzga con el mismo criterio. Si sólo aplica a parte del código, dale `paths` en
  vez de borrarla.
- Regla con `paths`: carga condicional, coste casi nulo. Umbral bajo para
  conservarla.
- Comando o skill: comprueba si se ha usado. Lo que lleva meses sin invocarse
  es candidato a archivo, no a mantenimiento.
- Subagente: se justifica si aporta aislamiento de contexto o un conjunto
  distinto de herramientas. Si sólo es un prompt distinto para el mismo trabajo,
  probablemente es redundante.

## Límites

- No borres ni edites nada sin aprobación explícita. Entregas un plan, no un
  resultado.
- Antes de cualquier cambio aprobado, respalda la configuración completa y di
  dónde quedó el respaldo.
- Nunca propongas eliminar contenido de categoría A, aunque el criterio de
  frecuencia lo señale. Ninguna de esas líneas se cumple en cada ejecución, y ese
  es precisamente el motivo por el que el criterio de frecuencia no aplica a ellas.
- No propongas montar un sistema de evaluación con ejecuciones repetidas para
  decidir recortes. Para efectos categóricos el resultado es deducible sin medir;
  para efectos de estilo el coste de medir supera al beneficio. La documentación
  oficial pide observar si el comportamiento cambia en uso real, no construir un
  banco de pruebas.
- Si algo es ambiguo entre A y B, se queda. El coste de perder un dato es
  asimétricamente mayor que el de conservar una línea de más.

## Verificación

Antes de dar la auditoría por buena:

- Confirma con `/context` qué ficheros de memoria cargan de verdad. Lo que no
  aparece ahí, Claude no lo ve, y auditarlo es perder el tiempo.
- Busca contradicciones entre ámbitos. Dos reglas en conflicto hacen que el modelo
  elija una arbitrariamente, y eso se manifiesta como "no me hace caso".
- Reporta el recuento de líneas antes y después de cada recorte propuesto.
- Si la versión instalada es 2.1.206 o superior, `/doctor` incluye un chequeo que
  propone recortes de `CLAUDE.md` automáticamente. Contrasta tu propuesta con la
  suya y explica las diferencias en vez de ignorarlas.

Tras aplicar recortes, la verificación es de uso, no de laboratorio: se observan
las siguientes sesiones reales. Si el modelo falla en algo que antes acertaba, se
reintroduce esa línea sola y se comprueba si el fallo desaparece. Línea a línea,
nunca por bloques.

## Entrega

Un informe con:

1. Inventario medido, con las cifras contra el umbral de 200 líneas.
2. Cada bloque clasificado en A, B o C, con una línea de justificación.
3. Plan de recortes ordenado por relación beneficio/riesgo, separando lo que se
   elimina de lo que se reubica y adónde.
4. El veredicto honesto sobre el impacto esperado. Si la configuración ronda las
   60 u 80 líneas, el ahorro de tokens es irrelevante y el beneficio real, si
   existe, es de adherencia. Dilo así en vez de vender una mejora que no vas a
   poder demostrar.

Si el inventario sale limpio, el informe correcto es "no hay nada que recortar" con
las cifras que lo respaldan.

## Referencias

- https://code.claude.com/docs/en/memory
- https://code.claude.com/docs/en/best-practices

Opus 5: borraron el 80% del prompt de Claude Code (y por qué tú no vas a hacerlo)