Guía para trabajar con Fable, el modelo más revolucionario de Claude (con prompts para copiar)

Qué es Fable 5, por qué cambia cómo trabajamos con IA, y las técnicas exactas,con prompts listos, que usa el propio equipo de Claude Code.

Hay charlas técnicas que envejecen en una semana. Y luego hay charlas que, sin proponérselo, describen un cambio de época. La que dio Thariq Shihipar, ingeniero del equipo de Claude Code en Anthropic, en AI Engineer, coincidiendo con el lanzamiento de Fable, es de las segundas.

Su metáfora inicial lo resume todo: hasta ahora estábamos jugando el tutorial de un RPG. Con esta nueva clase de modelos, se abre el mundo abierto. Hay muchísimo más que explorar, pero también es intimidante, porque de repente puedes hacer casi cualquier cosa y nadie te ha dado el mapa.

En esta edición hago tres cosas: te cuento qué es exactamente Fable 5 y por qué su lanzamiento ha sido el más accidentado (y comentado) de la historia de Anthropic; desmenuzo las cuatro ideas de la charla de Shihipar; y te doy la caja de herramientas práctica, con prompts que puedes copiar y pegar hoy, que sale de cruzar la charla con la documentación oficial de Anthropic.

Contexto: qué es Fable 5 (y por qué su lanzamiento ha sido una montaña rusa)

Antes de entrar en la charla, los datos que necesitas para situarte:

Ficha rápida de Claude Fable 5

• Qué es: el primer modelo de la familia Claude 5 y el primero de la nueva clase “Mythos” (un nivel por encima de Opus) que Anthropic pone a disposición del público general. Es su modelo más capaz jamás lanzado de forma general: estado del arte en casi todos los benchmarks, con especial ventaja en tareas largas y complejas — cuanto más larga la tarea, mayor su ventaja sobre modelos anteriores.

• La pareja: existe un gemelo, Claude Mythos 5 — el mismo modelo base, pero con salvaguardas de ciberseguridad levantadas, disponible solo para ciberdefensores e infraestructura crítica aprobados (Project Glasswing, en colaboración con el gobierno de EE.UU.).

• Especificaciones: ventana de contexto de 1 millón de tokens, hasta 128k tokens de salida. Precio API: $10 por millón de tokens de entrada, $50 por millón de salida.

• El culebrón: lanzado el 9 de junio de 2026 → suspendido el 12 de junio por controles de exportación del gobierno de EE.UU. (tras un informe sobre un método de bypass de sus salvaguardas) → redeplegado globalmente el 1 de julio con nuevos clasificadores de seguridad → incluido en los planes de pago (Pro, Max, Team) hasta el 50% del límite semanal hasta el 12 de julio de 2026, fecha tras la cual pasa a créditos de uso hasta que haya capacidad para devolverlo a las suscripciones.

• El dato que lo explica todo: durante las pruebas tempranas, Stripe reportó que Fable 5 comprimió meses de ingeniería en días — una migración completa de una base de código Ruby de 50 millones de líneas en un día, trabajo que a un equipo humano le habría llevado más de dos meses.

Traducción práctica: si tienes un plan de pago de Claude, tienes hasta el 12 de julio para probar el modelo más potente del mundo sin coste marginal. Esta guía existe para que ese tiempo cuente.

Ahora sí: la guía de campo. Cuatro partes.

1. “Unhobbling” Claude: el modelo no es el límite, lo eres tú

La primera idea es casi filosófica: los modelos se cultivan, no se diseñan. En Anthropic no se levantan un día diciendo “necesitamos un 99% en SWE-bench”. Le dan al modelo datos, feedback y cómputo, y el resultado es algo orgánico que ellos mismos tienen que aprender a entender a medida que lo usan.

La consecuencia práctica es demoledora: lo que limita al modelo somos nosotros. El “harness”, las herramientas, el system prompt, la forma de pedirle las cosas, es una función de nuestro entendimiento del modelo. “Unhobbling” (des-cojear, quitarle las trabas) significa entenderlo mejor para liberarlo.

