Guía de campo de Fable: encontrar mis incógnitas

• La clave del trabajo con Claude Fable 5 es encontrar y reducir la brecha entre el mapa (map, prompt·skills·contexto) que da el usuario y el territorio (territory, codebase·realidad·restricciones) donde el trabajo ocurre de verdad, es decir, las incógnitas (unknowns)
• Fable es el primer modelo en el que la calidad del trabajo depende de la capacidad del usuario para aclarar las incógnitas, y mientras mayor sea la carga de trabajo, más incógnitas aparecen
• Las incógnitas se dividen en 4 tipos: Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns, y reducirlas y prepararse para ellas es la capacidad central del coding agéntico
• Antes, durante y después de implementar, se descubren incógnitas con técnicas iterativas como blindspot pass, lluvia de ideas, entrevistas, referencias, planes de implementación, notas de implementación y quizzes
• La explicación, la lluvia de ideas, las entrevistas, los prototipos y las referencias son formas de descubrir incógnitas a bajo costo antes de que el problema se vuelva caro, y es importante empezar el siguiente proyecto pidiéndole a Claude que encuentre las incógnitas

---

El mapa y el territorio, y las incógnitas (Unknowns)

• El mapa es la representación del trabajo a realizar: prompt·skills·contexto, o sea, lo que se le da a Claude; el territorio es el codebase·realidad·restricciones reales donde el trabajo ocurre en la práctica
• La diferencia entre el mapa y el territorio son precisamente las incógnitas (unknowns), y cuando Claude se topa con una incógnita, tiene que decidir haciendo la mejor suposición posible sobre lo que el usuario quiere
• Fable es el primer modelo en el que la calidad del trabajo tiene como cuello de botella la capacidad de aclarar las incógnitas
• Planear de antemano no basta; las incógnitas pueden descubrirse muy dentro de la implementación o incluso indicar que el problema debe resolverse de otra manera
• El trabajo con Fable es un proceso iterativo de descubrir incógnitas antes, durante y después de implementar
• Algunos materiales de ejemplo útiles para encontrar lo desconocido para revisar más tarde

Conocer tus incógnitas (Knowing your unknowns)

• Descompone el problema en 4 categorías
  • Known Knowns: lo que está en el prompt, lo que le dices al agente que quieres
  • Known Unknowns: lo que todavía no has identificado, pero sí sabes que no lo has hecho
  • Unknown Knowns: lo tan obvio que no se escribe, pero que reconoces en cuanto lo ves
  • Unknown Unknowns: lo que ni siquiera has considerado, el conocimiento que no sabes que te falta, o cuánto podría mejorar algo sin que lo sepas
• Un buen coder agéntico tiene relativamente pocas incógnitas y está profundamente sincronizado (in-sync) con el codebase y con el comportamiento del modelo, por lo que sabe con detalle lo que quiere
• Reducir las incógnitas y prepararse para ellas es una habilidad que puede mejorar trabajando con Claude

Haz que Claude te ayude mejor (Help Claude help you)

• Las instrucciones necesitan equilibrio: si son demasiado específicas, Claude puede seguirlas incluso cuando convendría cambiar de dirección; si son demasiado vagas, tomará decisiones basadas en convenciones de la industria (best practices) que quizá no encajan con la tarea
• Si no se consideran las incógnitas, se falla en ambos extremos, y terminarás queriendo que Claude cambie de rumbo sin saber cuándo el camino está bloqueado o abierto
• Claude puede buscar rápido en el codebase y en internet, sabe más sobre temas promedio y itera rápido a partir del fracaso, así que acelera el descubrimiento de incógnitas
• Lo más importante es dar contexto sobre el punto de partida: explicar en qué parte de tu proceso mental estás, tu experiencia con el problema y con el codebase, y colaborar como si fuera un compañero de pensamiento
• Antes escribí sobre usar HTML en Claude, y en la mayoría de los casos los artefactos HTML son óptimos para visualizar y expresar ideas

