# thariq-field-guide-fable-finding-unknowns-2026-07-03

## Veille

Hilo de X (hilo ilustrado) de **Thariq Shihipar** (equipo de Claude Code / Anthropic): una *guía de campo* para sacar el máximo partido a **Claude Fable 5**. Tesis central tomada de Korzybski — *"el mapa no es el territorio"*: el **mapa** = lo que le das a Claude (prompts, skills, contexto); el **territorio** = donde ocurre el trabajo (base de código, restricciones del mundo real); la brecha entre ambos = las **incógnitas**. Fable es *"el primer modelo en el que la calidad del trabajo está limitada por mi capacidad de aclarar sus incógnitas"*. El artículo ofrece un **marco de 4 cuadrantes** (conocidos-conocidos / conocidos-desconocidos / desconocidos-conocidos / desconocidos-desconocidos) y un **conjunto de técnicas** ordenadas en el tiempo (antes / durante / después de la implementación) — blindspot pass, brainstorms y prototipos, entrevistas, referencias, plan de implementación, implementation-notes, pitches y explainers, quizzes — cada una con prompts de ejemplo. Dominio: prompt engineering, agentes de codificación, metodología de trabajo con IA, artefactos HTML.

## Titre Article

A Field Guide to Fable: Finding Your Unknowns

## Date

2026-07-03

## URL

https://x.com/trq212/status/2073100352921215386

## Keywords

Incógnitas, mapa vs. territorio, conocidos/desconocidos conocidos, desconocidos desconocidos, blindspot pass, brainstorm, prototipo, entrevista, referencias, plan de implementación, implementation-notes.md, pitches y explainers, quizzes, artefactos HTML, Claude Fable 5, Claude Design, compañero de pensamiento, prompt engineering, tareas de largo horizonte, descubrimiento iterativo de incógnitas

## Authors

Thariq Shihipar (@trq212)

## Ton

**Perfil**: guía de campo en primera persona, registro reflexivo y pedagógico de practicante, publicada como un hilo de X ilustrado de formato largo con 4 diagramas. Nivel técnico medio-alto, dirigido a usuarios habituales de agentes de codificación.

**Estilo**: un ensayo construido en torno a una **metáfora cartográfica extendida** tomada de la semántica general ("el mapa no es el territorio") y sostenida hasta la conclusión ("Matching the Map and Territory"). Estructura temporal explícita (antes / durante / después de la implementación) combinada con un marco conceptual tomado de Rumsfeld/Johari (la matriz 2×2 de lo conocido/desconocido). Autoridad mediante **autodemostración encarnada**: Thariq relata cómo editó la **Vidéo de lancement de Fable** enteramente con Claude Code pese a no saber nada del dominio (transcripción con Whisper, edición con ffmpeg, UI sincronizada palabra a palabra vía Remotion, *corrección de color* que hizo que Claude le *enseñara*). Cada técnica viene con **prompts de ejemplo** listos para copiar y pegar — es una guía operativa, no una teoría. Frases doctrinales: *"reducir y anticipar tus incógnitas es LA habilidad de la codificación agéntica"*, *"cada explainer, brainstorm, entrevista, prototipo y referencia es una forma barata de descubrir lo que no sabías antes de que resulte caro corregirlo"*, *"solo hago merge después de aprobar el quiz a la perfección"*, *"lo que aprendes se convierte en el mapa para la próxima vez"*. **Público objetivo**: ingenieros y makers que trabajan con Claude, incluso fuera de su área de especialización.

## Pense-betes

