Product Atelier

Construir con IA es fácil. Saber si funciona, no tanto.

Pones un agente o una feature con un LLM adentro, en la demo funciona perfecto… y después no hay forma de saber si de verdad funciona, ni si el próximo cambio de prompt rompió algo que antes andaba bien.

Ese salto de "parece que funciona" a "sé que funciona" tiene nombre: evals.

Un eval es una forma sistemática de medir la calidad de lo que produce tu IA. En vez de probar a ojo y cruzar los dedos, defines qué significa "bueno", armas un set de casos, y mides cada vez que cambias algo.

En este Atelier vamos a construir evals en vivo para una feature real con IA adentro:

• Definir el criterio: qué es una buena respuesta y qué es una mala.
• Armar el dataset: los casos que importan, incluyendo los que suelen fallar.
• LLM-as-judge: usar un modelo para evaluar a otro, y cuándo conviene confiar en eso.
• Medir y comparar: ver si un cambio de prompt mejora o rompe, con números en vez de intuición.

Para gente de producto esto es clave: los evals son la métrica de calidad de tus features de IA. Sin ellos, cada release es una apuesta.

Como siempre: sin slides, sin teoría de más. Construyendo en vivo.

¿Te sumas?

En encuentro previos surgió la inquietud de sumergirnos en Claude Design.

En este encuentro, Enrique Stiefkens nos va a llevar de la mano por un proceso que incluye Claude Design como core del discovery.

Enrique va a usar Claude Design en vivo, partiendo de una idea simple y llevándola hasta una app liviana con frontend y backend: landing, formulario, Supabase, login interno y dashboard con métricas. Esperamos cerrar el encuentro con el archivo y el prompt de handoff para pasar después a Claude Code o Codex.

Como siempre: construyendo en vivo.

¿Te sumas?

Una skill es un comportamiento empaquetado que Claude activa cuando lo necesita (y la misma skill funciona en Claude AI, en Cowork y en Claude Code).
Para gente de producto esto cambia las reglas. Lo que hoy resolvemos pegando prompts sueltos en mil lugares, pasa a ser una biblioteca de habilidades reutilizables que viaja con nosotros.
En el Atelier vamos a construir tres skills, en vivo, pensadas para el día a día de un PM:

• Evaluar feedback de usuarios: clasificar y sintetizar señales, no leer mil tickets.
• Detectar riesgos en una feature: sacar a la luz supuestos ocultos y las preguntas que faltan validar.
• Evaluar el impacto de una feature en el codebase: usar Claude Code para entender qué se toca, qué se rompe y qué cuesta, antes de prometer fechas.

Las creamos juntos, las probamos en los tres productos, y vemos qué cambia cuando tu stack de trabajo deja de ser "prompts sueltos" y pasa a ser un set de skills que te acompaña a todos lados.

Como siempre: sin slides, sin teoría de más. Construyendo en vivo.

¿Te sumas?

Fragmenta el problema, haz crecer la solución

Construir rápido ya no es el problema. Con agentes puedes tener un producto funcionando en horas.

El problema es saber por dónde cortar: qué construir primero, cuánto revelar, y qué aprender antes de dar el siguiente paso.

En este Atelier vamos a tomar un caso real y dividirlo en fases de exposición progresiva. Pero esta vez no vamos a estar solos: nos acompaña Alistair Cockburn, que acaba de publicar Slice the Problem, Grow the Solutio, un compendio revisado sobre todas sus ideas y propuestas acerca de cómo fragmentar una iniciativa, lanzar cada parte al mundo real, y ajustar sobre la marcha.

Alistair trae más de veinte años pensando en cómo se divide un problema para que la solución crezca bien. Nosotros traemos agentes, specs y las herramientas de hoy. La idea es juntar las dos cosas: hacer el slicing en vivo, discutir cada decisión, y ver qué pasa cuando el criterio clásico de desarrollo se encuentra con la velocidad que tenemos ahora.

Sin slides. En vivo. Construyendo y discutiendo.

¿Te sumas?

Learn-Driven Development

Con agentes podemos construir una feature completa en una hora. Rehacerla en otra. Correr cien experimentos en una semana.

El problema es que los usuarios no se aceleraron al mismo ritmo. Cuanto más enviamos, menos aprendemos.

La respuesta obvia ("construir en slices finos") tiene su propia trampa cuando el que codea es un agente: cada slice lo obliga a reconstruir el contexto desde cero, y ahí aparece el drift que no ves hasta que miras el conjunto.

Learn-Driven Development separa dos ritmos que antes eran uno:

1. Construir la feature entera, en una sola pasada coherente donde el agente tiene todo el contexto.

2. Revelarla a los usuarios en tus términos, con flags, rollout progresivo, canary releases.

El incremento de build y el incremento de feedback se desacoplan. El aprendizaje validado (no la feature entregada) vuelve a ser la unidad de progreso.

En el Atelier vamos a tomar un caso real y recorrerlo completo: cómo se construye entero, cómo se planea la exposición progresiva, y qué aprendemos en cada nivel antes de abrir el siguiente.

Sin slides. En vivo. Decidiendo juntos qué mostrar, cuándo, y a quién.

¿Te sumas?