Antes de implementar (Pre-implementation)

• Blind Spot Pass

  • En tareas poco familiares, como crear funcionalidades en un área nueva o iterar un diseño, suele haber muchos unknown unknowns: quizá no sabes qué preguntas hacer, qué se considera bueno, qué trabajos previos existen o qué trampas evitar
  • Pídele a Claude que encuentre y explique los unknown unknowns; es importante usar literalmente expresiones como "blindspot pass" y "unknown unknowns", y darle contexto sobre quién eres y qué sabes
  • Prompts de ejemplo
    • "Estoy agregando un nuevo auth provider y no conozco nada del módulo de auth de este codebase. Haz un blindspot pass para identificar los unknown unknowns relevantes y ayúdame a escribir mejores prompts"
    • "No sé qué es color grading, pero tengo que hacer grading a este video. Enséñame a entender los unknown unknowns de color grading para poder hacer mejores prompts"

• Lluvia de ideas y prototipos (Brainstorms and prototypes)

  • En áreas con muchos unknown knowns, es decir, criterios que reconoces al verlos pero que son difíciles de definir de antemano, conviene hacer lluvia de ideas y prototipos con Claude
  • Tiene valor identificar y poner en palabras los unknown knowns al inicio del prototipado y no en plena implementación, porque pequeños cambios en la especificación pueden alterar mucho el código y luego ser difíciles de revertir
    • Ejemplo: cuando solo quieres ver cómo se vería un botón agregado a un frame, sin rutas de backend ni estado de frontend
  • El diseño visual es un área difícil de describir con claridad, pero donde sabes lo que quieres cuando lo ves, así que conviene pedir varios enfoques de diseño
  • Casi toda sesión de coding debería empezar con una etapa de exploración y lluvia de ideas para definir el alcance con intención; eso evita que quede demasiado estrecho o demasiado amplio
  • Prompts de ejemplo
    • "Quiero un dashboard para estos datos, pero no tengo sentido visual ni sé qué es posible. Crea 4 páginas HTML con direcciones de diseño totalmente distintas para que yo pueda reaccionar"
    • "Antes de conectarlo, haz un mockup en un solo archivo HTML de una nueva toolbar del editor con datos falsos. Quiero reaccionar al layout antes de tocar la app real"
    • "El problema general es el abandono de usuarios después del onboarding. Busca en el codebase y haz una lluvia de ideas con 10 puntos de intervención, desde lo más barato hasta lo más ambicioso"

• Entrevistas (Interviews)

  • Si después de suficiente lluvia de ideas todavía quedan incógnitas, pídele a Claude una entrevista sobre esas incógnitas y ambigüedades, dándole contexto del problema para que formule preguntas
  • Prompt de ejemplo
    • "Haz preguntas sobre las partes ambiguas, una por una, y prioriza las que podrían cambiar la arquitectura según mis respuestas"

• Referencias (References)

  • Cuando no puedes describir en detalle lo que quieres, la mejor respuesta son las referencias; pueden ser diagramas, documentos o imágenes, pero el código fuente es por mucho la mejor referencia
  • Si hay una librería implementada de cierta forma o un componente de diseño que te gusta, incluso en otro lenguaje, señala la carpeta e indícale que lo busque
  • Claude Design funciona igual: si señalas un módulo de un sitio web que te guste, en vez de una captura de pantalla puede leer el código subyacente y darte información rica sobre el markup, la estructura y la implementación real
  • Prompt de ejemplo
    • "Este crate de Rust en vendor/rate-limiter implementa exactamente el comportamiento de backoff que quiero. Léelo y reimplanta esa misma semántica en nuestro cliente API en TypeScript"

