Capital de Tokens
Borra tus Skills: por qué Claude Code recomienda empezar de nuevo
Durante los últimos años hemos aprendido una regla aparentemente obvia para trabajar con agentes de IA: si una instrucción mejora el resultado, guárdala.
Primero añadimos un CLAUDE.md. Después un Skill. Luego un hook. Más tarde otra regla para corregir un comportamiento extraño. Y, sin darnos cuenta, terminamos construyendo una capa enorme de instrucciones alrededor del modelo.
El problema es que esa capa puede sobrevivir mucho más tiempo que el defecto que intentaba corregir.
Boris Cherny, creador de Claude Code, contó recientemente que el equipo de Anthropic eliminó más del 80% del system prompt de Claude Code al trabajar con una nueva generación del modelo. Su explicación es sencilla: muchas instrucciones existían para compensar limitaciones que el modelo nuevo ya no tenía.
Y de ahí sale una recomendación bastante radical:
cada cierto tiempo, borra
CLAUDE.md, tus Skills y tus hooks, y observa qué ocurre.
No porque las Skills sean inútiles. Todo lo contrario. La idea es descubrir cuáles siguen aportando valor y cuáles se convirtieron en deuda histórica.
Las instrucciones también envejecen
En software estamos acostumbrados a pensar en deuda técnica. Una solución temporal puede quedarse durante años aunque el problema original haya desaparecido.
Con agentes ocurre algo parecido.
Imagina que un modelo de hace seis meses tenía dificultad para revisar sus propios cambios. Podríamos añadir una regla como esta:
Después de modificar cualquier archivo:
1. vuelve a leer todo el diff;
2. busca errores;
3. ejecuta los tests;
4. revisa los logs;
5. corrige cualquier problema;
6. repite el proceso.En ese momento quizá mejora mucho el resultado.
Pero llega una nueva generación del modelo que ya tiende a verificar su trabajo de forma natural. La instrucción permanece y ahora el agente consume tokens, tiempo y atención siguiendo un procedimiento que quizá ya no necesita.
Lo que antes era una mejora se convierte en una restricción.
Podemos pensar en cada regla como una pequeña deuda:
beneficio de la instrucción
-
costo de contexto
-
costo de rigidez
-
costo de mantenimiento
=
valor realSi el beneficio desaparece, la instrucción deja de ser un activo.
El método: ablation testing para prompts
La forma en que el equipo de Claude Code evalúa estas instrucciones se parece a una técnica clásica de machine learning: ablation testing.
En vez de asumir que cada componente es necesario, lo eliminas y observas cuánto empeora el sistema.
Aplicado a un agente:
configuración actual
↓
quitar instrucciones
↓
ejecutar tareas reales
↓
comparar resultados
↓
reintroducir solamente lo que demuestra valorBoris describe una estrategia todavía más agresiva: empezar prácticamente desde cero y reconstruir el prompt a partir de los fallos que realmente aparecen.
Eso cambia completamente la mentalidad.
La pregunta deja de ser:
¿Qué otras instrucciones puedo añadir para mejorar al agente?
Y pasa a ser:
¿Cuál es la cantidad mínima de instrucciones necesaria para obtener el comportamiento que quiero?
No añadas una regla por cada error
Este punto es especialmente importante.
Un agente falla una vez y nuestra reacción natural es añadir inmediatamente una regla permanente.
Por ejemplo:
Nunca olvides actualizar README.md cuando cambies una opción de configuración.Pero quizá ese fallo fue circunstancial.
Si añadimos una regla cada vez que aparece un error aislado, el archivo de instrucciones crece sin límite.
La estrategia propuesta por Cherny es observar fallos repetidos.
El ciclo sería:
el agente falla
↓
¿fue un caso aislado?
↓
seguir observando
↓
¿el mismo patrón vuelve a aparecer?
↓
añadir una reglaLa regla entra al sistema porque existe evidencia de que hace falta, no simplemente porque podemos imaginar que podría ser útil.
Esto convierte el mantenimiento de prompts en una disciplina empírica.
El problema del hobbling
Cherny utiliza otra idea interesante: hobbling.
Un modelo puede ser más capaz de lo que parece, pero el harness que lo rodea puede limitarlo.
Un ejemplo típico es el prompt excesivamente específico.
En lugar de decir:
Implementa esta funcionalidad.
Estos son los invariantes que no puedes romper.
Ejecuta los tests y verifica el resultado.le damos veinte pasos:
abre este archivo
busca esta función
crea esta clase
usa exactamente este patrón
llama primero a esta función
luego modifica este archivo
no cambies nada más
...Paradójicamente, cuanto mejor se vuelve el modelo, mayor puede ser el costo de ese micromanagement.
El agente quizá podría encontrar una solución mejor, pero nosotros le hemos reducido el espacio de búsqueda a una receta escrita para una generación anterior.
Task + guardrails + verification
Una de las consecuencias más útiles de esta filosofía es que el prompt puede hacerse mucho más pequeño.
En lugar de describir exhaustivamente cómo hacer el trabajo, podemos concentrarnos en tres cosas:
TASK
¿Qué resultado queremos?
GUARDRAILS
¿Qué reglas no pueden romperse?
VERIFICATION
¿Cómo puede comprobar el agente que terminó correctamente?La tercera parte es especialmente importante.
Cherny describe proyectos de larga duración donde el prompt inicial era sorprendentemente corto. La sofisticación no estaba en la redacción del prompt, sino en darle al agente una forma objetiva de comprobar su propio trabajo.
Uno de los ejemplos fue una reescritura de una aplicación Electron en Swift. El agente podía ejecutar ambas versiones, tomar capturas y comparar visualmente los resultados.
El loop conceptual era:
implementar
↓
ejecutar
↓
comparar
↓
detectar diferencias
↓
corregir
↓
repetirEl prompt no necesitaba anticipar cada decisión técnica porque el agente tenía un feedback loop.
Esa idea probablemente sea más importante que cualquier técnica concreta de prompt engineering.
Verification loops > prompts gigantes
Cuando un agente puede medir su propio progreso, podemos delegarle mucha más libertad.
En desarrollo de software, ejemplos de verification loops son:
- ejecutar tests;
- compilar el proyecto;
- ejecutar linters y type checking;
- comparar screenshots;
- lanzar tests end-to-end;
- consultar métricas;
- inspeccionar logs;
- validar contratos JSON;
- probar endpoints;
- comparar resultados contra fixtures conocidos.
En otras palabras:
menos instrucciones sobre cómo pensar
+
más mecanismos para comprobar la realidadEse patrón es extremadamente potente.
Entonces, ¿hay que borrar todas las Skills?
No.
El título funciona porque resulta provocador, pero interpretar literalmente la recomendación sería perder el punto.
Una Skill sigue siendo excelente cuando contiene conocimiento que el modelo no puede inferir simplemente por ser más inteligente.
Por ejemplo:
Convenciones específicas de un proyecto
Los migrations nunca se ejecutan automáticamente en producción.Reglas de negocio
Una factura pagada no puede volver al estado draft.Herramientas internas
Para desplegar este servicio usa el workflow deploy-oracle.yml.Procedimientos repetibles
Para publicar un episodio:
- valida metadata;
- genera assets;
- ejecuta el pipeline;
- verifica publicación;Restricciones de seguridad
Nunca imprimas secretos ni tokens en logs.Estas instrucciones no existen porque el modelo sea torpe. Existen porque representan conocimiento externo al modelo.
Ese es un criterio mucho más duradero.
Las tres preguntas que debería superar una Skill
Una forma práctica de auditar una Skill es preguntarse:
1. ¿Es repetible?
¿Este procedimiento ocurre regularmente?
Si solamente lo hicimos una vez, quizá no merece convertirse en infraestructura permanente.
2. ¿Contiene conocimiento requerido?
¿Existe información que el modelo no tendría forma razonable de conocer?
Por ejemplo, reglas internas, convenciones, APIs privadas o restricciones del proyecto.
3. ¿Vale la pena distribuirla?
¿Queremos que este procedimiento pueda utilizarse en múltiples sesiones, repositorios, agentes o equipos?
Si la respuesta a las tres preguntas es no, probablemente estamos guardando ruido.
AGENTS.md también debería adelgazar
Esta filosofía no aplica únicamente a Claude Code.
El mismo problema aparece con archivos como:
AGENTS.md;CLAUDE.md;.cursorrules;- prompts de sistema personalizados;
- instrucciones de Copilot;
- Skills;
- subagents;
- hooks;
- playbooks internos.
Un buen AGENTS.md debería parecerse más a una colección de invariantes y mecanismos de verificación que a un tutorial de pensamiento paso por paso.
Por ejemplo, esto probablemente merece quedarse:
- CI debe quedar verde.
- El proyecto soporta i18n.
- No hagas merge si los checks obligatorios fallan.
- Ejecuta pytest para validar cambios de backend.Mientras que instrucciones de este estilo deberían revisarse con frecuencia:
1. primero analiza A;
2. después abre B;
3. luego crea C;
4. después consulta D;
5. finalmente vuelve a A.Quizá el agente ya puede decidir ese procedimiento por sí mismo.
La arquitectura empieza a importar más que el prompt
Todo esto apunta a una transición mayor.
Durante la primera etapa de los LLM hablábamos constantemente de prompt engineering.
Después empezamos a hablar de context engineering.
Ahora, con agentes capaces de trabajar durante periodos largos, cada vez resulta más importante algo diferente: harness engineering.
El valor está en construir el entorno donde el agente puede trabajar correctamente:
modelo
+
tools
+
permisos
+
contexto
+
feedback loops
+
evals
+
observabilidad
+
exit criteriaUna gran instrucción puede ayudar.
Pero un agente que puede ejecutar, observar, medir y corregir su propio trabajo tiene una ventaja mucho mayor.
Un mantenimiento que deberíamos hacer periódicamente
La recomendación de borrar Skills puede convertirse en una práctica concreta de ingeniería.
Cada vez que cambia significativamente el modelo:
1. guarda la configuración actual;
2. ejecuta un conjunto de tareas representativas;
3. elimina temporalmente instrucciones, Skills y hooks no esenciales;
4. repite las mismas tareas;
5. compara calidad, costo y tiempo;
6. registra los fallos repetidos;
7. reintroduce únicamente las reglas que resuelven problemas observables.No hace falta borrar nada de Git permanentemente. Una rama, un commit o un simple git stash permiten experimentar sin riesgo.
Lo importante es que las instrucciones tengan que demostrar que merecen seguir existiendo.
La paradoja de los agentes más inteligentes
Hay una paradoja interesante aquí.
Cuanto más capaces son los modelos, menos instrucciones pueden necesitar.
Pero al mismo tiempo, cuanto más trabajo les delegamos, más importante se vuelve proporcionarles:
- objetivos claros;
- restricciones reales;
- herramientas adecuadas;
- acceso al entorno;
- mecanismos de verificación;
- límites de seguridad.
La ingeniería no desaparece.
Simplemente se mueve desde describir cada paso hacia diseñar el sistema donde el agente puede descubrir los pasos y comprobar si funcionan.
Quizá esa sea la mejor forma de resumir la recomendación de Boris Cherny:
codifica las reglas del mundo y la forma de verificar el resultado; deja que el agente descubra el procedimiento.
Y cada cierto tiempo, borra todo lo demás y comprueba si todavía hacía falta.