S4: Afk

Design: Revisar
← Escaleta Ver Slides →

Session Design: S4 - Autonomía Real (AFK)

Position in Journey

  • Phase: Fase 4 — Autonomía Real (AFK)
  • Emotional goal: Vértigo + asombro. Soltar el control es incómodo, pero el resultado es liberador.
  • Cognitive goal: Los cuatro elementos de un flujo autónomo: Prompt input, Trigger, Environment, Review. In-loop vs out-of-loop. ADWs como unidades reutilizables de trabajo agéntico. Evolución de la orquestación: de manual a código a IA.
  • Key question: ¿Pueden los agentes funcionar sin que el humano esté en el bucle?

Terminal Objective

Configurar un agente autónomo identificando los cuatro elementos (Prompt input, Trigger, Environment, Review) que complete una tarea real sin intervención humana.

Learning Objectives

  • O1 (COMPRENDER): Dado que hasta ahora han trabajado in-loop (presentes, corrigiendo, iterando), el participante explicará la diferencia entre trabajo in-loop y out-of-loop, identificando qué necesita el agente para funcionar sin supervisión humana.
  • O2 (ANALIZAR): Tras ejecutar un ADW end-to-end en la demo app, el participante descompondrá su funcionamiento identificando los 4 elementos de un flujo autónomo (Prompt input, Trigger, Environment, Review) y reconociendo las templates de S3 (/chore, /bug, /feature, /implement) embebidas dentro del flujo.
  • O3 (APLICAR): Dado un chore real de su backlog Jira, el participante configurará y ejecutará su primer flujo AFK aplicando los cuatro elementos: seleccionando el Prompt input (templates de S3 adaptadas), configurando Trigger manual, asignando Environment (rama dedicada), y validando con Review (tests + MR en GitLab).

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: “¿Cuántas horas a la semana pasáis supervisando lo que un agente ya sabe hacer?” 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 S3: “Tenéis templates que sistematizan el trabajo — chore, bug, feature. Pero seguís ahí, mirando. Hoy vamos a hacer que funcionen sin vosotros.”
  • Materials needed: —

De in-loop a out-of-loop (MODELAR)

  • Objective: O1
  • Duration: 10 min
  • Description: El facilitador presenta los dos modos de trabajo agéntico. In-loop: estás presente, corriges, iteras (lo que han hecho hasta ahora). Out-of-loop: lanzas, te vas, vuelves. Pregunta al grupo: “¿Qué necesita el agente para funcionar sin vosotros?” Recogida de ideas en pizarra. Cierre: “Vamos a probarlo. Ahora.”
  • Materials needed: Pizarra para recoger ideas del grupo

Lab Demo: Lanzamos ADWs (PRACTICAR)

  • Objective: O1, O2

  • Duration: 25 min

  • Demo app branch: S4

  • Description: Momento definitorio de la sesión. Dos demos en los forks de cada participante, con dos triggers diferentes:

    Demo A — trigger manual (~12 min): Todos lanzan adws/bin/adw_plan_build <issue> en su fork con el issue “Diálogo de confirmación al borrar tarea”. Primer AFK colectivo. Mientras ejecuta, el facilitador narra las fases del pipeline: classify → branch → plan → implement → commit → PR. Nadie toca nada. Al verificar el PR, comprueban que el agente completó trabajo real sin intervención. Momento “wow” colectivo.

    Demo B — trigger cron (~12 min): Todos arrancan adws/bin/trigger_cron en su fork. Activan el issue “Tareas completadas al final con separador y estilos” (comment “adw” en el issue). El cron lo detecta (~20s) y lanza el pipeline automáticamente — nadie lanza nada esta vez. Verifican el segundo PR. “La primera vez fuimos nosotros el trigger. Esta vez es código.”

    Post-verificación (~3 min): Dos PRs, mismo pipeline, diferente trigger. “¿Qué cambió? Solo quién lo arranca.” + “El PR es una propuesta. El flujo es absolutamente arbitrario — nosotros decidimos si vale.”

  • Materials needed: Fork propio de la demo app TODO (rama S4) por cada participante, portátil con Claude Code configurado, dos issues preparados por fork (“Diálogo de confirmación” y “Tareas completadas al final”)