- **Metáfora marco: el mapa no es el territorio.** El **mapa** = lo que le das a Claude (prompts, skills, contexto). El **territorio** = donde ocurre el trabajo (base de código, mundo real, restricciones). La brecha entre ambos = las **incógnitas**. Ante una incógnita, Claude *decide en función de su mejor suposición sobre lo que quieres* → cuanto mayor es el trabajo, más incógnitas encuentra.
- **La meseta de Fable.** *"Fable es el primer modelo en el que descubro que la calidad del trabajo está limitada por mi capacidad de aclarar sus incógnitas"* — el cuello de botella ha pasado del modelo a la **claridad humana**. Planificar de antemano no basta: las incógnitas emergen a mitad de la implementación, o revelan que el problema debía resolverse de **otra manera**. → un proceso **iterativo**: descubrir tus incógnitas **antes, durante y después**.
- **Los 4 cuadrantes (matriz de incógnitas)**: **Lo que sabemos que sabemos** = lo que está en el prompt (lo que dices que quieres); **Lo que sabemos que no sabemos** = lo que aún no has resuelto pero de lo que eres consciente; **Lo que no sabemos que sabemos** = *"demasiado obvio para escribirlo, pero lo reconocería"* (el "lo sabré cuando lo vea"); **Lo que no sabemos que no sabemos** = *"el bache que no sabías que la carretera podía tener"*.
- **La verdadera habilidad**: *"reducir y anticipar tus incógnitas es LA habilidad de la codificación agéntica"*. Los mejores (cita a **Boris** y **Jarred**) tienen **pocas incógnitas** (sincronizados tanto con la base de código como con los comportamientos del modelo) pero **asumen** que quedan algunas. Buena noticia: es una habilidad que **mejora trabajando con Claude**.
- **Instruir a Claude es un equilibrio delicado.** Demasiado preciso → Claude sigue las instrucciones incluso cuando un **cambio de rumbo** sería mejor. Demasiado vago → Claude rellena con *best practices del sector*, no necesariamente adecuadas al caso. Sin gestionar tus incógnitas, **fallas en ambos extremos**. Remedio: dale a Claude **contexto sobre tu punto de partida** (dónde estás en tu razonamiento, tu experiencia con el problema) y trátalo como un **compañero de pensamiento**. Claude busca en la base de código y en la web muy rápido, e itera a partir del fracaso más rápido que nosotros.
- **ANTES — Blindspot pass**: al trabajar en territorio desconocido (lo que no sabemos que no sabemos), pídele a Claude que **encuentre y explique sus puntos ciegos**. Usa literalmente las palabras *"blindspot pass"* y *"unknown unknowns"* además de contexto sobre quién eres. P. ej. *"estoy añadiendo un nuevo proveedor de auth pero no sé nada de los módulos de auth… haz un blindspot pass"*; *"enséñame a entender mis unknown unknowns sobre la corrección de color para poder promptear mejor"*.
- **ANTES — Brainstorms y prototipos**: para lo que **no sabemos que sabemos** (criterios que solo puedes definir al verlos, p. ej. el diseño visual). Verbalízalos **pronto**, ya que descubrirlos durante la implementación resulta costoso (un pequeño cambio de especificación puede implicar un código radicalmente distinto, difícil de revertir). Empieza **casi todas las sesiones** con una fase de exploración/brainstorm para encuadrar el alcance (ni demasiado estrecho ni demasiado amplio). P. ej. *"hazme una página HTML con 4 direcciones de diseño radicalmente distintas para que pueda reaccionar a ellas"*; *"maqueta la nueva barra de herramientas en un único archivo HTML con datos ficticios antes de tocar la app real"*; *"haz un brainstorm de 10 lugares donde podríamos intervenir, del más barato al más ambicioso"*.
- **ANTES — Entrevistas**: tras el brainstorm, pídele a Claude que **nos entreviste** sobre las ambigüedades restantes, **una pregunta a la vez**, priorizando *"las preguntas cuya respuesta cambiaría la arquitectura"*.
- **ANTES — Referencias**: cuando no puedes describir lo que quieres, **la mejor referencia es el código fuente**. Señala a Fable una carpeta/librería (incluso en otro lenguaje) e indica qué buscar ahí. **Claude Design** funciona así: al apuntar a un módulo de un sitio, **lee el código subyacente** (markup, estructura, construcción real), no solo la captura de pantalla. P. ej. *"este crate de Rust implementa exactamente el backoff que quiero — reimplementa la misma semántica en nuestro cliente TypeScript"*.
- **ANTES — Plan de implementación**: pide un plan **guiado por las decisiones con más probabilidad de cambiar** (modelos de datos, interfaces de tipos, flujos UX) y que **relegue el refactor mecánico al final** (*"en eso confío en ti"*). El plan **saca a la luz** lo que realmente habrá que modificar.
- **DURANTE — Implementation notes**: por mucha planificación que se haga, **siempre quedan cosas que no sabemos que no sabemos** (el agente encuentra un caso límite mientras codifica). Haz que Claude Code mantenga un **`implementation-notes.md`** temporal registrando decisiones *"para poder aprender de nuestro próximo intento"*. P. ej. *"si te topas con un caso límite que obliga a una desviación, elige la opción conservadora, regístrala bajo 'Deviations' y continúa"*.
- **DESPUÉS — Pitches y explainers**: *shippear* significa conseguir **respaldo y aprobaciones**. Empaqueta prototipo + spec + notas en **un único documento** que *"empiece con el GIF de la demo"* → acelera la comprensión (los revisores **parten de las mismas incógnitas que tú**) y las aprobaciones (los expertos quieren ver que sus puntos de fallo quedaron cubiertos).
- **DESPUÉS — Quizzes**: tras una sesión larga, leer los diffs solo da una comprensión **superficial** (el comportamiento depende de los flujos de código ya existentes). Pídele a Claude un **informe HTML + un quiz** sobre los cambios — *"solo hago merge después de aprobar el quiz a la perfección"*.
- **Prueba por el ejemplo: la Vidéo de lancement de Fable**, editada **enteramente con Claude Code** en un dominio que Thariq no dominaba — parte de lo que sabe (Claude puede editar/transcribir vídeo mediante código), se hace **explicar** Whisper/ffmpeg, **prototipa** una UI sincronizada palabra a palabra con Remotion, y luego hace que Claude le **enseñe** la corrección de color (sin tener ni idea de qué significa "bueno") en lugar de generar variantes a ciegas.
- **Conclusión**: *"cada explainer, brainstorm, entrevista, prototipo y referencia es una forma barata de descubrir lo que no sabías antes de que resulte caro corregirlo"* → *"empieza tu próximo proyecto pidiéndole a Claude que te ayude a encontrar tus incógnitas"*. El residuo del aprendizaje se convierte en el mapa para la próxima vez ("lo que aprendes se convierte en el mapa para la próxima vez").
- **Enlaces**: converge con el *Compounding Knowledge Lifecycle* (capitalizar lo aprendido), *loop engineering*, y la nota **[[willison-fable-judgement-delegation-subagents-2026-07-03]]** (mismo autor citado, Thariq, mismo momento sobre Fable) — dos facetas complementarias: Willison sobre **dejar que Fable juzgue**, Thariq sobre **reducir tus propias incógnitas para guiarlo mejor**.