El ejemplo Pokémon

Shihipar lo ilustra con un tuit viral: ¿por qué los LLMs no pueden decir qué Pokémon terminan en “aw”? Hay más de mil Pokémon y solo dos cumplen la condición (Croconaw y Drednaw). Un modelo de chat normal falla, aunque obviamente “conoce” todos los nombres. Pero Claude Code lo resuelve sin despeinarse: descarga la lista completa y escribe un script que filtra por “aw”.

A esto lo llaman capability overhang: capacidad latente que ya existe en el modelo pero que solo aflora cuando le das las herramientas adecuadas. Los modelos no se vuelven más inteligentes de forma lineal, sino “a picos” (spiky). La misma inteligencia, con un entorno distinto, produce resultados radicalmente distintos.

La historia se repite (y acelera)

El patrón ya ha ocurrido varias veces:

Del contexto a los brazos. Con los modelos de chat, la intuición era: “el contexto crecerá hasta que pueda pegar toda mi base de código”. Pero la solución real fue otra: darle brazos al modelo —la terminal, herramientas de búsqueda— para que construya su propio contexto. Ese insight es el que dio origen a Claude Code.

De reactivo a proactivo. El siguiente salto, según Shihipar, es la capacidad del modelo de “despertarse solo” y trabajar de forma proactiva y en multijugador, sin que nadie le dé al prompt. Eso es lo que está desbloqueando la nueva ola de agentes.

El system prompt encoge. Este dato me parece oro puro: Anthropic acaba de eliminar el 80% del system prompt de Claude Code. La evolución de las buenas prácticas cuenta la historia de los modelos:

• Era Sonnet 3.5: system prompt pequeño, pocas herramientas, muchos ejemplos.

• Modelos intermedios: prompts enormes, muchas instrucciones, muchas herramientas, el modelo por fin las seguía.

• Nueva clase (Fable): de vuelta a prompts pequeños. Los ejemplos ahora constriñen al modelo, porque es más imaginativo que los ejemplos que le damos. La regla nueva: dar contexto, no restricciones. Evitar el “no hagas esto” que era imprescindible antes.

De Markdown a HTML. La forma de comunicarse del modelo también evoluciona a saltos: primero Markdown como output enriquecido, luego el “plan mode” para que tú entiendas qué va a hacer, y ahora informes HTML completos e interactivos, con las preguntas del modelo embebidas dentro. Herramientas como ask user question, que con Opus 4 apenas funcionaban, ahora permiten que el modelo te entreviste con 40 preguntas sobre tu spec.

La conclusión de esta primera parte: esto se parece más a la biología que a la física. Es empírico, orgánico, no conocemos todas las reglas — pero hay ciencia y hay intuición que construir. (Shihipar recomienda el paper de Anthropic On the Biology of a Large Language Model, legible para todos los niveles técnicos.)

La documentación oficial le da la razón

Esto no es solo la opinión de un ingeniero en un escenario. La guía oficial de prompting de Fable 5 que Anthropic ha publicado en su documentación confirma el giro, punto por punto. Este es el cambio de paradigma resumido en una tabla:

Fíjate en la línea de “refactoriza o borra”. Es exactamente lo que hizo Anthropic con su propio producto al eliminar el 80% del system prompt de Claude Code. La pregunta incómoda para ti: ¿cuántas de tus instrucciones, GPTs, proyectos y skills están escritas para un modelo que ya no existe? Probablemente tu primera tarea con Fable no sea nueva: es auditar lo viejo.

2. Encuentra tus unknowns: el mapa no es el territorio

Si la primera parte va de quitarle las trabas al modelo, la segunda va de quitárnoslas a nosotros.

La metáfora central: el mapa no es el territorio. Tu prompt, tu plan, tu spec, eso es el mapa. El territorio es la realidad: la base de código, las restricciones del mundo real, el contexto que el modelo tiene que navegar. Cada vez que el modelo se topa con algo del territorio que no está en tu mapa, aparece un unknown: un punto de decisión que tú no especificaste.