Superpowers multiplica x10 el valor que te da Claude Code y la mayoría de la gente de producto todavía no sabe qué es. Bueno, en el atelier, lo arreglamos. ;-)

Superpowers no es "otro plugin de Claude Code". Es un método de desarrollo con Spec-Driven Development, empaquetado como skills que el agente activa automáticamente.

En el Atelier lo vamos a instalar, lo vamos a usar con un caso real, y vamos a discutir qué cambia cuando el workflow deja de ser "prompt → código" y pasa a ser "spec → plan → subagentes → review".

Sin slides. Sin teoría de más. Construyendo en vivo.

¿Te sumas?

En el encuentro anterior a este, refinamos la UI e incorporamos progresivamente un nuevo feature.

Ahora vamos a hacer hacer crecer el producto. Esta vez el foco está en dos cosas concretas:

Incorporar componentes externos: conectarlo a APIs, incorporar librerías de terceros (especialmente para la visualización de mapas).

Evaluación con IA: Este paso es un game changes, vamos a integrarnos con un LLM para evaluar datos del usuario con IA y realizar un diagnóstico de la situación y sugerencias de mejora.

Como siempre: en vivo, sin guion. Si algo se rompe, lo arreglamos ahí. Si aparece una decisión interesante, nos detenemos a discutirla.

Ideal para quienes estuvieron en el Encuentro #03, pero también para quienes quieren ver cómo se itera un producto real bajo este modelo moderno de trabajo.

En el encuentro anterior a este, arrancamos desde cero: una idea, una especificación, un prototipo funcional.

Ahora vamos a hacer lo que pasa en la realidad: iterar.

Vamos a retomar el producto donde lo dejamos y llevarlo más lejos. Esta vez el foco está en dos cosas concretas:

Refinar la UI: no como ejercicio estético, sino como decisión de producto. Qué cambiar, por qué, y cómo traducir eso en specs que un agente pueda ejecutar sin ambigüedad.

Desarrollo progresivo de specs: en lugar de una construcción monolítica, vamos a ir construyendo un spec de forma incremental. Cada cambio parte de lo que ya existe, se planifica con precisión y se implementa. Vas a ver cómo se gestiona esa conversación entre intención y ejecución cuando el producto ya tiene forma.

Como siempre: en vivo, sin guion. Si algo se rompe, lo arreglamos ahí. Si aparece una decisión interesante, nos detenemos a discutirla.

Ideal para quienes estuvieron en el Encuentro #03, pero también para quienes quieren ver cómo se itera un producto real bajo este modelo moderno de trabajo.

En este encuentro del Atelier de Producto vamos a empezar algo simple: construir un producto desde cero.

Sin slides y sin teoría abstracta.

En vivo.

Partiremos de una idea inicial y la iremos transformando paso a paso en algo que funcione.

Durante la sesión vamos a trabajar con Spec-Driven Development y Claude Code, explorando cómo pasar de una intención de producto a una especificación clara y de ahí a un prototipo funcional.

El objetivo no es solo que el sistema funcione.

Es ver cómo se toman decisiones cuando:

• el problema todavía está abierto
• las herramientas hacen posible construir más rápido
• pero el criterio sigue siendo necesario.

A lo largo del encuentro iremos definiendo:

• el problema que queremos resolver
• la estructura de la especificación
• cómo se traduce esa especificación en código
• y qué decisiones aparecen en el camino.

Como siempre en el Atelier, nada está completamente guionado.
Si algo falla, lo corregimos en vivo. Si aparecen alternativas, las discutimos.

Porque muchas veces la parte más interesante del trabajo está en las decisiones intermedias.

Vamos a rediseñar un agente monolítico, dividiéndolo en múltiples agentes especializados trabajando en paralelo.

Verás cómo distribuir la inteligencia mejora la velocidad, precisión y escalabilidad de tu producto.

Lo que vas a aprender:

1. Cuándo dividir vs. mantener un agente único
2. El patrón de procesamiento en paralelo
3. Beneficios reales para tu roadmap de producto

Ideal para: PMs, founders, y cualquiera diseñando productos con IA.

Si tu producto/agente de IA usa el mismo modelo para responder todo:
Puedes estar quemando dinero y ofreciendo una experiencia mediocre.

El patrón de Ruteo resuelve esto:

Una primera llamada al LLM clasifica la intención, urgencia y complejidad.

Luego, el sistema decide qué camino tomar.

El resultado:

1. Consulta simple → Modelo pequeño + prompt de FAQs
2. Seguimiento estándar → Modelo medio + acceso a logística
3. Caso urgente → Modelo potente + herramientas de contingencia + re-routing
4. Reembolso → Modelo capaz + políticas + autorización de refunds

Mismo input del usuario, pero diferentes solicitudes, entonces: cuatro experiencias completamente diferentes.

¿Por qué importa?
No es solo ahorro de costos (que lo hay, y mucho). Es que cada tipo de problema requiere un tipo de razonamiento, un tono y unas herramientas distintas.

Un cliente preguntando el horario no necesita empatía de crisis. Un cliente con
un pedido perdido hace 10 días sí.

NOS VEMOS ESTA NOCHE y lo construimos en vivo.

Vamos a armar este patrón desde cero en n8n. Sin slides, sin teoría de más.