## RésuméDe400mots

En esta *guía de campo* publicada el 3 de julio de 2026, **Thariq Shihipar** (equipo de Claude Code) formaliza una práctica para sacar el máximo partido a **Claude Fable 5**. Punto de partida, tomado de Korzybski: *"el mapa no es el territorio"*. El **mapa** es lo que le das a Claude — prompts, skills, contexto. El **territorio** es donde ocurre el trabajo — la base de código, el mundo real, sus restricciones. A la brecha entre ambos la llama las **incógnitas**: cuando Claude se topa con una, decide en función de su mejor suposición sobre lo que quieres. Cuanto mayor es el alcance del trabajo, más incógnitas encuentra. Fable es *"el primer modelo en el que descubro que la calidad del trabajo está limitada por mi capacidad de aclarar sus incógnitas"* — el cuello de botella ha pasado del modelo a la claridad humana.

Thariq propone una **matriz 2×2**: *lo que sabemos que sabemos* (lo que está en el prompt), *lo que sabemos que no sabemos* (lo que sabes que no sabes), *lo que no sabemos que sabemos* (lo obvio que no escribes pero reconocerías) y *lo que no sabemos que no sabemos* (lo que nunca consideraste). Reducir y anticipar tus incógnitas es, en su opinión, **LA habilidad** de la codificación agéntica — y se aprende trabajando con Claude. Instruir sigue siendo un equilibrio delicado: demasiado preciso, y Claude sigue las instrucciones al pie de la letra incluso cuando un cambio de rumbo sería mejor; demasiado vago, y rellena los huecos con *best practices* poco adecuadas.

