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

Position in Journey

• Phase: Fase 3 — Resolver Problemas de Forma Sistemática
• Emotional goal: Método + consistencia. De improvisar cada tarea desde cero a tener un sistema para los tipos recurrentes — sabiendo que el sistema crece con el equipo, no se diseña de golpe.
• Cognitive goal: Plans como “prompts escalados”. Meta-prompts que generan otros prompts. Templates por tipo de tarea recurrente (chore, bug, feature como baseline). El repertorio de templates es emergente: se descubren nuevos tipos con la práctica, no se diseñan upfront.
• Key question: ¿Cómo convierto problemas recurrentes en procesos resueltos?

Terminal Objective

Crear templates reutilizables por tipo de tarea recurrente (chore, bug, feature como baseline) que agentes ejecutan de forma consistente en sus proyectos reales, comprendiendo que el repertorio crece con la práctica del equipo — no se diseña upfront.

Learning Objectives

• O1 (COMPRENDER): Dado que cada tarea requiere un prompt específico con contexto diferente, el participante explicará por qué escribir prompts individuales no escala y cómo los templates (meta-prompts) resuelven este problema codificando las prácticas de ingeniería comunes en una estructura reutilizable.
• O2 (ANALIZAR): Dados los tres templates base (chore, bug, feature) de la demo app, el participante identificará en cada uno las secciones estáticas (estructura, enfoque, validación) y las que se generan dinámicamente en la fase Plan, mapeando el patrón meta-prompt y el flujo Plan→Build con agentes frescos.
• O3 (APLICAR): Dado su proyecto real del equipo, el participante incorporará los tres templates base adaptándolos al stack y convenciones del equipo, produciendo al menos un plan que un agente ejecute de forma consistente.

Activities

Check-in

• Duration: 5 min
• Description: Ritual de apertura. “¿Cómo llegáis?” Ronda rápida — cómo se encuentra cada persona. Sin relación con el contenido de la sesión.
• Materials needed: —

Pregunta provocativa

• Duration: 3 min
• Description: “¿Vais a escribir un prompt nuevo para cada tarea, para siempre?” Conecta con S1: el prompt planificado resolvió UNA tarea. ¿Y la siguiente? ¿Y la de después? Dejar que la incomodidad aterrice en silencio. No responderla — la sesión la responde progresivamente.
• Materials needed: —

Recapitulación

• Duration: 5 min
• Description: Puente desde S2: “Ya sabéis dónde invertir — 12 puntos, perspectiva del agente. Pero saber dónde no basta. ¿Cómo convertís un problema recurrente en un proceso?”
• Materials needed: —

El problema: cada tarea, su prompt (MODELAR)

• Objective: O1
• Duration: 20 min
• Description: Apertura: “¿Qué tipos de tarea hacéis en vuestro día a día?” Ejemplos provocadores: 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: el prompt planificado funcionó para UNA tarea. ¿Y la siguiente? Comparar 2-3 tareas del mismo tipo → descubren que comparten estructura pero necesitan contexto diferente. Insight: cada tarea necesita su propio prompt, pero escribirlos a mano no escala.
• Materials needed: Pizarra para agrupar tipos de tarea

La solución: template + plan (MODELAR)

• Objective: O1, O2
• Duration: 25 min
• Description: Concepto: el template captura lo estático (prácticas de ingeniería comunes), la fase Plan genera lo dinámico (contexto específico). 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.
• Materials needed: Demo app TODO (rama S3), slides conceptuales (estático vs dinámico)

Lab Demo: anatomía de templates (PRACTICAR)

• Objective: O2

• Duration: 25 min

• Demo app branch: S3

• Description: Los participantes prueban los 3 templates con escenarios reales en la demo app rama S3. Para cada template, ejecutan solo la fase de planificación (template → plan generado) y analizan qué secciones son estáticas vs dinámicas. NO implementan — el foco es entender la anatomía del template y cómo genera planes:

  Escenario 1 — /bug: “Al marcar o desmarcar una tarea como completada, el cambio parece funcionar visualmente, pero al recargar la página la tarea vuelve a su estado original. Los cambios de completado no se persisten en el servidor.”

  • El facilitador ejecuta /bug en vivo como demo completa (input → /bug → plan → /implement → bug arreglado)
  • El grupo observa cómo el plan diagnostica (reproduce el bug, identifica root cause, propone fix, valida)
  • La metodología diagnóstica es universalmente reconocible — los participantes ven codificado lo que ya hacen mentalmente
  • Identifican secciones estáticas (metodología de debugging) vs dinámicas (archivos involucrados, causa específica)
  • Después, los participantes replican con el mismo input y examinan el plan generado

  Escenario 2 — /chore: “Añadir la gema annotaterb y configurarla para que todos los modelos tengan anotaciones sobre su esquema de base de datos”

  • Ejecutan /chore con este input
  • Examinan el plan generado: qué archivos identifica, qué dependencias detecta, qué pasos propone
  • Contraste con /bug: en /bug lo estático era una metodología; aquí lo estático es un checklist prescriptivo
  • Identifican secciones estáticas del template (estructura, enfoque de chore) vs dinámicas (contexto Rails, modelos específicos)
  • Bonus: annotaterb es en sí mismo un leverage point (Types/Documentation) — genera anotaciones de esquema que mejoran el contexto para agentes futuros

  Escenario 3 — /feature: “Añadir drag and drop a la lista de todos para poder reordenarla”

  • Ejecutan /feature con este input
  • Analizan el plan: cómo estructura frontend vs backend, qué validaciones incluye
  • Capstone: el template más complejo muestra la potencia completa del concepto
  • Identifican secciones estáticas (scaffold full-stack, validación cruzada) vs dinámicas (componentes React, endpoints Rails)

  Después de probar los 3 escenarios, el grupo mapea el patrón meta-prompt: un prompt que genera otro prompt. Pregunta de cierre: “¿Hay alguno de los leverage points de S2 que estemos activando aquí?” → Descubren que Templates y Plans son dos de los 12 puntos, y que trabajan juntos.