Anatomía de un ADW (MODELAR)

  • Objective: O2
  • Duration: 27 min
  • Description: Con la experiencia fresca de ambos triggers, el facilitador recorre el código del ADW (adws/bin/adw_plan_build + adws/bin/trigger_cron) y lo descompone en los 4 elementos. Ancla: “Habéis usado dos triggers distintos. Mismo pipeline. ¿Qué cambió? Solo el Trigger.” Prompt input (qué alimenta el trabajo — un issue), Trigger (qué lo arranca — manual o cron, como acaban de vivir), Environment (dónde opera — rama dedicada), Review (cómo se valida — tests, PR, comentarios). Observaciones durante el code walkthrough:
    • “¿Dónde está la IA en este código?” → Solo en los agentes. La orquestación es Ruby puro, determinista.
    • “Cada instancia de Claude es un agente diferente con contexto fresco — ya estáis haciendo multi-agente sin saberlo.”
    • “Este flujo classify→plan→implement→commit→PR es absolutamente arbitrario. Vuestro equipo decide si vale o diseña otro.” Pregunta clave: “¿Cuáles de las templates de S3 reconocéis dentro del ADW?” → Descubren que /chore, /bug, /feature y /implement están embebidos. Estos cuatro elementos dan el vocabulario para diseñar sus propios ADWs. Cierre del bloque: el facilitador nombra los tres niveles de orquestación vividos — comando a comando (S1-S3), nosotros como orquestadores (Demo A), código como orquestador (Demo B/ADW). Señala la limitación: el código es rígido, supone que podemos prever todos los casos del desarrollo de software. Pregunta: “¿Cuál sería el siguiente paso lógico?” Reflexión guiada → orquestación dirigida por IA. Cierre: estado del arte emergente, muy verde — ahí se mueve la frontera.
  • Materials needed: Demo app código fuente del ADW (adws/), slides con diagrama Prompt-Trigger-Environment-Review

/prime:adw — Trabajar EN el ADW (MODELAR)

  • Objective: O2

  • Duration: 7 min

  • Description: Insight de cierre del bloque de orquestación. Llevamos tres sesiones diciendo que el vibe coding no escala — aquí la excepción: cuando el equipo trabaja ON el ADW (customizar el pipeline, cambiar el classify, añadir un paso), el trabajo es exploratorio/arquitectural. Ahí el vibe coding ES la herramienta correcta.

    Pero el agente necesita entender el codebase del ADW para ayudar. /prime:adw da ese contexto antes de explorar o modificar. Esta es la demostración más concreta de por qué existen los comandos de tipo prime: no solo para la app, sino para cualquier dominio que el agente vaya a explorar.

    Regla final: AFK para el código de la aplicación (lo que el ADW procesa). Vibe coding + /prime:adw para diseñar la propia capa de orquestación.

    Si falta tiempo, comprimir a 4 min: suprimir la pregunta inicial e ir directo a la tabla + regla.

  • Materials needed: —

Practica en Proyecto: AFK en tu proyecto (APLICAR)

  • Objective: O3
  • Duration: 30 min
  • Description: Los equipos diseñan y ejecutan su primer flujo AFK con un chore real de su backlog Jira. Paso a paso: (1) Eligen un chore de Jira, (2) Configuran Prompt input: adaptan las templates de S3 si necesitan, (3) Trigger manual: lanzan el flujo plan→build, (4) Environment: rama dedicada para el issue, (5) Review: tests + MR en GitLab. El facilitador circula, guía pero no prescribe. Primera experiencia AFK en su contexto real.
  • Materials needed: Proyecto real del equipo, acceso a Jira y GitLab, templates de S3 adaptadas

