¿One-shot prompting? Prefiero conversar con mi IA
Publicado el 🤖 Si quieres que tu IA lea este post, descárgaselo como markdown.
Hace unos días, en una conversación con compañeros, surgió el debate sobre la utilidad del one-shot prompting a la hora de generar código con IA. Yo defendía que no lo es, y el argumento que usé creo que merece ser compartido.
El problema del one-shot como objetivo
Cuando asumimos que el one-shot puede darnos los resultados esperados, estamos cargando toda la responsabilidad de la calidad del output en la parte humana: si el LLM no produce una buena respuesta, el problema es que no escribimos el prompt correcto.
Pero esta idea choca frontalmente con la naturaleza de la IA generativa, que es no-determinista. Para un mismo prompt y modelo, obtenemos respuestas diferentes en cada ejecución. Por tanto, resulta imposible —sobre todo con tareas complejas— obtener la respuesta óptima en una sola interacción. La iteración se vuelve ineludible.
En ese debate, con pequeños matices, todos coincidíamos en que el one-shot no es válido como fin en sí mismo, sino como ejercicio para mejorar nuestros prompts. Es imposible alcanzar el 100% de calidad, pero con esta práctica aprendemos a pasar, por decir algo, del 60% al 70%.
De Figma al código: otra perspectiva
Este fin de semana leí The only AI workflow I use in production, de Tommy Geoco. El artículo describe el flujo que Tommy utiliza para desarrollar su trabajo de diseño asistido por IA (Figma → Claude Code), afirmando que supera en términos absolutos al uso de otras herramientas como Lovable, Replit o Bolt. Si eres diseñador UX/UI interesado en la integración de IA en tu trabajo, te recomiendo leerlo porque contiene ideas realmente interesantes.
Entre esas ideas hay una que me ha hecho reflexionar de nuevo sobre la inconveniencia del one-shot. Según el autor, debemos desmitificarlo porque no captura el valor real. La verdadera potencia no está en la generación inicial, sino en las iteraciones posteriores.
Su flujo de trabajo es el siguiente:
- Diseñar el "happy path" (flujo óptimo) en Figma
- Alimentar el diseño a Claude Code vía Figma MCP
- Obtener una base sólida en 15 minutos (vs. 50 horas de codificación manual)
- Iterar y refinar durante 50 horas
El último punto es clave para él: la iteración no es desarrollo, es trabajo de diseño. No se trata de refinar el código para representar un diseño cerrado, sino con él tomar decisiones sobre jerarquía visual, patrones de interacción, casos extremos, estados de error, etc.
¿Y si el valor está en la iteración?
De aquí saco dos conclusiones igualmente importantes. La primera: el autor está trasladando gran parte del ejercicio de diseño de Figma al código, algo novedoso que desdibuja la frontera UX/UI-Desarrollo. No voy a desarrollarla aquí para no desviarme del tema, pero merece un post propio.
La segunda, relacionada con el debate sobre one-shot: el autor no usa la IA para que diseñe por él en base a unas instrucciones iniciales, sino que se apoya en ella para iterar más rápido, reflexionar sobre el diseño de manera más profunda y conseguir un mejor resultado. Creo que no solo porque la IA le ahorra tiempo de trabajo repetitivo sin valor y lo gana para pensar, sino porque el diálogo generado puede llevarlo a lugares, pensamientos y decisiones a los que solo no habría llegado.
Queda por ver si este esquema se traslada igual al desarrollo de software, pero si funciona de manera similar, entonces la inconveniencia del one-shot no se debe únicamente a las limitaciones que nos impone la naturaleza no-determinista de los LLMs. Hay algo más importante: la iteración —ese diálogo continuado entre humano e IA— nos proporciona valor real, obtenemos mejores resultados.
Esta idea de la iteración como diálogo me ha hecho recordar los planteamientos sobre cocreación humano–IA de Owen Matson. Y tengo que reconocer que ha sido escribiendo este post —en diálogo con una IA— cuando creo que finalmente he entendido lo que Owen plantea. Queda pendiente profundizar en esta vía 🙂