🧠 El overplanning: cuando el modelo piensa demasiado
🧠 Imagínalo así: un pasante brillante, cuando tiene más tiempo y autonomía, a veces usa ese tiempo para investigar contexto que nadie pidió, revisar decisiones ya tomadas o «solo confirmar» algo obvio otra vez. El sobreplanificación en Fable 5 es esa misma tendencia — y aparece precisamente porque el modelo es demasiado capaz para «desactivar» el razonamiento pronto.
Claude Fable 5 tiene mucha más capacidad de razonamiento que los modelos anteriores: puede mantener una instrucción durante días, revisar sistemas enteros y cruzar decenas de archivos antes de cambiar una línea. Esa misma capacidad, aplicada a una tarea de rutinaria, se convierte en un desperdicio: el modelo investiga más de lo necesario, evalúa alternativas que no importan y tarda en empezar a actuar de verdad.
Esto no es un defecto oculto: es un efecto secundario directo del effort alto, que es el valor predeterminado. Con un esfuerzo alto, el comportamiento adecuado para un problema difícil se vuelve excesivo en una tarea sencilla, y Fable 5 funciona con esfuerzo alto de forma predeterminada.
📚 Cita oficial — doc "Prompting Claude Fable 5"
Sobre por qué esto ocurre precisamente en el trabajo rutinario con un nivel de esfuerzo alto:
"On routine work at higher effort, Claude Fable 5 can gather context and deliberate beyond what the task needs..."
En una frase: cuanto más potente es el modelo, más necesita instrucciones explícitas para saber cuándo dejar de pensar y empezar a actuar.
🟢 El prompt oficial anti-overplanning: «Déjalo actuar»
🎯 La idea central
El antídoto contra el overplanning no es pedir «sé más rápido» (demasiado vago para que el modelo actúe en consecuencia), sino decir exactamente cuándo es obligatorio parar. Todo lo que no cumpla este criterio, Fable 5 debe hacerlo directamente, sin pausas.
- •Acción destructiva o irreversible → detente y pregunta
- •Cambio real de alcance → detente y pregunta
- •Información que solo tiene el usuario → detente y pregunta
- •Cualquier otra cosa → actúa y termina el turno con trabajo, no con una promesa
Fíjate en lo que el prompt oficial NO hace: no enumera comportamientos ("no preguntes antes de leer un archivo", "no preguntes antes de ejecutar una prueba"...). Da un criterio — algo destructivo/irreversible, un cambio real de alcance o un dato que solo sabe el usuario — y deja que el modelo aplique ese criterio en cualquier situación nueva. Es la misma lógica de "explica el porqué" (módulo 1.2), pero hacia adentro: el "porqué" de cuándo detenerse.
Objetivo: dejar de esperar aprobación para cada microdecisión reversible (leer un archivo, ejecutar una prueba, crear una branch, refactorizar dentro del alcance solicitado) y reservar la pausa solo para cuando sea realmente necesaria.
Pause for the user only when the work genuinely requires them: a destructive or irreversible action, a real scope change, or input that only they can provide. If you hit one of these, ask and end the turn, rather than ending on a promise.
Pausa y pregunta al usuario solo cuando el trabajo realmente lo requiera: una acción destructiva o irreversible, un cambio real de alcance o información que solo él puede proporcionar. Si encuentras uno de estos casos, pregunta y termina el turno, en vez de terminar con una promesa.
Cómo comprobar: pega la versión en inglés (la oficial) en el CLAUDE.md o en el system prompt del proyecto. En las próximas sesiones, observa si Fable 5 ejecuta directamente los pasos reversibles (leer, probar, crear una branch) y si SOLO se detiene cuando la acción es realmente destructiva o irreversible, cambia el alcance o depende de algo que solo tú sabes. Si deja de preguntar "¿puedo continuar?" en medio de tareas rutinarias, el prompt está funcionando.
✓ Qué HACER
- ✓Dejar que el modelo termine el turno con un resultado real (archivo modificado, prueba ejecutada)
- ✓Confiar en acciones reversibles (lectura, prueba, rama, lint)
- ✓Reservar la pausa solo para lo destructivo, irreversible, fuera de alcance o que requiera una decisión del usuario
✗ Qué EVITAR
- ✗Pedir confirmación para cada lectura de archivo o ejecución de prueba
- ✗Terminar el turno con una promesa ("voy a hacer X ahora") en lugar de con un resultado
- ✗Tratar todo cambio como si fuera irreversible "por precaución"
En una frase: haz una pausa solo cuando la acción sea destructiva, cambie el alcance o dependa del usuario; lo demás, hazlo.
🗺️ Plan mode: cuándo sigue siendo útil
🧠 Imagínalo así: plan mode es el agente que se detiene a dibujar el mapa antes de avanzar. Tiene sentido en territorio desconocido. Es una pérdida de tiempo cuando el camino ya es obvio, y el tema 2 ya resuelve lo «obvio» sin necesidad de mapa.
El error común es tratar el plan mode como un hábito predeterminado: abrirlo para toda tarea «por si acaso». Esto vuelve a introducir exactamente el problema del tema 1: el modelo delibera antes de actuar, incluso cuando la tarea ya estaba lo suficientemente clara como para simplemente hacerla.
La prueba práctica es sencilla: la tarea es genuinamente ambigua (hay varios caminos razonables, no se puede saber cuál elegir sin decidir antes), es grande (afecta decenas de archivos, cambia la arquitectura) o puede cambiar el rumbo del proyecto? Si sí, el plan mode justifica el costo de la pausa. Si no —como ocurre con la mayoría de las tareas cotidianas—, dejarlo actuar (tema 2) ya es la respuesta correcta.
Mira el rombo: es la única prueba que importa. Si la respuesta es "no" —el caso más común—, Fable 5 debe pasar directamente a la acción, sin abrir el plan mode por costumbre.
✅ Vale la pena usar el modo plan
- ✓Tarea realmente ambigua: hay más de un camino razonable y hace falta decidir antes de tocar el código
- ✓Cambio grande: decenas de archivos, migración, cambio de arquitectura
- ✓Decisión que es costosa de revertir si resulta equivocada
⏸️ Solo estorba
- ✗Corrección puntual de un bug, ajuste de estilo, tarea con un camino obvio
- ✗Cualquier cosa que el tema 2 («deja que actúe») ya cubra por sí solo
- ✗Usar el plan mode «por costumbre», sin comprobar si la tarea realmente lo requiere
Observación de quien usa esto todos los días: no es solo teoría de curso: varios creadores de contenido que prueban agentes de IA como parte de su trabajo cuentan el mismo ajuste: dejaron de abrir el plan mode por costumbre y empezaron a reservarlo solo para tareas realmente grandes o ambiguas. El resto del tiempo (la mayoría de las veces), «deja que actúe» ya es suficiente.
🔍 El problema de confiar ciegamente
🧠 Imagínalo así: no confías en un colega nuevo solo porque dijo «terminé»; confías después de ver la solicitud de extracción, ejecutar la prueba y revisar el resultado. Con un agente es igual: «terminé» es una afirmación, no un hecho. El hecho es la evidencia que la respalda.
Dejar que el modelo actúe sin detenerse en cada paso (tema 2) solo es seguro si al final hay una prueba real. Sin eso, "déjalo actuar" se convierte en "confía ciegamente"; y entonces el riesgo pasa a ser lo contrario de lo que querías: menos pausas, pero ninguna garantía de que el trabajo reportado sea real.
El informe de «terminé» puede ser correcto, puede ser optimista o puede ser inventado sin intención: el modelo generaliza a partir de lo que «debería» haber ocurrido, no de lo que realmente ocurrió en la herramienta. La única forma de saber la diferencia es auditar la afirmación con evidencia concreta de esta sesión: el resultado de una prueba, un diff, un log.
Delegar la tarea
Tú lo pides, el agente lo ejecuta sin parar (tema 2).
En este punto aún no sabes si el trabajo se hizo bien; solo sabes que se ejecutó.
El agente dice «terminé»
Un informe final, en texto, optimista por naturaleza.
Es una afirmación; todavía no demuestra nada.
Sin verificar, ¿ya confiarías?
Con un colega humano nuevo, la respuesta sería no.
Con un agente, el instinto es confiar demasiado rápido: justo el punto ciego que este tema aborda.
Confianza real = evidencia comprobada
El tema 5 resuelve esto con un prompt oficial.
Solo después de ver que la prueba pasó, que el diff es correcto y que el registro está limpio, la afirmación "terminé" se convierte en un hecho.
💡 Consejo práctico
Antes de aceptar cualquier «terminé», pregunta: «señala la evidencia exacta de esta sesión que lo confirma» (un resultado de prueba, un diff, un log). Si el agente no puede señalar nada concreto, es señal de que el trabajo aún no está verificado, aunque en el texto parezca listo.
📋 El prompt oficial de verificación: "Demuestra que terminó"
Este es el segundo prompt oficial del dúo de este módulo, y cierra el ciclo que abrió el tema 4. En vez de pedir «sé honesto» (algo vago; el modelo ya «cree» que está siendo honesto), el prompt define un procedimiento de auditoría: cada afirmación de progreso debe señalar un resultado real de esta sesión antes de reportarse.
Objetivo: eliminar los informes de estado inventados — hacer que el agente reporte solo lo que puede demostrar con un resultado real de una herramienta y admita explícitamente lo que todavía no se verificó.
Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.
Antes de reportar progresso, audite cada alegação contra um resultado de ferramenta desta sessão. Só reporte o trabalho que você consegue apontar evidência; se algo ainda não foi verificado, diga isso explicitamente. Reporte os resultados com fidelidade: se os testes falharem, diga isso com a saída; se uma etapa foi pulada, diga que foi; quando algo estiver pronto e verificado, afirme isso claramente, sem hesitar.
Cómo comprobar: pega la versión en inglés (la oficial) en el CLAUDE.md o en el system prompt, junto con el prompt del tema 2. Pide una tarea con pasos verificables (ejecutar la suite de pruebas, aplicar un diff) y observa el informe final: debe indicar el resultado exacto (p. ej., "5 de 5 pruebas pasaron, salida: ...") en vez de decir "todo funciona" de forma genérica, y debe reconocer explícitamente cualquier parte no verificada, en lugar de omitirla.
📊 Resultado empírico (Anthropic)
La propia Anthropic probó este prompt en tareas diseñadas expresamente para inducir informes fabricados:
"In Anthropic's testing, this nearly eliminated fabricated status reports even on tasks designed to elicit them."
Sigue la flecha punteada en cian que vuelve de «Informe» a «Actuar»: ese es el ciclo que se repite. Ningún paso salta directamente de «Actuar» a «Informe» sin pasar por la auditoría frente al resultado de la herramienta.
🛡️ La verificación por subagent supera la autocrítica
🧠 Imagínalo así: pedirle al mismo agente que escribió el código que también lo revise es como pedirle al autor de un texto que sea su único revisor: ya decidió que está bien y tiende a confirmar sus propias decisiones. Un subagent con contexto actualizado no tiene ese sesgo: solo ve la especificación y la evidencia, no la narrativa de quien hizo el trabajo.
En tareas largas, revisar el propio trabajo a cada paso es costoso, pero no revisarlo nunca permite que los errores se acumulen hasta el final, cuando corregirlos ya cuesta más. La solución oficial es combinar ambas cosas: un ritmo de verificación definido de antemano y delegado a un subagent independiente.
Objetivo: establecer un punto de control de verificación periódica en tareas largas, a cargo de un subagente con contexto fresco en lugar de la autoevaluación del propio agente que construyó la solución.
Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification.
Establece un método para revisar tu propio trabajo a intervalos de [X] mientras construyes. Ejecútalo cada [intervalo X] y verifica tu trabajo con subagents frente a la especificación.
Cómo comprobar: reemplaza [X] (en la versión en inglés, la que debe ir en tu prompt) por un intervalo concreto de tu contexto (por ejemplo, "cada 3 archivos modificados" o "cada 20 minutos de trabajo agéntico") y pégala en el system prompt de una tarea larga. Confirma que, en ese intervalo, el agente realmente inicia un subagent verificador independiente —y no solo se reafirma que "todo está bien"— y que ese subagent cita la especificación original al señalar discrepancias.
📚 Por qué gana el verificador externo
Cita oficial (doc "Prompting Claude Fable 5"):
"Separate, fresh-context verifier subagents tend to outperform self-critique."
La razón es estructural; no se trata de que el modelo "sea más riguroso": quien escribió la solución lleva en su propio contexto todo el razonamiento que condujo a las decisiones tomadas y tiende a reafirmarlas en vez de cuestionarlas. Un subagent que nunca ha visto ese razonamiento, sino solo la especificación y la evidencia, no hereda ese sesgo de confirmación.
⚠️ El riesgo de saltarse este paso
Sin un verificador de contexto reciente, dependes solo de la autoevaluación del mismo agente que hizo el trabajo: como poner al zorro a cuidar el gallinero. Combinado con el tema 2 («deja que actúe»), esto puede acumular decisiones erróneas durante muchos pasos antes de que alguien se dé cuenta. El punto de control con un subagent es lo que permite que Fable 5 trabaje durante largos períodos sin supervisión constante.
En una frase: define un intervalo de revisión y asígnaselo a un subagent nuevo: por naturaleza, desconfía; el autor original no.
🧾 Resumen del Módulo
Próximo módulo:
1.5 — Di menos, no más: por qué las instrucciones concisas guían mejor a Fable 5 que las listas exhaustivas de comportamiento.