Trabajar con Claude Fable 5 no deja de recordarme una vieja lección: el mapa no es el territorio.
El mapa, una representación del trabajo a realizar, son mis prompts, mis habilidades y mi contexto; es lo que le doy a Claude. El territorio es donde debe ocurrir el trabajo: la base de código, el mundo real, sus limitaciones reales.
La diferencia entre el mapa y el territorio es lo que llamo incógnitas. Cuando Claude se topa con una incógnita, tiene que tomar una decisión basada en su mejor suposición de lo que quiero. Cuanto más trabajo se haga, más incógnitas puede encontrar Claude.
Fable es el primer modelo en el que siento que la calidad del trabajo está limitada por mi capacidad para aclarar sus incógnitas.
Algo importante: planificar con anticipación no siempre es suficiente. Puedes encontrar incógnitas en lo profundo de la implementación, o tus incógnitas pueden indicarte que en realidad deberías resolver el problema de una manera completamente diferente.
He descubierto que trabajar con Fable es un proceso iterativo de descubrir mis incógnitas antes, durante y después de la implementación.
He creado algunos artefactos de ejemplo para encontrar incógnitas aquí, pero asegúrate de volver para construir la intuición sobre cuándo usarlos.
Conocer tus incógnitas
¿Cuáles son tus incógnitas? Cuando acudo a Claude con un problema, tiendo a desglosarlo en 4 categorías:
- Known Knowns (Lo que sé que sé): Básicamente es lo que está en mi prompt. ¿Qué le digo al agente que quiero?
- Known Unknowns (Lo que sé que no sé): ¿Qué no he resuelto todavía, pero soy consciente de que no lo he resuelto?
- Unknown Knowns (Lo que no sé que sé): ¿Qué es tan obvio que nunca lo escribiría, pero lo reconocería si lo viera?
- Unknown Unknowns (Lo que no sé que no sé): ¿Qué no he considerado en absoluto? ¿Qué conocimiento desconozco? ¿Sé lo bueno que puede llegar a ser algo?
Los mejores programadores con agentes son buenos y tienen relativamente pocas incógnitas. Ver a alguien como Boris o Jarred escribir prompts me deja claro que saben exactamente lo que quieren. Están profundamente sincronizados tanto con la base de código como con los comportamientos del modelo.
Pero también asumen incógnitas. En muchos sentidos, reducir y planificar tus incógnitas es la habilidad de la programación con agentes. Pero por suerte, es una habilidad que puedes mejorar trabajando con Claude.
Ayuda a Claude a ayudarte
Instruir a Claude es un equilibrio delicado. Si eres demasiado específico, Claude seguirá tus instrucciones incluso cuando un giro sea más apropiado. Si eres demasiado vago, Claude a menudo tomará decisiones y suposiciones basadas en las mejores prácticas de la industria que podrían no ser adecuadas para tu tarea.
Cuando no tienes en cuenta tus incógnitas, fallas de ambas maneras. No sabes cuándo el camino estará lleno de obstáculos ni cuándo estará despejado, pero igual quieres que Claude se desvíe.
Claude puede ayudarte a descubrir tus incógnitas más rápido. Puede buscar en tu base de código y en internet extremadamente rápido, y sabe mucho más sobre el tema promedio que tú. También puede iterar a partir del fracaso más rápido.
La parte más importante de este proceso es darle a Claude contexto sobre tu punto de partida. Por ejemplo, cuéntale en qué parte de tu proceso de pensamiento te encuentras; revela tu experiencia con el problema y la base de código; y deja que trabaje contigo como un compañero de pensamiento.
Anteriormente he escrito sobre el uso de HTML con Claude, y en casi todos estos casos, un artefacto HTML es la mejor manera de visualizarlo y representarlo.
En este artículo detallo algunos de los patrones que uso para descubrir estas incógnitas. No uso todas las técnicas cada vez, pero es una colección útil de técnicas para tener a mano.
Pre-implementación
Análisis de puntos ciegos
Al comenzar un trabajo, una de las cosas más útiles que puedes hacer es comprender tus puntos ciegos. Por ejemplo, si estás escribiendo una función en una nueva parte de la base de código o usando Claude para ayudarte con un trabajo desconocido, como iterar sobre un diseño, es probable que tengas muchas unknown unknowns (incógnitas desconocidas).
Puede que no sepas qué preguntas hacer, cómo se ve algo bueno, qué trabajo histórico se ha realizado o qué obstáculos evitar.
Para esto, puedes pedirle a Claude que te ayude a encontrar tus unknown unknowns y te las explique. Me gusta usar las palabras literales "blindspot pass" y "unknown unknowns". Darle contexto sobre quién eres y qué sabes suele ser importante.
Ejemplos de prompts:
- «Estoy trabajando en agregar un nuevo proveedor de autenticación, pero no sé nada sobre los módulos de autenticación en esta base de código. ¿Puedes hacer un análisis de puntos ciegos para ayudarme a identificar mis unknown unknowns relevantes y ayudarme a darte un mejor prompt?»
- «No sé qué es la gradación de color, pero necesito gradar este video. ¿Puedes enseñarme a entender mis unknown unknowns sobre la gradación de color, para que pueda darte mejores prompts?»
Lluvias de ideas y prototipos
Cuando trabajo en un área con muchos unknown knowns (cosas que no sé que sé), criterios que solo sé definir cuando los veo, me gusta pedirle a Claude que haga una lluvia de ideas y prototipos conmigo.
Es extremadamente valioso identificar y verbalizar los unknown knowns temprano durante la creación de prototipos, porque descubrirlos durante la implementación puede ser (relativamente) costoso. Pequeños cambios en una función o especificación pueden provocar implementaciones drásticamente diferentes en el código, y puede ser más difícil para tu agente revertir cambios anteriores.
Por ejemplo, es posible que solo quieras ver cómo se ve un botón agregado a un marco sin tener que conectar una ruta de backend ni mantener un estado adicional en el frontend.
El diseño visual es algo que para mí es difícil de expresar, pero sé lo que quiero cuando lo veo. En estos casos, pido varios enfoques de diseño para un artefacto.
También empiezo casi todas las sesiones de codificación con una fase de exploración o lluvia de ideas. Esto me ayuda a comenzar con la intención de definir el alcance del proyecto. Claude suele encontrar enfoques de alto valor que yo habría pasado por alto y, a veces, no ve el bosque por los árboles. La lluvia de ideas evita que fije un alcance demasiado estrecho o demasiado amplio.
Ejemplos de prompts:
- «Quiero un panel de control para estos datos, pero no tengo gusto visual y no sé lo que es posible. Crea una página HTML con 4 direcciones de diseño radicalmente diferentes para que pueda reaccionar a ellas».
- «Antes de conectar nada, crea un único archivo HTML que simule la nueva barra de herramientas del editor con datos falsos. Quiero reaccionar al diseño antes de que toques la aplicación real.»
- «Este es mi problema aproximado: los usuarios abandonan después de la incorporación. Busca en la base de código y haz una lluvia de ideas de 10 lugares donde podríamos intervenir, desde el más barato hasta el más ambicioso. Te diré cuáles resuenan conmigo.»
Entrevistas
Una vez que he hecho suficiente lluvia de ideas, es probable que aún tenga incógnitas.
En ese caso, le pido a Claude que me entreviste sobre cualquier incógnita o ambigüedad. Al pedirle a Claude que te entreviste, intenta darle contexto sobre tu problema para guiar sus preguntas. Aquí hay algunos ejemplos.
Ejemplos de prompts:
- «Entrevístame una pregunta a la vez sobre cualquier cosa ambigua, prioriza las preguntas donde mi respuesta cambiaría la arquitectura.»
Referencias
A veces no puedes describir lo que quieres en detalle. Por ejemplo, es posible que no tengas el lenguaje o que sea tan complicado que te llevaría bastante tiempo.
En ese caso, la mejor respuesta es una referencia. Si bien puedes incluir diagramas, documentación o imágenes, la mejor referencia absoluta es el código fuente.
Si tienes una biblioteca que implementa algo de cierta manera o un componente de diseño que te gusta mucho, simplemente apunta a Fable a la carpeta y dile qué buscar, incluso si está en un lenguaje diferente.
Así es como funciona también Claude Design. No tienes que pasarle un archivo (aunque también puedes hacerlo). Puedes apuntarlo a un módulo en un sitio web que te guste, y lee el código subyacente, no solo la captura de pantalla. Esto proporciona un detalle mucho más rico sobre el marcado, la estructura y cómo se construye realmente el componente.
Ejemplos de prompts:
- «Esta crate de Rust en vendor/rate-limiter implementa exactamente el comportamiento de retroceso que quiero. Léela y reimplementa la misma semántica en nuestro cliente de API TypeScript.»
Planes de implementación
Cuando creo que estoy listo para implementar, suelo pedirle a Claude que elabore un plan de implementación para que lo revise, centrándome en las partes que podrían tener más probabilidades de cambiar, por ejemplo, para revisar modelos de datos, interfaces de tipo o flujos de UX. Esto permite que Claude saque a la luz cosas que podría necesitar modificar.
Ejemplos de prompts:
- «Escribe un plan de implementación en HTML, pero comienza con las decisiones que es más probable que modifique: cambios en el modelo de datos, nuevas interfaces de tipo y cualquier cosa orientada al usuario. Entierra la refactorización mecánica al final; confío en ti en esa parte.»
Durante la implementación
Notas de implementación
Una vez que estoy satisfecho con mi plan, abro una nueva sesión y paso los artefactos al prompt. Por ejemplo, podría pasar un archivo de especificaciones y un prototipo y pedirle a un agente que lo implemente.
Pero la verdad es que, por mucho que planifiques, siempre hay unknown unknowns al acecho. El agente puede descubrir durante su trabajo que necesita tomar un camino diferente debido a un caso límite que encontró en el código.
Le pido a Claude Code que mantenga un archivo temporal 'implementation-notes.md' (o .html) donde registre las decisiones que toma para que podamos aprender de nuestro próximo intento.
Ejemplos de prompts:
- «Mantén un archivo implementation-notes.md. Si te encuentras con un caso límite que te obligue a desviarte del plan, elige la opción conservadora, regístrala en 'Desviaciones' y continúa.»
Post-implementación
Presentaciones y explicaciones
Una de las partes más importantes de lanzar algo es obtener aprobación y aceptación. Crear artefactos de presentación y explicación en el documento final ayuda a:
- Acelerar la comprensión cuando los revisores comienzan con las mismas incógnitas que tú tenías.
- Acelerar las aprobaciones cuando los expertos quieren ver que tuviste en cuenta las incógnitas y los puntos de fallo comunes que ellos habrían anticipado.
Ejemplos de prompts:
- «Empaqueta el prototipo, la especificación y las notas de implementación en un solo documento que pueda publicar en Slack para obtener aprobación. Empieza con el GIF de demostración.»
Cuestionarios
Después de una larga sesión de trabajo, Claude podría haber logrado mucho más de lo que creía. Leer los diffs de código solo me da una comprensión superficial de lo que sucedió, ya que gran parte del comportamiento dependerá de las rutas de código existentes.
Pedirle a Claude que me examine sobre el cambio después de darme un montón de contexto me ayuda a entender lo que pasó. Solo fusiono los cambios después de aprobar el cuestionario a la perfección.
Ejemplos de prompts:
- «Quiero asegurarme de entender todo lo que ha sucedido en este cambio. Dame un informe HTML sobre los cambios para que lo lea y lo entienda, con contexto, intuición, lo que se hizo, etc., y un cuestionario al final sobre los cambios que debo aprobar sí o sí.»
Cómo se une todo: el lanzamiento de Fable
El video de lanzamiento de Fable fue editado completamente por Claude Code. Este era un dominio nuevo para mí y no soy para nada un experto.
Así que empecé con lo que sí sabía. Sabía que Claude podía usar código para editar videos y transcribirlos, pero no estaba seguro de si era lo suficientemente preciso. Luego le pedí a Claude que me explicara cómo funcionaba la transcripción, como Whisper, y si podría recortar con precisión cosas como los "ehms" o las pausas largas usando ffmpeg.
Quería que Claude creara una interfaz de usuario que estuviera sincronizada con las palabras que decía, pero no estaba seguro de que pudiera hacerlo, así que le pedí a Claude que creara un video prototipo usando Remotion y una transcripción para ver si funcionaba.
Finalmente, el video en sí se veía un poco apagado, lo cual sabía que era el resultado de la gradación de color, pero realmente no sabía qué era la gradación de color. Mi primer intento fue tratar de que Claude hiciera algunas variaciones para elegir, pero me di cuenta de que no sabía cómo se veía "bueno" en cuanto a gradación de color. Así que, en su lugar, le pedí a Claude que me enseñara sobre gradación de color para descubrir mis incógnitas.
Puedes ver una explicación más detallada sobre eso aquí.
Emparejar el mapa y el territorio
Cuanto mejores sean los modelos, más se puede lograr con el enfoque adecuado. Cuando una tarea de largo alcance sale mal, es probable que necesites dedicar más tiempo a definir tus incógnitas o a crear un plan de implementación que permita a Claude improvisar a través de ellas.
Cada explicación, lluvia de ideas, entrevista, prototipo y referencia es una forma económica de descubrir lo que no sabías antes de que sea costoso solucionarlo.
Así que comienza tu próximo proyecto pidiéndole a Claude que te ayude a encontrar tus incógnitas.