Con modelos que recorren áreas enormes de territorio de forma autónoma, esto se convierte en el cuello de botella. En palabras de Shihipar: “Fable está limitado por mi capacidad de hacer coincidir el mapa y el territorio”.

La matriz de los unknowns

Para cualquier problema, propone la clásica matriz:

• Known knowns: lo que sabes y escribes en el prompt.

• Known unknowns: lo que sabes que no sabes todavía.

• Unknown knowns: lo tan obvio que no lo escribirías nunca — pero “lo reconoces cuando lo ves”.

• Unknown unknowns: lo que ni siquiera has considerado. Lo que, si lo supieras, cambiaría cómo prompteas.

La buena noticia: puedes usar el propio modelo para encontrar tus unknowns. Estas son sus seis técnicas, y para cada una te dejo el prompt adaptado, listo para copiar:

1. Blind spot pass (caza tus unknown unknowns)

“Voy a trabajar en [proyecto/área] y hay partes que no domino. Antes de empezar, haz una pasada de puntos ciegos: explora [la base de código / estos documentos / este contexto] y dime qué complicaciones, excepciones y decisiones no obvias debería conocer para promptear mejor. Prioriza lo que cambiaría mi enfoque si lo supiera.”

Sirve para bases de código, pero también para aprender campos enteros — Shihipar lo usó para aprender color grading en edición de vídeo. Su frase: “el modelo sabe más que yo de casi todo; solo tengo que sacárselo”.

2. Brainstorms y prototipos (destapa tus unknown knowns)

“No sé describir con palabras lo que quiero, pero lo reconoceré cuando lo vea. Créame [una página / cuatro versiones de X] con decisiones radicalmente distintas entre sí, para que pueda reaccionar a ellas y afinemos juntos.”

3. Entrevistas (antes de ejecutar, deja que te pregunte)

“Antes de empezar, entrevístame sobre esta spec. Contexto sobre mí: [quién eres, en qué fase estás]. Prioriza las preguntas cuya respuesta cambiaría la arquitectura o el enfoque general.”

4. Referencias (la mejor forma de dar un mapa es dar otro mapa)

En lugar de escribir la spec perfecta, pásale un ejemplo que represente lo que quieres: código en otro lenguaje, un mockup, un documento de otro proyecto, una pieza de la competencia. “Lee esto, entiéndelo, y úsalo como referencia de lo que busco.”

5. Implementation notes (registra las desviaciones)

“Mientras trabajas, registra cada punto donde encuentres algo que no estaba en mis instrucciones y qué decidiste hacer. Al final quiero ver ese log de desviaciones.”

Y de la documentación oficial de Anthropic sale el complemento perfecto para tareas largas — el prompt anti-fabulación de progreso:

“Antes de reportar progreso, contrasta cada afirmación con una evidencia real de esta sesión. Reporta solo trabajo que puedas demostrar; si algo no está verificado, dilo explícitamente. Si algo falló, dilo con el detalle del fallo.”

6. El quiz final (garantiza que sigues entendiendo)

“Hazme un quiz sobre lo que acabamos de construir/decidir. Quiero asegurarme de que puedo explicar y defender este trabajo ante [mi equipo / mi cliente].”

El hilo común de las seis técnicas: mantenerte en el loop. La autonomía del modelo no te exime de entender; te exige entender mejor.

3. El duelo: cómo no reír, pero también cómo no llorar

Esta es la parte más humana de la charla, y la que menos esperaba de un ingeniero presentando un modelo.

Shihipar cuenta que la primera vez que usó un modelo de esta clase sintió a la vez una ganancia enorme y una sensación de pérdida. Dirigió una startup de YC de 30 personas, y recuerda esa época como “un país extranjero”: vivían forzados a elegir trade-offs porque programar era durísimo. ¿Hacemos la app rápida o prototipamos la feature nueva? Un mes o dos meses. Elegir siempre.

Hace unas semanas volvió a esa base de código antigua. Lo que le habría llevado semanas, ahora le llevaba horas. Y su reacción: “¿Cómo no reír? Pero también, ¿cómo no llorar?”

