En The Thing (1929), G. K. Chesterton plantea el caso de una valla que cruza un camino. Un reformista llega, no le ve utilidad y propone quitarla. Otro, más sensato, le contesta que primero averigüe para qué se puso. Cuando vuelva sabiéndolo, quizá le deje derribarla. Tu CLAUDE.md está lleno de vallas como esa: «no hagas esto sin preguntar», «para si te sales del alcance», «nunca reintentes». Con Claude Fable 5.2, el modelo más capaz de Anthropic, esas vallas frenan más. El modelo las sigue al pie de la letra aunque su motivo ya no exista, y Anthropic avisa de que se nota sobre todo cuando trabajan varios agentes juntos.
Las reglas de un agente son un andamio: se ponen mientras no dominas el flujo de trabajo y, cuando su motivo caduca, se retiran o se reescriben con su alcance y su porqué. Fable 5.2 es solo el caso más reciente de algo general: cada modelo lee las mismas reglas de forma distinta.
Qué dice la guía de Fable 5.2 sobre las cautelas acumuladas
Fable 5.2 obedece tanto las cautelas que acaba pidiendo permisos que no necesita. La guía de prompting de Claude Fable 5.2 lo explica en una sección sobre la cautela que se acumula: las instrucciones prudentes se amontonan, sesión tras sesión, en la memoria, en las notas y en los archivos de instrucciones.
Basta una regla para notarlo. Anthropic puso «enviar mensajes a personas fuera de esta conversación» en la lista de pasos que necesitan aprobación. En tareas simuladas en las que nadie podía aprobar nada, el modelo se guardó cerca de la mitad de sus mensajes rutinarios a compañeros y a otros equipos.
El remedio que propone la guía es borrar las notas caducadas, nombrar los pasos que no necesitan aprobación, acotar las condiciones de parada y escribir las excepciones de las reglas con «nunca». Más abajo están sus ejemplos.
Por qué empiezo un proyecto rodeado de reglas
Cuando arranco un proyecto con un flujo de trabajo que todavía no tengo asimilado, lo rodeo de reglas. No sé aún dónde se va a equivocar el agente ni qué pasos necesito revisar, así que lo controlo todo: que no toque nada sin issue, que presente un plan y espere mi visto bueno, que pare si algo se sale del alcance.
Conforme saco tareas y conozco el flujo, voy retirando las reglas que le quitan autonomía. El objetivo es que el modelo complete el proceso entero, desde el análisis hasta abrir el PR, sin pararse en cada paso.
Las reglas del principio protegen un flujo que aún no entiendes. Lo que falla es no quitarlas cuando ya lo entiendes, y con Fable 5.2 ese olvido frena más.
Cómo decido si una regla se queda, se reescribe o se quita
Antes de tocar una regla le hago las preguntas de Chesterton. Según las respuestas, la regla se queda, se reescribe o se quita.
Los casos de la guía
La guía da cuatro ejemplos que sirven de plantilla:
| Regla | Qué hacer | Por qué |
|---|---|---|
| «No reintentes nunca» | Quitarla | Es una nota antigua de la memoria que el modelo sigue obedeciendo cuando ya no hace falta |
| «Nunca borres archivos» | Reescribirla: «pide aprobación antes de borrar archivos» | Con «nunca» el modelo la trata como absoluta. Así sigues decidiendo tú sin bloquearlo |
| «Para y revisa en el primer error» | Acotarla o quitarla | Una condición de parada así bloquea el trabajo autónomo |
| «Responde directamente, sin deliberar» | Quitarla y bajar el esfuerzo | Fable 5.1 la seguía. En Fable 5.2 no impide que piense a partir del esfuerzo medio |
Mi caso: el CLAUDE.md de Fantasy Copilot
Fantasy Copilot recomienda alineaciones de LaLiga Fantasy a partir de vídeos de YouTube. Su CLAUDE.md no está en el repo, pero estas son sus reglas tal cual. Tiene una docena; estas son las que más enseñan:
| Regla | Qué hago | Por qué |
|---|---|---|
«No se suben claves ni transcripciones en crudo. Los archivos se añaden a git por su nombre, nunca con git add -A» | La mantengo | Una clave subida se queda en el historial. Aquí el «nunca» es intencionado |
| «Si [un test] parece incorrecto, se consulta antes de tocarlo» | La mantengo | Parece una parada que sobra, pero no lo es |
| «Se usa Colima, no Docker Desktop» | La mantengo | Describe el entorno, no es una cautela: no frena nada |
| «Todo cambio de código parte de un issue de GitHub dentro de un milestone. Sin issue no se empieza» | La reescribo | Es absoluta y no dice su porqué |
| «Se crean sin preguntar los issues que merezcan la pena» | Ya está bien | Nombra un paso que no necesita aprobación, como pide la guía |
La regla de los tests es la valla de Chesterton que no hay que derribar. Los tests los escribe otro agente que solo ve el issue, no la implementación:
Si el agente que implementa pudiera cambiar los tests, los adaptaría a su código y dejarían de comprobar nada. Ese peligro sigue existiendo, así que la parada se queda.
La regla del issue sí tiene motivo, pero no lo dice: el issue es lo único que ven el escritor de tests y el revisor. Con el porqué escrito, el modelo puede saber dónde no se aplica:
- Todo cambio de código parte de un issue de GitHub dentro de un milestone, porque el issue es lo único que ven el escritor de tests y el revisor. Corregir una errata en `brain/` o en un comentario no lo necesita.Una regla que caduca: un ejemplo inventado
A Fantasy Copilot le falta el tercer caso: una regla cuyo motivo ya no existe. Este CLAUDE.md es inventado, el de una app con pagos:
- Nunca reintentes una petición a la API de pagos.
- Para y pregunta antes de ejecutar los tests de integración.La primera se escribió porque la API no recibía una clave de idempotencia y un reintento cobraba dos veces. La segunda, porque los tests usaban una base de datos compartida y bloqueaban al resto del equipo. Hoy cada petición lleva su clave y cada rama tiene su propia base. La primera se quita. La segunda se reescribe nombrando el paso que ya no necesita aprobación:
- Ejecuta los tests de integración sin preguntar: cada rama usa su propia base de datos.Una regla de alcance controla menos de lo que parece
Una frase sobre de quién es el código pesa más que una regla que limita lo que el agente puede tocar.
La guía lo comprobó así. Si le dices a Fable 5.2 «eres el dueño de este código y su diseño depende de ti», se toma la libertad de ordenarlo: cuando encuentra código repetido, lo une en una sola función. Lo hizo en unas tres de cada cuatro pruebas. Sin la frase, en menos de una de cada diez.
Una prohibición no lo frena. Con «eres el dueño» y «nada de refactors, renombrados ni limpiezas de paso» en el mismo prompt, siguió ordenando el código en más de la mitad de las pruebas.
Esa libertad tiene un precio: genera entre un 70 % y un 80 % más de texto, hace cambios que nadie pidió y, a veces, cambia cómo funciona algo que ya existía.
Así que primero decide si quieres que el agente trate el código como suyo. En mi portfolio se lo diría, porque prefiero que mejore la estructura y reviso los cambios en el PR. En código de otro que debe cambiar lo mínimo, no escribas esa frase: la regla de alcance sola no la compensa.
Cuándo repetir la revisión
Revisa las reglas cada vez que cambies de modelo. La guía lo pide porque lo que funcionaba con el anterior puede costar más, tener efectos secundarios o no hacer nada. Es el momento de volver a preguntar por cada valla.
No hace falta usar Fable 5.2 para que esto te afecte. En el día a día la mayoría trabajamos con Sonnet u Opus, y las cifras de la guía son de Fable 5.2: no las trasladaría a otro modelo. Lo que sí se traslada es el método. Una regla se escribe para un modelo concreto: «responde directamente, sin deliberar» funcionaba con Fable 5.1 y con Fable 5.2 ya no hace nada. Y si combinas modelos, como uno que planifica y subagentes más baratos que ejecutan, cada uno puede necesitar sus propias reglas.
Las cifras tienen un límite: la guía no publica el tamaño de sus muestras y se ha actualizado desde que salió. Las de este artículo son de la versión del 11 de noviembre de 2026.
Aunque quites reglas, mantén tu propia confirmación en las acciones arriesgadas o irreversibles. Es la valla que la guía nunca te pide derribar.