Reflexión / Resumen (REFLEXIONAR)

  • Objective: O1, O2, O3
  • Duration: 15 min
  • Description: Puesta en común: ¿funcionó? ¿Cómo se siente soltar el control? Discusión sobre qué salió bien y qué no. Confianza progresiva: hoy usamos trigger manual y cron con features — el siguiente paso es escalar a más tipos de tarea y automatizar más. Principio: cuando falla, arreglar el template o el ADW, no el síntoma. Identidad: “Ya no hacemos código — creamos sistemas que generan sistemas. La capa ADW es donde los equipos van a centrarse.” Amplitud: “Y no solo para desarrollo — el mismo patrón sirve para PRDs, historias de usuario, documentación.” Semilla S5: “El agente trabaja solo, pero ¿cómo sabéis que lo ha hecho bien? ¿Y si falla un test y no os enteráis?” → bucles cerrados de retroalimentación.
  • Materials needed: Pizarra para anotar resultados y patrones

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

BlockDurationActivity
Check-in5 minRitual: cómo se encuentra cada persona
Pregunta provocativa3 min”¿Cuántas horas a la semana pasáis supervisando…?”
Recapitulación5 minPuente desde S3: templates → ¿y si no estáis?
De in-loop a out-of-loop10 minMODELAR — los dos modos + recogida de ideas
Lanzamos ADWs25 minPRACTICAR — Demo A (manual) + Demo B (cron) en forks
Anatomía de un ADW27 minMODELAR — análisis del código + los cuatro elementos + evolución orquestación
/prime:adw — Trabajar EN el ADW7 minMODELAR — excepción vibe coding + por qué existen los prime commands
AFK en tu proyecto30 minAPLICAR — primer flujo AFK con chore real
Reflexión / Resumen15 minREFLEXIONAR — puesta en común + identidad + semilla S5
Check-out5 minRitual: cómo se va cada persona
Total planificado132 min
Safety margin (12%)18 min
Total sesión150 min

Nota sobre el margen: El 12% de margen es adecuado. El bloque /prime:adw es el de menor riesgo de extensión (MODELAR puro, sin práctica). Si falta tiempo, comprimirlo a 4 min suprimiendo la pregunta inicial. El bloque AFK en proyecto propio es impredecible y probablemente necesitará extensión. La secuencia PRACTICAR→MODELAR (bloques 5→6) es deliberada: discovery-based learning — ejecutan el ADW con ambos triggers antes de entender cómo funciona. La progresión manual→cron se vive, no se explica.

Contenido prescindible (si falta tiempo):

  • Bloque “De in-loop a out-of-loop” puede fusionarse con el inicio del lanzamiento del ADW, ahorrando ~5 min
  • La pregunta sobre templates de S3 en el bloque de anatomía puede mencionarse brevemente
  • Los talking points de reflexión (identidad, amplitud, batalla) pueden reducirse a una frase cada uno
  • La reflexión puede comprimirse a 8 min (solo ronda rápida + talking points esenciales)

Si sobra margen: extender “AFK en tu proyecto” que previsiblemente necesita más tiempo.

Materials Needed

  • Pizarra/whiteboard: para ideas in-loop/out-of-loop (bloque 4) y resultados (bloque 8)
  • Slides: diagrama de los cuatro elementos (Prompt-Trigger-Environment-Review), in-loop vs out-of-loop, confianza progresiva
  • Fork propio de la demo app TODO (Rails + React), rama S4, por cada participante, con:
    • Script adws/bin/adw_plan_build funcional
    • Script adws/bin/trigger_cron funcional
    • Issue preparado para Demo A: “Diálogo de confirmación al borrar tarea”
    • Issue preparado para Demo B: “Tareas completadas al final con separador y estilos”
  • Cada participante con portátil y Claude Code configurado contra su fork
  • Proyecto real del equipo accesible (GitLab + Jira) para la actividad AFK
  • Templates de S3 (/chore, /bug, /feature, /implement) disponibles en los proyectos de los participantes