• Materials needed: Demo app TODO (rama S3), cada participante con portátil y Claude Code configurado contra la demo app

Incorpora templates a tu proyecto (APLICAR)

• Objective: O3
• Duration: 30 min
• Description: Framing del facilitador: “Estos tres templates (chore, bug, feature) son el baseline — cubren los tipos de tarea más comunes en cualquier proyecto. El objetivo hoy es incorporar estos tres. No intentéis diseñar todos los templates posibles.” Los equipos toman los templates de la demo app y los crean en su proyecto real, adaptándolos al stack y convenciones (Rails, Python, React). Guía del facilitador durante la actividad: “Si mientras trabajáis detectáis que hay un tipo de tarea que no encaja en ninguno de los tres, anotadlo — no lo templateéis ahora. Los nuevos tipos emergen con la práctica, como los modelos de datos de una aplicación: se descubren, no se diseñan upfront.” Momento definitorio del journey: lo que antes era artesanal ahora es un proceso. El alumno ve cómo un agente ejecuta de forma consistente.
• Materials needed: Proyecto real del equipo accesible, demo app como referencia

Reflexión / Resumen (REFLEXIONAR)

• Objective: O1, O2, O3
• Duration: 15 min
• Description: Puesta en común: ¿qué ha funcionado? ¿Qué no? ¿Por qué? Los equipos comparten su experiencia adaptando los templates. Discusión sobre qué ajustes fueron necesarios y qué aprendieron del proceso. El fallo productivo emerge naturalmente (templates necesitaron ajustes) → template quality = output quality. Pregunta: “¿Habéis detectado algún tipo de tarea que no encaje en chore/bug/feature? ¿Cuándo lo añadiríais?” → Refuerza que el repertorio crece con la práctica. 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?”
• Materials needed: Pizarra para anotar patrones comunes

Check-out

• Duration: 5 min
• Description: Ritual de cierre. “¿Cómo os vais?” Ronda rápida — cómo se va cada persona. Sin relación con el contenido de la sesión.
• Materials needed: —

Time Budget

Block	Duration	Activity
Check-in	5 min	Ritual: cómo se encuentra cada persona
Pregunta provocativa	3 min	”¿Vais a escribir un prompt nuevo para cada tarea, para siempre?”
Recapitulación	5 min	Puente desde S2: 12 puntos → ¿cómo sistematizar?
El problema: cada tarea, su prompt	20 min	MODELAR — debate + callback S1
La solución: template + plan	25 min	MODELAR — concepto + demo en vivo
Lab Demo: anatomía de templates	25 min	PRACTICAR — examinar 3 templates, mapear meta-prompt
Incorpora templates a tu proyecto	30 min	APLICAR — transferencia al proyecto real
Reflexión / Resumen	15 min	REFLEXIONAR — puesta en común + síntesis + semilla S4
Check-out	5 min	Ritual: cómo se va cada persona
Total planificado	133 min
Safety margin (13%)	17 min
Total sesión	150 min

Nota sobre el margen: El 13% de margen es el más ajustado del curso porque S3 dedica la mayoría del tiempo a práctica hands-on. El bloque de incorporar templates es el más crítico — momento definitorio del journey. Si falta tiempo, comprimir el bloque “El problema” (fusionando debate con inicio del bloque siguiente) antes que recortar lab demo o práctica.

Contenido prescindible (si falta tiempo):

• La recapitulación puede fusionarse con el inicio de “El problema”, ahorrando ~5 min
• La conexión con leverage points al final del lab demo puede mencionarse brevemente si el tiempo aprieta
• La reflexión puede comprimirse a 5 min (solo ronda rápida)

Materials Needed

• Pizarra/whiteboard: para debate de tipos de tarea (bloque 3) y patrones comunes (bloque 7)
• Slides: diagrama estático vs dinámico, flujo template→plan→implement
• Demo app TODO (Rails + React), rama S3, con:
  • 3 comandos predefinidos: /chore, /bug, /feature
  • 3 escenarios de prueba preparados:
    1. Bug: “Al marcar/desmarcar tarea como completada, el cambio no persiste al recargar”
    2. Chore: “Añadir la gema annotaterb y configurarla para que todos los modelos tengan anotaciones sobre su esquema de base de datos”
    3. Feature: “Añadir drag and drop a la lista de todos para poder reordenarla”
• Cada participante con portátil y Claude Code configurado contra la demo app
• Proyecto real del equipo accesible para la actividad de práctica (bloque 6)