Anthropic borró el 80 % de sus propias instrucciones y te dice que hagas lo mismo
Charlie Hills cuenta que se sentó a borrar su configuración entera de Claude —el archivo de instrucciones, los hooks, las skills, seis meses de reglas escritas de una en una— porque se lo dijo el hombre que construyó Claude Code.
- Boris Cherny, en el escenario de Y Combinator: «We deleted 80% of the system prompt» — el prompt que va dentro del producto, recortado a una quinta parte para Opus 5 y Fable 5. Y el modelo, según él, mejoró. (según Charlie Hills, 9-ago · sin verificar)
- Su consejo al usuario que no fabrica productos agénticos: cada seis meses, borra tu archivo de instrucciones, tus skills y tus hooks, y mira qué hace el modelo sin ellos. (Cherny citado por Charlie Hills · sin verificar)
- La documentación de Anthropic, según el autor, publica un techo que casi nadie conoce: apuntar a menos de 200 líneas por archivo de instrucciones, porque los archivos largos consumen más contexto y reducen el seguimiento de las reglas. El suyo iba por 305. (citado por Charlie Hills · sin verificar)
- Y la parte incómoda: esas reglas no son configuración, son contexto. Si dos se contradicen, el modelo puede elegir una de forma arbitraria — y no te dice cuál. (documentación de Anthropic citada por Charlie Hills · sin verificar)
- Debajo hay un efecto conocido —«Lost in the Middle»—: los modelos leen con atención el principio y el final de un contexto largo, y ojean el medio. Cuanto más largo el archivo de reglas, más lejos queda del borde que el modelo lee bien lo que de verdad has pedido. (según Charlie Hills · sin verificar)
- Sus propios números tras auditarse: 195 skills instaladas, 65 invocadas alguna vez. Y 15.109 prompts escritos en 45 días. (Charlie Hills, sobre su propia máquina)
Ángulos
- Charlie Hills — no acaba borrando: acaba manteniendo. Su tesis es que el archivo principal no debe guardar el conocimiento, sino apuntar a dónde está, y que algo automático haga el apuntado.
- El sesgo a vigilar — quien lo dice fabrica el modelo. Que el producto luzca mejor sin muletas del usuario es exactamente lo que le conviene contar. No lo invalida; obliga a comprobarlo en casa antes de repetirlo.
Por qué es importante para ti
Esto parece de técnicos y no lo es. En cuanto una empresa pasa del «pruébalo a ver» a tener asistentes con reglas propias —tono, políticas, qué no puede decir, a qué documentos mira—, alguien empieza a escribir un archivo de normas que crece cada vez que algo sale mal y no se revisa nunca. Es el equivalente digital del manual de calidad que nadie ha vuelto a abrir desde la última auditoría.
Lo que cambia hoy es que el fabricante dice que ese archivo, pasado cierto tamaño, empeora el resultado en vez de mejorarlo, y que las reglas contradictorias se resuelven en secreto. Traducido a lo que un consejo tiene que decidir: quien gobierna la IA en tu casa necesita una fecha de caducidad para sus propias normas y un responsable de podarlas. La pregunta para la próxima reunión no es «¿qué más le decimos a la IA?», sino «¿cuándo fue la última vez que quitamos algo?».
Y hay un segundo filo, el de coste: cada línea de ese archivo se paga en cada conversación, todo el año, la use o no.
Esto te toca a ti, no solo a tu lector
Tu propio sistema es exactamente el caso descrito: un archivo de instrucciones de varios cientos de líneas, 37 skills registradas y reglas añadidas cada vez que algo falló. La categoría del radar que más valor tiene es «cambios que invalidan algo que sostengo», y esta entra por ahí. Auditar tu OS delante del lector, con los números reales, es una pieza que casi nadie puede escribir — y el ángulo, como siempre, es tuyo: si tras auditarlo resulta que la acumulación sí te servía, esa contradicción vale más que la obediencia.