Lo que sigue es un **conjunto de herramientas** ordenado en el tiempo, cada técnica acompañada de prompts. **Antes**: el *blindspot pass* (hacer explícitos tus puntos ciegos), *brainstorms y prototipos* (verbalizar pronto lo que no sabemos que sabemos, p. ej. 4 direcciones de diseño en HTML), *entrevistas* (Claude te pregunta una cuestión a la vez, priorizando lo que cambiaría la arquitectura), *referencias* (la mejor es el código fuente — así es como funciona **Claude Design**), y el *plan de implementación* guiado por lo que probablemente cambiará. **Durante**: un `implementation-notes.md` donde el agente registra sus desviaciones. **Después**: *pitches y explainers* (un único documento guiado por la demo, ya que los revisores parten de las mismas incógnitas) y *quizzes* ("solo hago merge después de aprobar el quiz a la perfección").

Prueba de apoyo: la **Vidéo de lancement de Fable**, editada íntegramente con Claude Code en un dominio ajeno al autor, llegando incluso a que el modelo le *enseñara* la corrección de color. Moraleja: cada artefacto es una forma barata de descubrir lo que no sabías **antes de que resulte caro corregirlo**. *"Empieza tu próximo proyecto pidiéndole a Claude que te ayude a encontrar tus incógnitas."*

## GrapheDeConnaissance

- Thariq Shihipar —travaille_chez→ équipe Claude Code (Anthropic) (ORGANISATION, 0.95)
- Thariq Shihipar —affirme_que→ "Fable est le premier modèle où la qualité du travail est plafonnée par ma capacité à clarifier ses inconnues" (AFFIRMATION, 0.95)
- Finding Your Unknowns —s_applique_à→ Claude Fable 5 (TECHNOLOGIE, 0.95)
- Finding Your Unknowns —est_basé_sur→ "la carte n'est pas le territoire" (AFFIRMATION, 0.93)
- Matrice des inconnues —fait_partie_de→ Finding Your Unknowns (METHODOLOGIE, 0.9)
- Thariq Shihipar —affirme_que→ "reducing and planning for your unknowns is THE skill of agentic coding" (CITATION, 0.94)
- Blindspot pass —permet→ Unknowns (CONCEPT, 0.9)
- Brainstorms & prototypes —permet→ verbaliser tôt les unknown knowns (moins cher qu'en implémentation) (CONCEPT, 0.9)
- References —résout→ l'incapacité à décrire ce qu'on veut en détail (CONCEPT, 0.9)
- Claude Design —utilise→ lecture du code sous-jacent d'un module (pas seulement la capture) (CONCEPT, 0.88)
- implementation-notes.md —permet→ journaliser les déviations pendant l'implémentation (CONCEPT, 0.9)
- Quizzes —améliore→ la compréhension réelle d'un changement avant le merge (CONCEPT, 0.9)
- Pitches & explainers —permet→ obtenir buy-in et approbations (reviewers partant des mêmes inconnues) (CONCEPT, 0.88)
- Claude Code —a_créé→ vidéo de lancement de Fable (DOCUMENT, 0.9)
- Instruction de Claude —affirme_que→ trop spécifique empêche le pivot, trop vague invoque des best practices inadaptées (AFFIRMATION, 0.9)

---
Canonical: https://www.thekb.eu/es/fiches/thariq-field-guide-fable-finding-unknowns-2026-07-03/
