Boris Cherny, creador de Claude Code en Anthropic, ha lanzado una recomendación poco habitual para quienes han llenado la herramienta de instrucciones, skills y automatizaciones: borrarlas periódicamente y comprobar qué sigue siendo realmente necesario. Su propio equipo eliminó más del 80 % del system prompt de Claude Code con la llegada de Claude Opus 5, después de comprobar que muchas instrucciones corregían limitaciones que el nuevo modelo ya podía resolver por sí mismo.
Las claves del cambio de filosofía en Claude Code en 20 segundos
- Anthropic eliminó más del 80 % del system prompt de Claude Code para Opus 5.
- Cherny aconseja probar cada seis meses Claude Code sin
CLAUDE.md, skills y hooks antiguos. - El objetivo no es eliminar toda configuración, sino detectar instrucciones que ya no aportan valor.
- Para tareas complejas propone definir objetivo, límites y criterios de finalización, dejando al modelo decidir cómo resolverlas.
La idea contradice aparentemente buena parte de las recomendaciones que han circulado durante el último año alrededor de los agentes de programación. A medida que Claude Code ganaba capacidades, muchos usuarios construyeron archivos CLAUDE.md, colecciones de skills, hooks y extensas instrucciones para conseguir resultados más consistentes.
Cherny plantea ahora que esa acumulación puede convertirse en un problema.
No porque los skills hayan dejado de ser útiles, sino porque una instrucción creada para corregir un comportamiento de Claude hace seis meses puede ser innecesaria, o incluso contraproducente, con un modelo posterior.
Anthropic borró más del 80 % de sus propias instrucciones
Cherny explicó esta filosofía durante una conversación publicada por Y Combinator tras el lanzamiento de Opus 5.
Claude Code no utiliza un conjunto de instrucciones inmutable. Anthropic modifica el system prompt, las herramientas disponibles y los propios prompts asociados a ellas cuando cambia el modelo.
La razón es sencilla: modelos diferentes pueden necesitar instrucciones diferentes.
Con Opus 5, Anthropic comprobó que buena parte del system prompt estaba solucionando comportamientos que el nuevo modelo ya gestionaba correctamente. El equipo terminó eliminando más del 80 % de esas instrucciones.
Cherny llegó a señalar que en determinados experimentos el modelo parecía comportarse de forma más inteligente con menos instrucciones.
La técnica utilizada para comprobarlo se conoce como ablación.
En lugar de asumir que cada línea del prompt continúa siendo necesaria, el equipo elimina instrucciones y mide qué ocurre. Posteriormente puede recuperar elementos individualmente para comprobar si aportan una mejora real.
El planteamiento resulta fácilmente trasladable a un usuario de Claude Code.
Una configuración puede haber empezado con diez instrucciones y terminar meses después con cientos de líneas. Cada problema encontrado añade una nueva regla y cada nuevo flujo de trabajo puede acabar convertido en otro skill.
El resultado es una especie de sedimentación de instrucciones.
Cherny propone romper ese ciclo aproximadamente cada seis meses: probar Claude Code sin CLAUDE.md, skills y hooks y observar qué ocurre. Con Opus 5, su recomendación es todavía más clara: experimentar eliminando configuraciones antiguas porque muchas podrían haberse quedado obsoletas.
Eso no equivale a recomendar borrar definitivamente toda la configuración de producción sin comprobar sus consecuencias. La propia explicación de Anthropic gira alrededor de experimentar, medir y recuperar aquello que demuestre seguir siendo necesario.
Cuando explicar demasiado puede limitar al agente
Detrás de esta limpieza aparece otra idea relevante para el uso de los agentes modernos.
Durante años, utilizar bien un modelo implicaba describir cuidadosamente cómo debía realizar una tarea. Era habitual escribir instrucciones del tipo: primero analiza los archivos, después modifica determinada función, a continuación ejecuta las pruebas y finalmente revisa los resultados.
Los modelos actuales pueden necesitar menos dirección de ese tipo.
Cherny identifica como un error habitual dar instrucciones excesivamente específicas sobre el procedimiento. En lugar de describir cada paso, propone trabajar a un nivel superior.
El esquema puede reducirse a tres elementos:
| Elemento | Qué debe indicar |
|---|---|
| Tarea | Qué resultado se quiere conseguir |
| Guardrails | Qué límites no debe superar el agente |
| Criterio de término | Cómo puede comprobar que el trabajo está realmente terminado |
La diferencia parece pequeña, pero modifica la autonomía que recibe el modelo.
Un paso determina cómo debe avanzar. Un guardrail establece dónde no puede entrar.
Por ejemplo, decir «abre este archivo, modifica primero esta función y después cambia esta otra» impone un procedimiento. Decir «corrige el problema sin modificar la base de datos y todas las pruebas deben pasar» establece restricciones y un resultado verificable, pero permite que Claude decida cómo llegar hasta él.
Cherny relaciona la sobreespecificación con un concepto que denomina «hobbling», una referencia a limitar deliberadamente el movimiento de un caballo.
Aplicado a un agente, ocurre cuando el usuario impone un método tan detallado que termina restringiendo otras soluciones que el modelo podría haber encontrado.
Eso tampoco convierte automáticamente las instrucciones detalladas en malas prácticas. Hay procesos donde el procedimiento forma parte del requisito: operaciones reguladas, políticas internas, convenciones arquitectónicas, despliegues delicados o tareas que deben realizarse de una forma determinada.
La diferencia está entre una restricción necesaria y una instrucción heredada de una limitación que ya no existe.
Los skills siguen teniendo sentido, pero para tareas concretas
El mensaje tampoco supone el final de los skills de Claude Code.
El material compartido propone una regla práctica denominada las 3R para decidir cuáles conservar: repetible, requisito y repartible. Esta clasificación procede del autor del análisis y no es una metodología oficial de Anthropic.
Una tarea repetible puede justificar un skill cuando debe ejecutarse de la misma manera de forma frecuente. Un requisito corresponde a información que el modelo no puede deducir por sí mismo, como convenciones internas, estructura de carpetas, determinadas políticas o reglas de una marca. Y un proceso repartible tiene sentido cuando debe poder utilizarlo de forma consistente otro miembro del equipo.
En estos casos, un skill se parece más a un procedimiento operativo estandarizado (SOP) que a una colección de trucos para conseguir que el modelo razone de determinada manera.
La distinción resulta importante.
Un skill que establece cómo generar siempre una factura corporativa puede tener valor porque el resultado necesita ajustarse a unas reglas. Otro que explica a Claude, paso por paso, cómo investigar un error de programación puede quedarse anticuado rápidamente si el nuevo modelo encuentra mejores estrategias.
También explica por qué descargar grandes colecciones de skills creados por terceros puede ofrecer menos ventajas de las esperadas.
Una skill puede estar perfectamente escrita y, aun así, resolver el proceso de otra persona. Cuanto más específico sea ese procedimiento, mayor es la posibilidad de introducir instrucciones que no encajan con el proyecto donde se instalan.
Claude Code apuesta por agentes que verifican su propio trabajo
La evolución de Claude Code va además en la misma dirección.
Anthropic presentó en mayo los dynamic workflows, una función diseñada para dividir problemas complejos entre decenas o cientos de subagentes que trabajan en paralelo. Claude crea dinámicamente la orquestación, reparte las subtareas y comprueba los resultados antes de integrarlos.
La compañía plantea estos workflows para trabajos demasiado grandes para una única ejecución: migraciones extensas, búsquedas de errores sobre grandes repositorios, auditorías o cambios que afectan a cientos de archivos.
Aquí la habilidad del usuario cambia.
En lugar de describir exactamente cómo debe programarse cada componente, cobra más importancia plantear correctamente el problema y proporcionar mecanismos que permitan al agente verificar su propio trabajo.
Cherny pone precisamente el foco en la verificación como una de las piezas que los usuarios todavía pueden mejorar.
Un agente al que simplemente se pide «migra esta aplicación» tiene dificultades para saber cuándo ha terminado realmente. Si dispone de pruebas, capturas de referencia, métricas de rendimiento o cualquier otro resultado comprobable, puede iterar sobre su propio trabajo.
Eso permite ejecutar tareas mucho más largas sin convertir el prompt inicial en un manual de cientos de líneas.
Claude Code está pasando así de un modelo donde el desarrollador dirige continuamente el procedimiento a otro en el que define el problema, establece límites, proporciona herramientas de comprobación y deja más libertad al agente.
Los skills, CLAUDE.md y hooks no desaparecen con ese cambio. Lo que pierde valor es acumular instrucciones por defecto y asumir que cada nueva regla mejora necesariamente el resultado.
La recomendación de borrar cada seis meses debe entenderse precisamente como una prueba de mantenimiento: retirar temporalmente las ayudas creadas para modelos anteriores y comprobar cuáles siguen siendo necesarias.
Si Claude falla sin una determinada instrucción, existe una razón para recuperarla. Si obtiene el mismo resultado o uno mejor sin ella, esa línea probablemente estaba solucionando un problema que el modelo ya había dejado atrás.
Preguntas frecuentes
¿Anthropic recomienda borrar el archivo CLAUDE.md?
Boris Cherny recomienda probar periódicamente Claude Code sin CLAUDE.md, skills y hooks para comprobar qué instrucciones continúan siendo necesarias. La propuesta consiste en experimentar y medir, no en eliminar indiscriminadamente requisitos importantes de un proyecto.
¿Por qué Anthropic eliminó el 80 % del system prompt de Claude Code?
Según Cherny, muchas instrucciones corregían comportamientos que modelos anteriores no resolvían adecuadamente. Con Opus 5, el equipo comprobó que gran parte de esas correcciones ya no eran necesarias.
¿Han dejado de ser útiles los skills de Claude Code?
No. Siguen siendo especialmente útiles para procesos repetibles, requisitos específicos y procedimientos que deben compartirse o ejecutarse de forma consistente. Lo que se cuestiona es mantener instrucciones que determinan innecesariamente cómo debe razonar el modelo.
¿Qué son los dynamic workflows de Claude Code?
Son workflows en los que Claude divide automáticamente una tarea compleja en subtareas y las distribuye entre múltiples subagentes en paralelo. Los resultados pueden verificarse e integrarse antes de presentar el trabajo final.
