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 por hacer, son mis prompts, habilidades y contexto, es lo que le doy a Claude. El territorio es donde debe ocurrir el trabajo: el código base, el mundo real, sus limitaciones reales.
La diferencia entre el mapa y el territorio es lo que llamo incógnitas. Cuando Claude se encuentra con una incógnita, necesita tomar una decisión basada en su mejor suposición de lo que quiero. Cuanto más trabajo se haga, más incógnitas podría encontrarse Claude.
Fable es el primer modelo en el que la calidad del trabajo se ve limitada por mi capacidad para aclarar sus incógnitas.
Es importante destacar que planificar con anticipación no siempre es suficiente. Puedes encontrar incógnitas en medio de la implementación, o tus incógnitas pueden indicarte que en realidad deberías estar resolviendo 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 ejemplos de artefactos para encontrar incógnitas aquí, pero asegúrate de volver para desarrollar la intuición sobre cuándo usarlos.
Conociendo tus incógnitas
¿Cuáles son tus incógnitas? Cuando acudo a Claude con un problema, tiendo a desglosarlo de 4 maneras:
- Conocidas conocidas: Esto es esencialmente lo que está en mi prompt. ¿Qué le digo al agente que quiero?
- Conocidas desconocidas: ¿Qué no he resuelto todavía, pero soy consciente de que no lo he hecho?
- Desconocidas conocidas: ¿Qué es tan obvio que nunca lo escribiría, pero lo reconocería si lo viera?
- Desconocidas desconocidas: ¿Qué no he considerado en absoluto? ¿Qué conocimiento no conozco? ¿Sé lo bueno que algo puede llegar a ser?
Los mejores codificadores agentivos tienen relativamente pocas incógnitas. Al ver a alguien como Boris o Jarred dar prompts, es obvio para mí que saben exactamente lo que quieren. Están profundamente sincronizados tanto con el código base 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 codificación agentiva. Pero afortunadamente, es una habilidad que puedes mejorar trabajando con Claude.
Ayuda a Claude a ayudarte
Dar instrucciones a Claude es un equilibrio delicado. Si eres demasiado específico, Claude seguirá tus instrucciones incluso cuando un cambio de rumbo 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 pueden no ser adecuadas para tu tarea.
Cuando no consideras tus incógnitas, fallas de ambas formas. No sabes cuándo el camino estará lleno de obstáculos ni cuándo estará despejado, pero aun así quieres que Claude se desvíe.
Claude puede ayudarte a descubrir tus incógnitas más rápido. Puede buscar en tu código base 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 el código base; y deja que trabaje contigo como un compañero de ideas.
Ya he escrito anteriormente sobre cómo usar HTML con Claude. 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
Revisión de puntos ciegos
Al comenzar un trabajo, una de las cosas más útiles que puedes hacer es entender tus puntos ciegos. Por ejemplo, si estás escribiendo una función en una parte nueva del código base o usando Claude para ayudarte con trabajo desconocido como iterar sobre un diseño, es probable que tengas muchas incógnitas desconocidas.
Puede que no sepas qué preguntas hacer, cómo se ve lo bueno, qué trabajo histórico se ha realizado o qué obstáculos evitar.
Para hacer esto, puedes pedirle a Claude que te ayude a encontrar tus incógnitas desconocidas y te las explique. Me gusta usar las palabras literales “blindspot pass” e “incógnitas desconocidas”. Darle contexto sobre quién eres y lo que sabes suele ser importante para
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 este código base. ¿Puedes hacer una revisión de puntos ciegos para ayudarme a descubrir mis incógnitas desconocidas relevantes y ayudarme a darte mejores prompts?”
- “No sé qué es la corrección de color, pero necesito corregir este video. ¿Puedes enseñarme a entender mis incógnitas desconocidas sobre la corrección de color para que pueda darte mejores prompts?”
Lluvias de ideas y prototipos
Cuando trabajo en un área con muchas desconocidas conocidas, que involucra 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 las desconocidas conocidas temprano durante la creación de prototipos, porque descubrirlas durante la implementación puede ser (relativamente) costoso. Pequeños cambios en una función o especificación pueden causar 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 configurar una ruta de backend o mantener 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, pediré 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 a menudo encuentra 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 establezca un alcance demasiado estrecho o demasiado amplio.
Ejemplos de prompts:
- “Quiero un panel para estos datos, pero no tengo gusto visual y no sé lo que es posible. Hazme una página HTML con 4 direcciones de diseño radicalmente diferentes para que pueda reaccionar a ellas.”
- “Antes de conectar cualquier cosa, haz un solo archivo HTML simulando 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 general: los usuarios abandonan después de la incorporación. Busca en el código base 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.”
Entrevistas
Una vez que he hecho suficiente lluvia de ideas, es probable que aún tenga incógnitas.
En este 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 vocabulario o que sea tan complicado que te tomaría bastante tiempo.
En este 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 librería 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 otro idioma.
Esta es también la forma en que funciona 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 detalles mucho más ricos 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 el comportamiento de retroceso exacto que quiero. Léela y reimplementa la misma semántica en nuestro cliente de API de TypeScript.
Planes de implementación
Cuando creo que estoy listo para implementar, suelo pedirle a Claude que prepare un plan de implementación para que lo revise, que se centre en las partes que tienen más probabilidades de cambiar, por ejemplo, revisar modelos de datos, interfaces de tipos o flujos de UX. Esto permite que Claude saque a relucir 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 ajuste: cambios en el modelo de datos, nuevas interfaces de tipo y cualquier cosa que enfrente el 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, creo una nueva sesión y paso cualquier artefacto 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 no importa cuánta planificación hagas, siempre hay incógnitas desconocidas al acecho. El agente puede descubrir durante su trabajo que necesita tomar un rumbo 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 encuentras un caso límite que te obligue a desviarte del plan, elige la opción conservadora, regístralo bajo 'Desviaciones' y continúa.”
Post implementación
Presentaciones y explicaciones
Una de las partes más importantes de lanzar algo es obtener aceptación y aprobaciones. Crear artefactos de presentación y explicación en el documento final ayuda:
- Acelerar la comprensión cuando los revisores comienzan con las mismas incógnitas que tú
- Acelerar las aprobaciones cuando los expertos quieren ver que tomaste en cuenta las incógnitas y los puntos de falla comunes que ellos habrían anticipado
Ejemplos de prompts:
- “Empaqueta el prototipo, las especificaciones y las notas de implementación en un solo documento que pueda compartir en Slack para obtener aceptación. Comienza con el GIF de demostración.”
Cuestionarios
Después de una larga sesión de trabajo, es posible que Claude haya logrado mucho más de lo que me di cuenta. Leer los diffs del código solo puede darme 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 sucede. Solo fusiono después de aprobar el cuestionario perfectamente.
Ejemplos de prompts:
- “Quiero asegurarme de entender todo lo que ha sucedido en este cambio. Dame un informe HTML sobre los cambios para que los lea y entienda con contexto, intuición, lo que se hizo, etc., y un cuestionario al final sobre los cambios que debo aprobar.”
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 de ninguna manera un experto.
Así que comencé 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 'ums' o las pausas grandes usando ffmpeg.
Quería que Claude creara una interfaz de usuario que estuviera sincronizada con las palabras que estaba diciendo, pero no estaba seguro de si podría 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 se veía un poco apagado, lo que sabía que era el resultado de la corrección de color, pero realmente no sabía qué era la correcció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" cuando se trataba de corrección de color. Así que, en lugar de eso, le pedí a Claude que me enseñara sobre corrección de color para descubrir mis incógnitas.
Puedes ver una explicación más detallada de eso aquí.
Emparejando el mapa y el territorio
Cuanto mejores se vuelven los modelos, más puedes lograr con el enfoque correcto. Cuando una tarea de largo plazo sale mal, es probable que necesites pasar más tiempo definiendo tus incógnitas o creando 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 barata 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.
