Session Escaleta: S3 - Resolver Problemas de Forma Sistemática

Position in Journey

Phase: Fase 3 — Resolver Problemas de Forma Sistemática
Key question: ¿Cómo convierto problemas recurrentes en procesos resueltos?
Terminal objective: Crear templates reutilizables por tipo de problema recurrente que agentes ejecutan de forma consistente en sus proyectos reales

Key Concepts

Cada tarea necesita su propio prompt — Tareas del mismo tipo (ej: “nueva feature”) parecen iguales pero no lo son: una toca HTML y necesita el sistema de diseño, otra toca BD y necesita el esquema. Cada tarea requiere un prompt específico con el contexto correcto. Escribirlos a mano no escala.
Templates: la parte estática — Lo que SÍ es común entre tareas del mismo tipo: estructura del plan, enfoque de ingeniería, secciones de validación. El template codifica estas prácticas compartidas en un meta-prompt: un prompt que genera otro prompt. Tres tipos base (chore, bug, feature) cubren la mayoría de problemas recurrentes en cualquier proyecto.
Plan → Build: la parte dinámica — La fase Plan es donde la IA genera lo que cambia entre tareas: qué archivos tocar, qué contexto leer, qué dependencias considerar. El humano diseña el template una vez; la IA genera el plan específico para cada tarea concreta. Dos agentes, dos contextos frescos.
Plans = prompts escalados — El plan generado ES el prompt que el agente de implementación ejecuta. Gran planificación = gran prompting. Pero ahora el humano no escribe cada plan — diseña el template y la IA se encarga del resto.
Templates customizados = ingeniería diferenciada — Cuanto más específico el template al dominio (convenciones Rails, patrones de API, estructura de BD), mejores los resultados. Un template genérico produce output inconsistente. La calidad del template determina la calidad del output.

Session Flow

#	Block	Type	Description	Key Concepts	~Duration
1	Check-in	—	Ritual: cómo se encuentra cada persona	—	~5 min
2	Pregunta provocativa	—	“¿Vais a escribir un prompt nuevo para cada tarea, para siempre?”	—	~3 min
3	Recap	—	Puente desde S2: ya sabéis dónde invertir (12 puntos, perspectiva del agente). “Pero saber dónde no basta — falta saber cómo. ¿Cómo convertís un problema recurrente en un proceso?”	—	~5 min
4	El problema: cada tarea, su prompt	MODELAR	Apertura: “¿Qué tipos de tarea hacéis en vuestro día a día?” Ejemplos para provocar: cambios de diseño, scripts de BD, funcionalidad nueva, actualizar libs, bugs… El grupo identifica que cada tipo activa un “modo de pensar” diferente. Callback a S1: en la primera sesión vimos un prompt planificado para una tarea concreta. Ese prompt funcionó — pero ¿y la siguiente? El grupo compara 2-3 tareas del mismo tipo y descubre que cada una necesita contexto diferente (diseño, esquema BD, endpoints) aunque comparten estructura y enfoque. Insight: cada tarea necesita su propio prompt, pero escribirlos a mano no escala.	1	~20 min
5	La solución: template + plan	MODELAR	Concepto: el template captura lo estático (prácticas de ingeniería comunes), la fase Plan genera lo dinámico (contexto específico de cada tarea). El plan resultante ES el prompt escalado. Demo en vivo: el facilitador ejecuta el flujo completo en la demo app — descripción de un bug → template /bug genera plan diagnóstico → /implement ejecuta y arregla el bug. Los participantes ven cómo la IA rellena las secciones dinámicas que antes tendrían que escribir a mano.	2, 3, 4	~25 min
6	Lab Demo: anatomía de templates	PRACTICAR	Los participantes examinan y prueban los 3 templates (/bug, /chore, /feature) en la demo app rama S3. Para cada uno: qué secciones son estáticas, qué genera dinámicamente la fase Plan, qué validación incluye. Mapean el patrón meta-prompt. Pregunta de cierre: “¿Hay alguno de los leverage points que vimos en la sesión anterior que estemos activando aquí?” El grupo descubre que Templates y Plans son dos de los 12 puntos — y que trabajan juntos: el template es el prompt que planifica, el plan es el prompt que construye.	2, 3	~25 min
7	Incorpora templates a tu proyecto	APLICAR	Los equipos toman los templates de la demo app (chore, bug, feature) y los crean en su proyecto real, adaptando lo necesario a su stack y convenciones. Si detectan que necesitan algún tipo de plan adicional específico de su equipo, lo crean también. El objetivo principal: incorporar estos tres tipos, que son suficientemente generales para cualquier proyecto.	2, 5	~30 min
8	Reflexión / Resumen	REFLEXIONAR	Puesta en común: ¿qué ha funcionado? ¿Qué no? ¿Por qué? Los equipos comparten su experiencia adaptando los templates. Síntesis: “Lo que antes era artesanal ahora es un proceso. Y los procesos escalan.” Semilla S4: “Tenéis procesos consistentes, pero todavía estáis supervisando… ¿pueden hacerlo sin que estéis?“	5	~15 min
9	Check-out	—	Ritual: cómo se va cada persona	—	~5 min