Amaba programar a mano. Amaba ver la base de código en su mente y rotarla. Pero también recuerda las noches en vela depurando, semanas trabajando en cosas que no funcionaban, “nadar en el fracaso”. La mayoría de sus proyectos fracasaron. La mayoría de las startups quiebran.

Su conclusión: “the only way out is through”, la única salida es atravesarlo. No hay vuelta atrás, y la nostalgia no es una estrategia. Pero si nos mantenemos en el loop, si aprendemos a des-cojear estos modelos, salimos al otro lado con muchísimo más.

Este duelo no es exclusivo de los programadores. Lo vivirán los diseñadores, los estrategas, los redactores, los analistas, cada oficio del conocimiento, escalonadamente. Y creo que nombrarlo, como hace Shihipar, es más honesto y más útil que negarlo o que vender solo la parte del entusiasmo.

4. Sé irrazonable: los trade-offs ya no son reales

Y aquí el cierre, que es puro manifiesto.

En Anthropic, cuenta Shihipar, existe la creencia cultural de que los trade-offs no son reales. En su empresa anterior él era “razonable”: lista de prioridades, elegir una para el trimestre, aparcar el resto. Lo sensato.

¿Y si simplemente lo hicieras todo? ¿Y si obligaras a la realidad a enseñarte el trade-off, en lugar de asumirlo de antemano?

La matemática de esta clase de modelos cambia la ecuación. El clásico “bueno, rápido, barato: elige dos” se convierte en “elige tres”. El caso de Stripe que citaba arriba (dos meses de trabajo de un equipo comprimidos en un día) no es una mejora incremental: es una categoría distinta de posibilidad. Y hay decenas de trade-offs que hacemos implícitamente en la cabeza cada día sin cuestionarlos.

Tres ideas finales que me quedo subrayadas:

“La única forma de demostrar que los agentes funcionan es hacer el mejor trabajo de nuestras vidas, más rápido que nunca.” La presentación de la propia charla la hizo con Fable la noche anterior, en cuatro horas, y es una presentación de la que está orgulloso.

Construir es fácil; generar valor sigue siendo difícil. El aviso a navegantes para todos los que nos obsesionamos con el proceso, los setups y las herramientas: el punto es generar valor, y eso requiere muchos intentos. Los agentes te dan más swings — no te garantizan el home run.

Y su resolución personal: ser más productivo, trabajar menos y pasar más tiempo con la gente que le importa. Que quizá sea la métrica definitiva de si todo esto funciona.

Mi lectura desde +MAIN.MIND

Tres traducciones directas de esta charla al mundo de la estrategia y la marca:

1. El capability overhang también existe en tu empresa. La mayoría de organizaciones están usando modelos de mundo abierto con mentalidad de tutorial. La pregunta ya no es “¿qué sabe hacer la IA?” sino “¿qué entorno, herramientas y contexto le estamos dando?”. La ventaja competitiva está en el harness, no en el modelo.

2. Tu documentación de marca es tu mapa. Todo lo que Shihipar dice sobre unknowns aplica letra por letra a la identidad conversacional: si tu marca no tiene el territorio mapeado (esencia, temperamento, habla, operación, sintonía), el agente decidirá por ti en cada unknown. Y decidirá genérico.

3. Menos restricciones, más contexto. El cambio en los system prompts (del “no hagas esto” al contexto rico) es exactamente el cambio que defendemos en cómo se construyen agentes de marca. Las marcas que escriban manuales de prohibiciones tendrán agentes cojos. Las que den contexto y criterio tendrán agentes con carácter.

Aprende a trabajar así: Curso de Claude de +MAIN.Academy

Todo lo que has leído en esta edición es exactamente lo que enseñamos, con casos reales y práctica guiada, en el Curso de Claude de +MAIN.Academy.

No es un curso de trucos de prompts. Es un sistema completo para que tú y tu equipo trabajéis con Claude como lo hace el propio equipo que lo construye: de la configuración inicial a los agentes, pasando por Projects, Skills y flujos de trabajo reales para marketing, estrategia y negocio.