A Field Guide to Fable: Finding Your Unknowns

Puntos clave

1. 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.
2. 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.
3. 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".
4. 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.
5. 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.
6. 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".
7. 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".
8. 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".
9. 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".
10. 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.
11. 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".
12. 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).
13. 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".
14. 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.
15. 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").
16. 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.