Fable 5: el cuello de botella pasó del modelo al usuario

Cualquiera que programe con agentes de IA conoce la escena. El prompt está listo, el plan parece claro, pero el resultado no cuaja. Según Thariq Shihipar, desarrollador de Anthropic, con el último modelo de Claude, Fable 5, cada vez menos es culpa del modelo y cada vez más de los puntos ciegos del propio usuario.

Shihipar sostiene que Fable 5 es el primer modelo donde la calidad del output está limitada por la capacidad del usuario para explicitar sus incógnitas. Distingue cuatro categorías: "Known Knowns" son las que ya figuran en el prompt; "Known Unknowns" son las preguntas que sabes que no resolviste todavía; "Unknown Knowns" son conocimientos tan obvios que jamás los escribirías, pero los reconocerías al verlos; y "Unknown Unknowns" son las cosas en que ni siquiera pensaste. Esta última categoría, dice, es la crítica.

Ser muy específico es tan malo como ser muy vago

Planificar de antemano por sí solo no basta, plantea Shihipar. Las incógnitas pueden aflorar en mitad de la implementación o incluso señalar que el problema debía resolverse de otra forma. Los mejores programadores agénticos tienen relativamente pocas incógnitas, pero siempre esperan que aparezcan más, sostiene.

Demasiada especificidad hace que Fable 5 siga instrucciones rígidas incluso cuando un cambio de rumbo tendría más sentido. Demasiada vaguedad, en cambio, produce decisiones basadas en defaults de la industria que no encajan con la tarea concreta.

"Cuando no consideras tus incógnitas, fallas en ambos frentes", escribe Shihipar. Pero Claude puede ayudarte a descubrirlas más rápido: busca en el código y en internet a alta velocidad y sabe más sobre la mayoría de los temas que el usuario promedio. La clave, según él, es darle contexto sobre tu punto de partida, es decir, dónde estás en tu razonamiento y qué experiencia tienes con el problema.

¿Cómo se descubren los puntos ciegos antes de programar?

Shihipar describe varias técnicas para la fase previa a la implementación. En lo que llama un blindspot pass, le pides a Claude que identifique tus unknown unknowns. Funciona especialmente bien cuando estás trabajando en una parte del código que no conoces, sostiene.

Un prompt de ejemplo que sugiere: "Estoy agregando un nuevo proveedor de auth pero no sé nada de los módulos de auth en este codebase. ¿Puedes hacer un blindspot pass para ayudarme a identificar mis unknown unknowns relevantes y prompearte mejor?".

Para áreas con muchos "unknown knowns", como diseño visual, recomienda brainstorming y prototipado. En vez de saltar directo a implementar, hace que Claude genere varias direcciones de diseño radicalmente distintas como artefactos HTML, así puede reaccionar a algo tangible. Casi todas sus sesiones de código arrancan con una fase de exploración o brainstorming para acotar el alcance del proyecto de forma consciente.

Otras técnicas que describe incluyen entrevistas estructuradas, donde Claude interroga al usuario pregunta por pregunta sobre ambigüedades, priorizando aquellas cuyas respuestas cambiarían la arquitectura. Las referencias también importan, dice Shihipar: el mejor referente es código fuente, aunque esté en otro lenguaje de programación. Claude Design, por ejemplo, lee el código subyacente de un sitio, no solo el screenshot.

Antes de arrancar el trabajo propiamente tal, Shihipar hace que Claude arme un plan de implementación centrado en las partes más propensas a cambiar, como modelos de datos, interfaces de tipos y todo lo que está en el lado del usuario. La refactorización mecánica queda para el final.

Durante y después, documentar y entender

Las incógnitas también acechan durante la implementación, advierte. Le pide a Claude Code que mantenga un archivo temporal implementation-notes.md donde registra las decisiones que va tomando, para poder aprender del siguiente intento. Cuando aparecen edge cases inesperados, Claude debe elegir la opción conservadora, dejar constancia del desvío y seguir trabajando.

Después de implementar, Shihipar recomienda dos técnicas. La primera son pitches and explainers: documentos resumen para stakeholders que empaquetan prototipo, especificaciones y notas de implementación. La segunda son quizzes: Claude genera un reporte HTML detallando los cambios hechos, con contexto e insights, seguido de un cuestionario. Shihipar dice que no mergea hasta pasar el quiz sin errores.

Las cuatro categorías de incógnitas

¿Cómo se ve en la práctica? El video de lanzamiento de Fable

Shihipar muestra cómo se articulan estas técnicas usando como ejemplo el video de lanzamiento de Fable, editado enteramente con Claude Code. La edición de video era territorio nuevo para él.

Empezó por lo que sabía. Claude puede editar y transcribir videos usando código, pero no estaba claro si la precisión sería suficiente, así que hizo que alguien le explicara cómo funciona la transcripción con Whisper y si las muletillas y pausas podían cortarse con precisión usando ffmpeg. Para el fade-in temporalizado de elementos UI construyó un prototipo con Remotion.

Cuando el resultado se veía plano en color, primero intentó que Claude generara varias variaciones de color-grading. Pero se dio cuenta de que no sabía qué era "bueno" en color-grading. En vez de evaluar variaciones a ciegas, hizo que Claude le enseñara sobre el tema para destapar sus propias incógnitas.

Mientras más potentes se vuelven los modelos, más se puede lograr con el enfoque correcto, dice Shihipar. Si una tarea larga se sale de curso, probablemente hay que invertir más tiempo definiendo las propias incógnitas o crear un plan de implementación que le permita a Claude improvisar sobre ellas.

"Cada explainer, brainstorm, entrevista, prototipo y referencia es una forma barata de descubrir lo que no sabías antes de que arreglarlo se ponga caro", escribe. Shihipar también publicó una versión visual de sus tips en un sitio web.