Lab Demo

Sí. Dos momentos hands-on con la demo app (TODO app Rails+React), rama S3:

Demo del facilitador (bloque 4): ejecuta el flujo template → plan → implement en vivo. El grupo ve cómo la IA genera las secciones dinámicas del plan (contexto, archivos, dependencias) a partir del template estático.
Análisis de participantes (bloque 5): examinan los 3 templates (chore/bug/feature), identificando el patrón meta-prompt y la estructura que después replicarán en sus proyectos.

Practica en Proyecto

Sí. Los equipos toman los templates de la demo app (chore, bug, feature) y los incorporan a su proyecto real, adaptándolos a su stack y convenciones (bloque 6). Es el momento definitorio del journey: lo que antes era artesanal ahora es un proceso. Si detectan necesidad de templates adicionales específicos de su equipo, los crean también.

Notes

La pregunta provocativa (“¿Vais a escribir un prompt nuevo para cada tarea, para siempre?”) conecta con S1 (el prompt planificado resolvió UNA tarea) y genera la tensión que la sesión resuelve progresivamente.
El callback a S1 (bloque 4) ancla el problema en algo que ya vivieron: el prompt planificado de la primera sesión resolvía UNA tarea. ¿Y la siguiente? La tensión “cada tarea necesita su propio prompt, pero no puedes escribirlos todos” motiva toda la sesión.
El momento definitorio (del journey) ocurre en el bloque 6: el alumno incorpora templates a su proyecto real y ve cómo un agente ejecuta de forma consistente lo que antes era artesanal.
La reflexión (bloque 7) es abierta: qué funcionó, qué no, por qué. El fallo productivo puede emerger naturalmente (templates necesitaron ajustes), pero el foco es aprendizaje compartido, no provocar frustración.
La demo (bloque 4) es más efectiva integrada con el concepto: primero la idea (estático vs dinámico), inmediatamente la prueba visual. No separar concepto de demo.
chore/bug/feature son el baseline: son suficientemente generales para cualquier proyecto. El bloque 6 los incorpora directamente a los proyectos reales. Si el equipo detecta tipos adicionales, los crea, pero el primer objetivo es adoptar estos tres.
El margen de ~20 min permite extender el bloque 6 (incorporar templates) si los equipos necesitan más tiempo — es el bloque más crítico.
Si falta tiempo, comprimir bloque 3 (fusionando debate con inicio de bloque 4) antes que recortar bloques 5-6.
Conexión S2→S3 por descubrimiento (bloque 5): la conexión con los leverage points NO se da de entrada — emerge como pregunta al final del lab demo, después de que los alumnos hayan examinado y probado los templates. “¿Hay alguno de los leverage points de S2 que estemos activando?” Descubren que Templates y Plans son dos puntos del mapa que trabajan juntos: el template es el prompt del agente que planifica, el plan es el prompt del agente que construye.
HOPs (Higher Order Prompts) se mencionan tangencialmente en la demo (/implement como HOP que recibe un plan), pero no se formalizan como concepto clave. Queda para profundizar si el grupo tiene nivel para absorberlo.