• Planes de implementación (Implementation Plans)

  • Cuando ya estés listo para implementar, pide un plan de implementación para revisión centrado en las partes con mayor probabilidad de cambiar (modelo de datos, interfaces de tipos, flujo UX), para que salgan a la superficie los puntos que requieren ajustes
  • Prompt de ejemplo
    • "Escribe un plan de implementación en HTML, pero pon primero las decisiones que yo tendría más probabilidad de cambiar (cambios al modelo de datos, nuevas interfaces de tipos, elementos visibles al usuario), y manda las refactorizaciones mecánicas hasta abajo"

Durante la implementación (During implementation)

• Notas de implementación (Implementation notes)

  • Cuando ya estés conforme con el plan, crea una nueva sesión y pasa al prompt artefactos como el archivo de especificación o los prototipos para pedirle al agente que implemente
  • Por más que planees, los unknown unknowns siempre están al acecho, y puede que el agente tenga que elegir otro enfoque por casos borde descubiertos durante el trabajo
  • Haz que Claude Code registre las decisiones tomadas en un archivo temporal implementation-notes.md (o .html) para que la siguiente iteración aprenda de eso
  • Prompt de ejemplo
    • "Mantén un archivo implementation-notes.md. Si encuentras un caso borde que te obligue a desviarte del plan, toma una decisión conservadora, regístrala en 'Deviations' y sigue adelante"

Después de implementar (Post implementation)

• Pitches y materiales explicativos (Pitches and explainers)

  • Una de las partes más importantes al lanzar algo es conseguir alineación y aprobación, y ayuda crear artefactos de pitch y explicación en la documentación final
    • Si el revisor parte de las mismas incógnitas que tú, eso acelera la comprensión
    • Si un experto quiere verificar que se consideraron las incógnitas y los puntos típicos de fallo, eso acelera la aprobación
  • Prompt de ejemplo
    • "Une el prototipo, la especificación y las notas de implementación en un solo documento para publicarlo en Slack y conseguir alineación. Pon primero el GIF de demo"

• Quizzes

  • Después de una sesión larga de trabajo, Claude puede haber hecho más de lo que esperabas, y ver solo el diff del código te deja con una comprensión superficial de comportamientos que dependen de rutas ya existentes
  • Dale contexto y pídele a Claude que te haga un quiz sobre los cambios para verificar tu comprensión, y haz el merge solo después de pasarlo perfectamente
  • Prompt de ejemplo
    • "Quiero entender todo lo que pasó en este cambio. Haz un reporte en HTML con el contexto, la intuición y lo realizado, y agrega al final un quiz que deba aprobar sí o sí"

Cómo se integra todo en el caso del lanzamiento de Fable (How this comes together)

• El video de lanzamiento de Fable fue editado completamente con Claude Code, aunque era un área nueva y no una especialidad
• Partieron de lo que sí sabían: sabían que Claude podía editar video y transcribir con código, pero no estaban seguros de la precisión, así que pidieron una explicación del principio de transcripción al estilo Whisper y de si era posible cortar con precisión ums y silencios largos usando ffmpeg
• Querían una UI donde las palabras habladas y el timing coincidieran, pero no sabían si sería posible, así que lo validaron creando un video prototipo con Remotion y transcripción
• Sabían que el video se veía algo apagado por el color grading, pero no sabían qué era eso, así que en vez de solo elegir variaciones, pidieron que se les enseñara color grading para descubrir las incógnitas

Hacer coincidir el mapa y el territorio (Matching the Map and Territory)

• Mientras mejores sean los modelos, más cosas se pueden lograr con el enfoque correcto; cuando una tarea larga sale mal, por lo general hace falta dedicar más tiempo a definir las incógnitas o a un plan de implementación al que Claude pueda adaptarse sobre la marcha
• Toda explicación, lluvia de ideas, entrevista, prototipo y referencia sirve para descubrir incógnitas a bajo costo antes de que el problema se vuelva caro
• La clave es empezar el siguiente proyecto pidiéndole a Claude que encuentre las incógnitas