Desde el momento de su lanzamiento, el destino de Fable 5 ha sido tan místico como el nombre del modelo.
Desde el esperado "momento de la deificación de la IA", pasando por la orden del gobierno estadounidense que lo forzó a desconectarse, hasta la prohibición de acceso para no estadounidenses, definitivamente ha captado la atención global.
Ahora, el revuelo gradualmente se calma. Al final, los modelos deben volver a la productividad.
Para ello, el ingeniero de Claude Code, Thariq Shihipar, publicó un extenso blog en redes sociales, detallando las técnicas para usar Fable 5.
Este artículo resuelve una duda de larga data. Si las capacidades de los modelos actuales han evolucionado hasta un punto tan poderoso, ¿por qué sigo sintiendo que no realiza bien las tareas cuando lo uso?
El blog de Thariq trae claridad. En resumen: existe una brecha de información entre el humano y el modelo, es decir, la diferencia entre las indicaciones (prompts), habilidades, contexto proporcionado por el usuario y la ejecución real de la tarea.
Por ello, el blog completo enseña precisamente cómo romper esta brecha de información. A continuación, Machine Heart incluye el texto completo del blog para el disfrute de los lectores.
Título del blog: Una guía de campo para Fable: Encontrando tus desconocidos
Enlace del blog: https://x.com/trq212/status/2073100352921215386
Trabajar con Claude Fable 5 me hace recordar constantemente una vieja lección: el mapa no es el territorio.
Lo que llamo "mapa" es la representación del trabajo a realizar, es decir, mis indicaciones, habilidades y contexto, lo que entrego a Claude. Lo que llamo "territorio" es el lugar donde realmente necesita ocurrir el trabajo: el repositorio de código, el mundo real y las restricciones reales existentes en él.
Llamo "incógnitas" a la brecha entre el mapa y el territorio. Cuando Claude encuentra una incógnita, debe tomar decisiones basándose en su mejor suposición sobre mi intención. Cuanto más complejo es el trabajo, más incógnitas puede encontrar Claude.
Fable es el primer modelo que me hizo sentir claramente que el cuello de botella de la calidad del trabajo depende de mi capacidad para aclarar sus incógnitas.
Es importante destacar que solo planificar con anticipación no siempre es suficiente. Puedes descubrir incógnitas en las profundidades de la implementación; o puedes darte cuenta de que estas incógnitas apuntan a un hecho: que en realidad deberías abordar el problema de una manera completamente diferente.
Descubro que colaborar con Fable es, en esencia, un proceso iterativo de descubrir incógnitas antes, durante y después de la implementación.
El autor proporciona algunos ejemplos para descubrir "incógnitas", los lectores pueden consultarlos junto con el texto completo.
Enlace del ejemplo: https://thariqs.github.io/html-effectiveness/unknowns/
Conoce tus incógnitas
¿Qué es una incógnita? Cuando acudo a Claude con un problema, normalmente lo desgloso desde cuatro ángulos:
Conocidos conocidos: Básicamente, esto es lo que escribo en mis indicaciones. Le digo al agente, ¿qué quiero?
Conocidos desconocidos: ¿Qué cosas aún no tengo claras, pero sé que no las tengo claras?
Desconocidos conocidos: ¿Qué cosas son tan obvias para mí que ni siquiera las escribiría, pero las reconocería una vez las vea?
Desconocidos desconocidos: ¿Qué cosas no he considerado en absoluto? ¿Qué conocimiento no sé que no sé? ¿Sé qué tan bien se puede hacer algo?
Los mejores programadores que trabajan con agentes suelen tener relativamente menos incógnitas. Tienen muy claro lo que quieren, y con mucho detalle. Están altamente sincronizados tanto con el repositorio de código como con el comportamiento del modelo.
Pero también presuponen la existencia de incógnitas. En muchos sentidos, reducir y planificar con antelación tus incógnitas es la habilidad central de la programación con agentes. Afortunadamente, es una habilidad que se puede mejorar continuamente colaborando con Claude.
Ayuda a Claude para ayudarte a ti mismo
Dar instrucciones a Claude es un delicado equilibrio. Si eres demasiado específico, incluso si otro enfoque podría ser más apropiado, Claude ejecutará estrictamente tus órdenes. Si eres demasiado vago, Claude a menudo tomará decisiones y hará suposiciones basadas en las mejores prácticas de la industria, y esas elecciones no necesariamente se ajustan a tu tarea.
Cuando no consideras suficientemente tus incógnitas, ambos casos fracasan. No sabes cuándo el camino por delante estará lleno de obstáculos, ni cuándo el camino en realidad es suave, pero aún así esperas que Claude pueda hacer ajustes cuando sea necesario.
Claude puede ayudarte a descubrir incógnitas más rápido. Puede buscar en tu repositorio de código y en internet a velocidades extremas, y posee más conocimiento general sobre la mayoría de los temas que tú. También puede iterar más rápido a partir de los fracasos.
Lo más importante en este proceso es darle a Claude suficiente contexto de partida. Por ejemplo, dile en qué punto estás pensando actualmente; explica tu nivel de familiaridad con el problema y el código; haz que colabore contigo como un compañero de pensamiento.
He escrito antes sobre cómo usar Claude para generar HTML. En casi todos estos escenarios, los artefactos HTML son la mejor manera de visualizar y expresar ideas.
En este artículo, detallaré algunos de los patrones que uso para descubrir estas incógnitas. No uso todas las técnicas cada vez, pero tenerlas como un conjunto de métodos a los que recurrir es muy útil.
Antes de la implementación
Escaneo de puntos ciegos
Una de las cosas más útiles al comenzar a trabajar es entender tus propios puntos ciegos. Por ejemplo, si estás escribiendo una funcionalidad en un módulo nuevo del código, o estás pidiendo a Claude que maneje algún tipo de trabajo con el que no estás familiarizado, como iterar sobre un diseño, es probable que tengas muchos "desconocidos desconocidos".
Puede que no sepas qué preguntas hacer, qué cuenta como bueno, qué trabajo histórico se ha hecho ya, ni qué trampas deberías evitar.
Para hacer esto, puedes pedirle a Claude que te ayude a encontrar los "desconocidos desconocidos" y te los explique. Me gusta usar directamente frases como "blindspot pass" y "unknown unknowns". Por lo general, también es importante decirle quién eres y qué sabes.
Ejemplo de indicación:
"Estoy añadiendo un nuevo proveedor de autenticación, pero no sé nada sobre el módulo de autenticación en este código. ¿Podrías hacer un 'blindspot pass' para ayudarme a encontrar los 'unknown unknowns' relevantes y así poder escribirte mejores indicaciones?"
"No entiendo de gradación de color (color grading), pero necesito hacerlo para este video. ¿Podrías enseñarme a entender mis 'unknown unknowns' en cuanto a gradación de color, para poder escribir mejores indicaciones?"
Lluvia de ideas y prototipado
Cuando trabajo en un área con muchos "desconocidos conocidos", es decir, cosas para las cuales solo sé cómo definir estándares una vez que las veo, le pido a Claude que haga lluvia de ideas y prototipos conmigo.
Identificar y expresar estos "desconocidos conocidos" temprano en la fase de prototipado es muy valioso, porque descubrirlos en la fase de implementación suele tener un costo relativamente mayor. Pequeños cambios en la funcionalidad o especificaciones pueden provocar grandes diferencias en la implementación del código, y hacer que el agente revierta cambios anteriores es más difícil.
Por ejemplo, puede que solo quieras ver cómo se vería agregar un botón en cierto framework, sin querer realmente conectar rutas backend ni mantener estado adicional en el frontend.
El diseño visual es para mí algo difícil de expresar claramente, pero sé lo que quiero una vez que lo veo. En este caso, le pido a Claude que proporcione varias direcciones de diseño diferentes para un artefacto.
Casi siempre comienzo cada sesión de codificación con exploración o lluvia de ideas. Esto me ayuda a definir el alcance del proyecto con una intención clara. Claude a menudo descubre enfoques de alto valor que yo habría pasado por alto, pero a veces también puede perderse en los detalles. La lluvia de ideas me impide comenzar con un alcance demasiado estrecho o demasiado amplio.
Ejemplo de indicación:
"Quiero hacer un panel de control para este conjunto de datos, pero no tengo gusto visual y no sé hasta dónde se puede llegar. Ayúdame a hacer una página HTML con 4 direcciones de diseño muy diferentes, para que pueda dar retroalimentación basada en los resultados."
"Antes de conectar nada, haz un archivo HTML separado con datos falsos que simule la nueva barra de herramientas del editor. Quiero dar retroalimentación sobre el diseño primero, luego puedes modificar la aplicación real."
"Este es mi problema aproximado: los usuarios abandonan después de completar la incorporación (onboarding). Busca en el repositorio, haz una lluvia de ideas de 10 lugares donde podríamos intervenir, desde los de menor costo hasta las soluciones más ambiciosas. Te diré qué direcciones me parecen más interesantes."
Preguntas de contraste
Después de suficiente lluvia de ideas, normalmente todavía tendré incógnitas.
En este caso, le pido a Claude que me entreviste en torno a cualquier punto poco claro o ambiguo. Al pedirle a Claude que te entreviste, proporciona tanto contexto sobre el problema como sea posible para que pueda hacer preguntas más específicas. Aquí hay algunos ejemplos.
Ejemplo de indicación:
"Por favor, hazme solo una pregunta a la vez, entrevístame sobre cualquier área de ambigüedad. Prioriza las preguntas cuyas respuestas cambiarían el diseño de la arquitectura."
Materiales de referencia
A veces, no puedes describir en detalle lo que quieres. Por ejemplo, puede que no tengas el lenguaje para expresarlo, o es demasiado complejo y describirlo completamente tomaría mucho tiempo.
En este caso, la mejor respuesta son los materiales de referencia. Puedes proporcionar diagramas, documentación o imágenes, pero el mejor material de referencia es en realidad el código fuente.
Si tienes una biblioteca que implementa una funcionalidad de cierta manera específica, o un componente de diseño que te gusta mucho, simplemente apunta a Fable a esa carpeta y dile qué mirar. Incluso si el código de referencia está en otro lenguaje, no hay problema.
Así es como funciona Claude Design. No necesariamente tienes que darle un archivo, aunque también puedes hacerlo. Puedes dirigirlo a un módulo de un sitio web que te guste, y leerá el código subyacente, no solo una captura de pantalla. Esto proporciona detalles más ricos, incluyendo la estructura del marcado, cómo se organizan los componentes y cómo se construye realmente este componente.
Ejemplo de indicación:
"Este crate de Rust en vendor/rate-limiter implementa exactamente el comportamiento de reintento con retroceso (backoff retry) que quiero. Por favor, léelo y reimplementa la misma semántica en nuestro cliente API de TypeScript."
Plan de implementación
Cuando me siento listo para comenzar la implementación, normalmente le pido a Claude que primero elabore un plan de implementación para que yo lo revise, centrándome en las partes con mayor probabilidad de cambiar, como el modelo de datos, las interfaces de tipo o los flujos de UX. Esto permite que Claude exponga de antemano algunas áreas que realmente podría necesitar ajustar.
Ejemplo de indicación:
"Escribe un plan de implementación en HTML, pero comienza presentando primero los puntos de decisión que con mayor probabilidad modificaré: cambios en el modelo de datos, nuevas interfaces de tipo y cualquier contenido orientado al usuario. Las refactorizaciones mecánicas van al final, esa parte confío en que puedes manejarla."
Durante la implementación
Notas de implementación
Cuando estoy satisfecho con el plan, inicio una nueva sesión e incluyo los artefactos relevantes en la indicación. Por ejemplo, podría incluir un archivo de especificaciones y un prototipo, y luego pedirle al agente que lo implemente.
Pero la realidad es que, por mucha planificación que hagas, siempre habrá "desconocidos desconocidos" acechando. El agente puede descubrir durante el trabajo que, debido a algún caso límite en el código, debe cambiar de enfoque.
Le pido a Claude Code que mantenga un archivo temporal implementation-notes.md, o un archivo .html, para registrar las decisiones que toma, para que podamos aprender del siguiente intento.
Ejemplo de indicación:
"Por favor, mantén un archivo implementation-notes.md. Si encuentras un caso límite que te obliga a desviarte del plan original, elige la opción conservadora, registra la razón en la sección 'Deviations' y continúa."
Después de la implementación
Documentación de presentación y explicación
Al lanzar algo, una de las cosas más importantes es conseguir la comprensión, el apoyo y la aprobación de los demás. Construir artefactos de presentación y explicación en la documentación final ayuda a:
Acelerar la comprensión de los revisores cuando ellos también comienzan con las mismas incógnitas que tú.
Acelerar la aprobación cuando los expertos quieren confirmar que has considerado las incógnitas y los puntos de falla comunes que ellos habrían anticipado.
Ejemplo de indicación:
"Empaqueta el prototipo, las especificaciones y las notas de implementación en un documento único que pueda enviar directamente a Slack para buscar apoyo. Comienza con un GIF de demostración."
Pruebas
Después de una larga sesión de trabajo, Claude puede haber hecho más trabajo del que me di cuenta. Solo mirar el diff del código a menudo me da una comprensión superficial de lo que sucedió, porque mucho comportamiento depende de las rutas de código existentes.
Pedirle a Claude que, después de darme mucho contexto, me examine sobre los cambios, puede ayudarme a entender realmente lo que pasó. Solo fusiono el código después de pasar perfectamente la prueba.
Ejemplo de indicación:
"Quiero asegurarme de entender todo lo que ocurrió en este cambio. Por favor, dame un informe en HTML que me ayude a leer y comprender estos cambios, incluyendo contexto, explicación intuitiva, qué se hizo concretamente, etc., y añade al final una prueba que deba aprobar."
Enlazando métodos: Tomando el lanzamiento de Fable como ejemplo
El video de lanzamiento de Fable fue editado completamente por Claude Code. Este era un territorio completamente nuevo para mí, y no soy en absoluto un experto en esto.
Así que comencé por lo que ya conocía. Sabía que Claude podía usar código para editar videos y transcribir, pero no estaba seguro de si su precisión sería suficiente. Entonces le pedí a Claude que me explicara cómo funcionan tecnologías de transcripción como Whisper, y si podría usar ffmpeg para cortar con precisión muletillas como "eh" o pausas largas.
Quería que Claude creara una interfaz de usuario sincronizada en el tiempo con las palabras que decía, pero no estaba seguro de si podría hacerlo. Así que le pedí a Claude que usara Remotion y el texto transcrito para crear un prototipo de video, para ver si la idea era viable.
Finalmente, el video en sí se veía un poco apagado. Sabía que era un problema de gradación de color, pero realmente no entendía qué es la gradación de color. Mi primer intento fue pedirle a Claude que hiciera algunas versiones para que yo eligiera, pero me di cuenta de que, cuando se trata de gradación de color, no sé qué es "bueno". Así que, en lugar de seguir generando versiones ciegamente, le pedí a Claude que me enseñara sobre gradación de color, para descubrir mis incógnitas.
Haciendo coincidir el mapa con el territorio
Cuanto más potente es el modelo, más puedes lograr a través de métodos correctos. Cuando una tarea de ciclo largo devuelve un resultado erróneo, es probable que necesites pasar más tiempo definiendo tus incógnitas, o crear un plan de implementación que permita a Claude navegar con flexibilidad entre estas incógnitas.
Cada documento explicativo, sesión de lluvia de ideas, entrevista, prototipo y material de referencia es un método de bajo costo para descubrir cosas que originalmente no sabías, antes de que el costo de corregirlas aumente.
Así que, al comenzar tu próximo proyecto, primero deja que Claude te ayude a encontrar tus incógnitas.
Este artículo proviene del WeChat oficial "Machine Heart", editado por: El equipo editorial de Machine Heart
