La siguiente frontera.

Agentic Developer

enaina

Check-in
enaina

Lo que sabéis hoy sobre trabajar con IA no existía hace un año.

enaina

¿Qué de lo que sabéis hoy seguirá siendo válido dentro de tres meses?

enaina

Agenda

El viaje
El horizonte
La paradoja
enaina

El viaje
enaina
graph LR A["1. Programamos"] --> B["2. Supervisamos\na la IA"] B --> C["3. Codificamos\nen prompts"] C --> D["4. Orquestamos\na la IA"] D --> E["5. Programamos\nla orquestación"] E --> F["6. Cerramos\nel bucle"] F --> G["7. Escalamos"]
enaina

El prompt es la nueva unidad fundamental de trabajo.

enaina

¿Qué necesita mi agente?

In-Agent (Core Four) Through-Agent
1. Context 5. Standard Out
2. Model 6. Types
3. Prompt 7. Documentation
4. Tools 8. Tests
9. Architecture
10. Plans
11. Templates
12. ADWs
enaina

El código tiene que estar optimizado para que los agentes trabajen en él.

enaina

KPIs: cómo sabemos que estamos mejorando

↑ Queremos más
Size
Trabajo delegado al agente
Streak
Éxitos consecutivos a la primera
↓ Queremos menos
Attempts
Iteraciones para completar
Presence
Tiempo de supervisión
enaina

Escapando del bucle

🎯
Prompt input
Issue + templates
Trigger
Manual · cron · webhook
🏗️
Environment
Entorno dedicado
Review
PR (revisión funcional/técnica)
enaina

Escapando del bucle

In-loop Out-of-loop
Nuestra atención garantiza la calidad Nuestro diseño garantiza la calidad
Compensamos fallos en tiempo real Los fallos se resuelven en el diseño
El cuello de botella: nuestra atención El cuello de botella: nuestro diseño
enaina

Cerrar el bucle

graph LR A([Plan]) --> B([Implement]) B --> C{Test} C -->|Falla| B C -->|Pasa| D{Validación} D -->|Falla| B D -->|Pasa| E([Documentar]) E --> F([Listo ✓]) E -.->|Contexto futuro| A
enaina

De programación a ingeniería de agentes

Mi rol Qué hago
Programador Programo
Supervisor Vibe coding
Orquestador Uso templates y comandos
Ingeniero agéntico Programo la orquestación
enaina

Construimos el sistema.

Construimos el sistema que construye el sistema.

enaina

Construimos el sistema.

Construimos el sistema que construye el sistema.

enaina

El horizonte
enaina

Cuatro retos.

Reto Pregunta
Control ¿Cómo lo sujetas?
Ingeniería de contextos ¿Cómo lo alimentas?
Gobernanza ¿Quién decide?
Orquestación ¿Cómo lo haces más inteligente?
enaina

Control
enaina

Un prompt no es un contrato.

¿Cómo convertimos instrucciones en garantías?

enaina

El código pone los límites.

Hooks. Tests. Herramientas. Orquestación determinista.

enaina

¿Cómo sabemos lo que hace el agente por debajo?

Convertir la caja negra en caja blanca: Trazabilidad. Observabilidad.

enaina

Ingeniería de contextos
enaina

La ingeniería de contextos es el arte y la ciencia de llenar la ventana de contexto con exactamente la información correcta para el siguiente paso.

— Andrej Karpathy

enaina

Context Engineering

Fuente: blog.langchain.com/the-rise-of-context-engineering
enaina

Memoria agéntica

Fuente: blog.dailydoseofds.com/p/types-of-memory-in-ai-agents
enaina

Gobernanza
enaina

Alguien modifica un contexto de la organización.

Todos los agentes de la organización cambian de comportamiento.

enaina

Alguien modifica un contexto de la organización.

Todos los agentes de la organización cambian de comportamiento.

enaina

¿Cómo funciona la gobernanza en desarrollo de software?

MRs, code reviews, permisos de acceso

enaina

¿Cómo funciona la gobernanza en desarrollo de software?

MRs, code reviews, permisos de acceso

enaina

¿Quién hace code review de una política de IA?

Product, legal, seguridad — no hacen MRs.

enaina

Orquestación
enaina

Prompt Chaining

Fuente: anthropic.com/engineering/building-effective-agents
enaina

Routing

Fuente: anthropic.com/engineering/building-effective-agents
enaina

Evaluator-Optimizer

Fuente: anthropic.com/engineering/building-effective-agents
enaina

Parallelization

Fuente: anthropic.com/engineering/building-effective-agents
enaina

Orchestrator-Workers

Fuente: anthropic.com/engineering/building-effective-agents
enaina

La paradoja
enaina

Creada con gemini nanobanana
enaina

Creada con gemini nanobanana
enaina

Lo que permanece no es la tecnología.

Es la capacidad de adaptarnos a la siguiente.

enaina

El trabajo ha cambiado.

Y todavía no sabemos cómo.

enaina

Nadie tiene el mapa.

enaina

Lo que importa no es la nave.

Es la tripulación.

enaina

The end

(of the beginning)

enaina

The end

(of the beginning)

enaina

Check-out
enaina

Gracias

enaina

🎯 Portada — Última sesión. El título señala cierre (hemos llegado al borde) y apertura (hay territorio por explorar). 💬 Sesión de cierre: consolidar el arco, mirar al horizonte Sin hands-on — sesión reflexiva con debate orgánico "La siguiente frontera" = los retos del horizonte que plantaremos en el Acto II 📌 Duración: ~150 min (90 planificados + 60 margen debate) ⏱ 1 min ➡️ Pasar directamente al check-in

🎯 Check-in — Conexión humana, última sesión del curso 💬 Cómo llegamos a la última sesión Una palabra o frase corta 🎬 "¿Cómo llegáis a la última sesión?" Ronda rápida, no comentar las respuestas Última ronda de apertura — dejar que sea más larga si el grupo quiere ⏱ 5 min ➡️ "Vamos con una pregunta."

🎯 Provocación — El hecho que prepara el vértigo 💬 Frase factual, irrebatible Hace un año no existían las prácticas que han aprendido Dejar que el hecho aterrice antes de pasar a la pregunta 🎬 Mostrar la slide Silencio de 3-5 segundos "Lo que sabéis hoy no existía hace un año." Dejar que aterrice. ⏱ 1 min ➡️ Avanzar directamente a la pregunta

🎯 Pregunta provocativa — El hilo que sobrevuela toda la sesión 💬 "Tres meses" es concreto y cercano — no es un futuro abstracto La incomodidad: ¿hemos aprendido algo duradero o algo efímero? Esta pregunta NO se responde ahora — la sesión la responde progresivamente: Acto I (El viaje) → la transformación es real Acto II (El horizonte) → lo que viene La paradoja → la nave generacional cierra el arco Respuesta final: lo que permanece no es la tecnología, es la tripulación 🎬 "¿Qué de todo esto seguirá siendo válido dentro de tres meses?" Silencio de 5-10 segundos No pedir respuestas. Dejar que la pregunta trabaje. La pregunta queda abierta — se cierra con la paradoja al final. ⏱ 2 min ➡️ "Antes de responder, miremos de dónde venimos."

🎯 Agenda — Mapa de la sesión 💬 Tres bloques, todos conceptuales y reflexivos Sin hands-on — esta sesión vive del diálogo El horizonte muestra paisaje, no enseña soluciones 🎬 Recorrer brevemente los bloques "Hoy no abrimos portátiles. Hoy miramos atrás, y miramos adelante." ⏱ 2 min ➡️ "Vamos a empezar por el viaje."

🎯 Título de sección — Abrir Acto I: Espejo 🎬 "Antes de mirar hacia delante, vamos a mirar hacia atrás." ⏱ 0.5 min ➡️ Pasar directamente al diagrama de evolución

🎯 Diagrama de evolución — El arco completo en una imagen 💬 7 etapas de transformación del rol: 1. Programamos — el estado original, escribimos código 2. Supervisamos a la IA — vibe coding: pedir, revisar, corregir, repetir 3. Codificamos en prompts — el prompt como unidad fundamental de trabajo 4. Orquestamos a la IA — templates, plans, perspectiva del agente 5. Programamos la orquestación — ADWs, AFK, los cuatro elementos 6. Cerramos el bucle — R-V-R, testing como diseño de fiabilidad 7. Escalamos — worktrees, ZTE, múltiples agentes en paralelo No es una línea de progreso — es una cadena donde cada paso habilita el siguiente 🎬 "Siete etapas." "Empezamos programando." "Después supervisábamos a la IA — vibe coding." "Después codificamos las tareas en prompts." "Después orquestamos. Después programamos la orquestación." "Cerramos el bucle. Y escalamos." Recorrer despacio, señalando cada paso "Cada paso hizo posible el siguiente." ⏱ 3 min ➡️ "Vamos a recordar algunos momentos clave."

🎯 Callback — El primer cambio de paradigma 💬 La doble provocación: dejad de programar + dejad de hacer vibe coding El grupo dibujó su flujo en la pizarra: pedir, revisar, corregir, repetir Descubrieron que no escala El shift: el prompt deja de ser "lo que le pido a la IA" Se convierte en la unidad de trabajo — planificado, compartido, reutilizable 🎬 "¿Os acordáis?" "Describisteis vuestro flujo en la pizarra." "Pedir, revisar, corregir, repetir. Vibe coding." "Y descubristeis que no escala." "El cambio: el prompt dejó de ser una petición." "Se convirtió en la unidad fundamental de trabajo." ⏱ 2 min ➡️ "Y entonces cambiamos la pregunta."

🎯 Callback — Perspectiva del agente + el mapa completo 💬 De "qué quiero yo" a "qué necesita mi agente" — la pregunta que lo cambió todo 12 puntos, dos familias: In-Agent = lo que viaja con el agente (controlamos directamente) Through-Agent = lo que encuentra en el proyecto (invertimos para mejorar) Este mapa les dio dirección — dejaron de ir a ciegas "Llevo meses invirtiendo esfuerzo en los puntos de menor impacto" 🎬 "La pregunta que lo cambió todo." "De 'qué quiero' a 'qué necesita mi agente'." "12 puntos de apalancamiento. 4 dentro del agente. 8 fuera." "Este mapa os dio dirección." ⏱ 2 min ➡️ "Y esto implica algo importante."

🎯 Callback — La inversión through-agent como disciplina 💬 No basta con tener un buen agente — el proyecto tiene que estar preparado 8 de 12 puntos son through-agent: están en el código, no en el agente Documentación, tests, arquitectura, tipos — todo eso es infraestructura para agentes El equipo que invierte en su codebase multiplica la efectividad de cualquier agente 🎬 "8 de 12 puntos están fuera del agente." "Están en vuestro código." "El código tiene que estar optimizado para que los agentes trabajen en él." "Eso es lo que habéis estado haciendo." ⏱ 1 min ➡️ "Y una brújula para medir el progreso."

🎯 SAPS — La brújula de adopción agéntica 💬 Size ↑ trabajo delegado al agente Attempts ↓ iteraciones para completar una tarea Presence ↓ tiempo de supervisión humana Streak ↑ éxitos consecutivos a la primera Estas cuatro métricas miden el progreso de todo el recorrido 🎬 "Y una brújula: SAPS." "Size, Attempts, Presence, Streak." "¿Cuál de estas cuatro os ha movido más desde que empezamos?" Invitar a respuesta rápida — una métrica por persona si el grupo quiere participar No analizar en profundidad — solo tomar temperatura 💡 Mini-debate de orgullo: las respuestas concretas anclan la transformación del Acto I. Si nadie responde: "A mí lo que más me sorprende es cuánto ha bajado Presence en los que habéis construido ADWs." ⏱ 3 min ➡️ "Y entonces: escapar del bucle."

🎯 Callback — Los cuatro elementos de un flujo autónomo 💬 Prompt input → Trigger → Environment → Review Las cuatro decisiones de diseño de cualquier flujo autónomo Prompt input: issue + templates embebidos Trigger: lo que lo arranca (manual, cron, webhook) Environment: rama dedicada, aislamiento Review: PR para revisión funcional/técnica 🎬 "Los cuatro elementos." Recorrer cada uno brevemente "Todo flujo autónomo tiene estos cuatro." ⏱ 1 min ➡️ "Y con esto, escapamos del bucle."

🎯 Callback — Escapar del bucle 💬 In-loop → nuestra atención es el mecanismo de calidad Out-of-loop → nuestro diseño es el mecanismo de calidad El cuello de botella no desaparece — se mueve de atención a diseño Atención = límite duro (uno a la vez) → diseño = resoluble con ingeniería 🎬 "In-loop: nuestra atención garantiza la calidad." "Out-of-loop: nuestro diseño garantiza la calidad." "El cuello de botella se movió. De atención a diseño." ⏱ 1 min ➡️ "Pero si no estás... ¿quién lo corrige?"

🎯 Callback — El ciclo de desarrollo agéntico completo 💬 El flujo completo con los tres bucles: Plan → Implement → Test (bucle sincrónico: falla → corrige → repite) Test pasa → Validación (segundo bucle: falla → corrige → repite) Validación pasa → Documentar → Listo La flecha punteada: documentación alimenta el Plan del siguiente ciclo Feedback sincrónico (tests, para esta ejecución) + asincrónico (docs, para la siguiente) El sistema mejora con el tiempo — cada agente empieza donde el anterior terminó La fiabilidad no se supervisa — se diseña 🎬 "El ciclo completo." "Plan. Implement. Test — si falla, corrige y repite." "Validación — segundo bucle." "Documentar. Y la flecha punteada." "Sin esa flecha, cada agente empieza de cero." "Con ella, cada agente empieza donde el anterior terminó." "La fiabilidad no se supervisa — se diseña." ⏱ 2 min ➡️ "Vamos a ponerle nombre a lo que habéis hecho."

🎯 Callback — La evolución del rol en una tabla 💬 Cuatro roles, cuatro formas de trabajar Programador → escribo código directamente Supervisor → vibe coding: pido, reviso, corrijo Orquestador → templates y comandos, el agente ejecuta Ingeniero agéntico → programo la orquestación: ADWs, bucles cerrados, ZTE Cada nivel automatiza el anterior Cuando automatizas un nivel, trabajas manualmente en el siguiente 🎬 Recorrer fila a fila "Programador. Supervisor. Orquestador. Ingeniero agéntico." "Cada vez que automatizamos un nivel, trabajamos en el siguiente." "¿Dónde estáis ahora? — señalad la fila." Invitar a posicionamiento rápido: manos, o que lo digan en voz alta Puede haber respuestas distintas: no es un error, el equipo está en transición 💡 Ronda de posicionamiento grupal: el grupo se ve a sí mismo en el mapa — momento de reconocimiento. Si alguien dice "entre dos niveles": "Normal. La transición es el punto de más aprendizaje." ⏱ 3 min ➡️ "Vamos a ponerle nombre."

🎯 Síntesis del arco (setup) — Primera capa: lo que han hecho 💬 "Construimos el sistema" — la capa agéntica, los comandos, los templates, los ADWs Dejar que aterrice antes de revelar la segunda capa 🎬 Pausa de 3-5 seg "Eso es lo que habéis hecho." ⏱ 1 min ➡️ Avanzar directamente a la revelación

🎯 Síntesis del arco (reveal) — La frase que resume el recorrido 💬 De vibe coding a capa agéntica No solo construyeron un sistema — construyeron el sistema que produce software 7 etapas: programar → supervisar → codificar en prompts → orquestar → programar la orquestación → cerrar el bucle → escalar No mejora incremental — cambio de paradigma Ya no escriben código directamente — diseñan la infraestructura que lo produce 🎬 "Construimos el sistema que construye el sistema." Dejar espacio "¿Qué ha cambiado para vosotros?" 💡 Primer momento de orgullo de la sesión. No apresurarse. Si el debate no arranca solo, usar una de estas: → "¿Hay algo que hacíais hace dos meses que ya no tiene sentido hacer manualmente?" → "¿Qué fue lo que más os costó cambiar — técnicamente o mentalmente?" → "¿Cuándo fue el momento en el que sentisteis que algo había hecho clic?" ⏱ 5 min (debate orgánico) ➡️ "Y ahora: ¿hacia dónde va esto?"

🎯 Título de sección — Abrir Acto II: Horizonte 💬 Transición de consolidación a horizonte Cuatro retos interrelacionados, cada uno con un origen distinto Rol del contenido: semilla — plantar curiosidad, no enseñar 🎬 "Habéis construido un sistema. Cuando crece, aparecen retos." "Cuatro dimensiones. Todas se afectan entre sí." ⏱ 1 min ➡️ Pasar directamente al mapa de retos

🎯 Mapa de retos — Cuatro dimensiones interrelacionadas 💬 No es una cascada secuencial — son cuatro dimensiones que se afectan mutuamente Control → ya lo tienen: el sistema es autónomo y tiene acceso a recursos sensibles Ingeniería de contextos → emerge del uso: el sistema se autodocumenta, genera contextos al trabajar Gobernanza → intrínseco a la complejidad organizacional: quién decide qué, cómo evoluciona Orquestación → cómo hacer el sistema cada vez más inteligente Cada una tiene un origen distinto pero todas interactúan 🎬 "Cuatro retos. Cuatro dimensiones." "No van en orden — se afectan entre sí." "Los vamos a recorrer." Recorrer brevemente sin explicar cada uno — solo plantar el mapa ⏱ 2 min ➡️ "Empecemos por algo que ya tenéis."

🎯 Título de reto — Control 🎬 Transición rápida ⏱ 0.5 min ➡️ Pasar directamente a la pregunta visceral

🎯 Control: tensión core — El lenguaje natural no garantiza nada 💬 Un CLAUDE.md, un comando, un prompt — son texto, no enforcement Podemos escribir "nunca hagas push a main" pero eso es una instrucción, no una garantía Lenguaje natural es probabilístico. Código es determinista. Ese es el salto. Nuestras reglas (seguridad, calidad, arquitectura) necesitan una capa de control real 🎬 Mostrar la slide Silencio de 5-10 seg — "un prompt no es un contrato" debe aterrizar No responder. Las siguientes slides responden progresivamente. ⏱ 3 min ➡️ Avanzar directamente a la respuesta

🎯 Control mediante código — La respuesta: código clásico, predecible, confiable 💬 Respuesta directa a "¿cómo convertimos instrucciones en garantías?" — con código El código es determinista: si el hook dice "bloquea push a main", se bloquea. Siempre. Ya lo hacemos: ADWs con orquestación determinista — el flujo lo decide el código, no el agente Hooks PreToolUse que interceptan y bloquean acciones peligrosas R-V-R con tests que validan antes de dar por bueno Los caminos peligrosos se cierran con código, no con esperanza El prompt sugiere. El código impone. 🎬 "La respuesta: código." "Hooks. Tests. Orquestación determinista." "El prompt sugiere. El código impone." "Ya lo hacemos — ADWs, bucles cerrados, hooks que bloquean." ⏱ 2 min ➡️ "Eso cubre lo que anticipamos. Pero..."

🎯 Trazabilidad y observabilidad — La segunda dimensión del control 💬 La prevención cubre lo que anticipamos. Pero no podemos anticipar todo. Trazabilidad: reconstruir cada decisión, cada acción, la cadena completa Observabilidad: ver qué hacen los agentes ahora mismo, en tiempo real Sin esto, la autonomía es un acto de fe La prevención ya la tenemos (código). La observabilidad es frontera — hay trabajo por hacer. 🎬 "Eso cubre lo que anticipamos." "Pero... ¿qué hizo el agente a las 3 AM?" Pausa "Sin trazabilidad, la autonomía es un acto de fe." Dejar espacio: "¿Qué escenarios os preocupan?" 👂 Escenarios típicos: secretos en commits, push a producción, borrado accidental, agente que se desvía del objetivo Si surge observabilidad: hooks → dashboard. Semilla para acompañamiento. 💡 Bloque que más debate genera. Dejar que fluya. Si el debate no arranca: usar este escenario de arranque → "Imaginad que vuestro agente ejecuta en cron a medianoche, modifica 40 ficheros y hace push. A las 9h llegáis a la oficina. ¿Cómo sabéis qué hizo? ¿Cómo revisáis si es correcto?" 📌 Detalle técnico (NO en slide): eventos de hooks (PreToolUse, PostToolUse, Stop, SubagentStop). Logs estructurados, UUID por ejecución. ⏱ 5 min (debate orgánico) ➡️ "A medida que el sistema trabaja, produce algo más que código. Produce contexto."

🎯 Título de reto — Ingeniería de contextos 🎬 "A medida que el sistema trabaja, produce contexto." ⏱ 0.5 min ➡️ Pasar directamente a la cita de Karpathy

🎯 Definición de context engineering — Anclar el concepto con autoridad 💬 Karpathy acuñó "context engineering" como disciplina No es prompt engineering — es ingeniería de TODO lo que rodea al prompt La ventana de contexto es el recurso más valioso y escaso del agente Llenarla bien = agente efectivo. Llenarla mal = contaminación o ceguera. A medida que el sistema trabaja, se autodocumenta — genera nuevos contextos El volumen crece. Gestionar ese volumen es una disciplina nueva. 🎬 Mostrar la cita Dejar que aterrice "Karpathy lo llama context engineering." "No es prompt engineering. Es la ingeniería de TODO lo que rodea al prompt." "A medida que vuestro sistema trabaja, genera contextos." "Commits, PRs, documentación, logs. El volumen crece." "Gestionar ese volumen es una disciplina." 📌 Tweet: https://x.com/karpathy/status/1937902205765607626 ⏱ 3 min ➡️ "Mirad esto."

🎯 Diagrama Context Engineering — Visualizar el alcance de la disciplina 💬 Context Engineering es el superconjunto que engloba: Prompt Engineering — lo que ya conocemos, diseño del prompt RAG — retrieval augmented generation, traer información relevante Memory — persistencia entre sesiones (lo que hace OpenClaw) State/History — estado de la conversación y el trabajo previo Structured Outputs — formatear la salida para que sea procesable Prompt Engineering es solo una pieza. Context Engineering es todo lo que rodea al agente. Esto es lo que Karpathy define: llenar la ventana de contexto con la información correcta. Cada una de estas piezas es una disciplina en sí misma. 🎬 "Esto es context engineering." "Fijaos: prompt engineering es solo una pieza." Señalar cada círculo brevemente "RAG, memoria, estado, salida estructurada — todo forma parte." "Es una disciplina nueva. Y ya la estamos practicando." 📌 Fuente: https://blog.langchain.com/the-rise-of-context-engineering/ ⏱ 2 min ➡️ "Un ejemplo concreto: la memoria."

🎯 Memoria agéntica — Un caso concreto de ingeniería de contextos 💬 La memoria es una de las piezas del diagrama anterior — y ya es una disciplina en sí misma. Dos ejes: Por scope: short-term (dentro de la sesión, historial de mensajes) vs long-term (entre sesiones, requiere persistencia) Por analogía humana: Semantic — hechos: info del usuario, conceptos del dominio, instrucciones Episodic — experiencias: qué hizo el agente, qué pasó, qué funcionó Procedural — instrucciones: el system prompt, los comandos, las reglas Lo que ya hacemos es memoria: CLAUDE.md = memoria semántica (hechos sobre el proyecto) Comandos y templates = memoria procedural (cómo hacer las cosas) Git log, PRs = memoria episódica (qué pasó) La diferencia: hoy es manual. El horizonte es que el sistema gestione su propia memoria. 🎬 "Un ejemplo concreto: la memoria." "Dos ejes. Por duración: corto y largo plazo." "Por tipo, como los humanos: hechos, experiencias, instrucciones." Señalar la tabla inferior "Ya lo hacemos: CLAUDE.md son hechos. Comandos son instrucciones. Git es experiencia." "Hoy lo gestionamos nosotros. El horizonte: el sistema gestiona su propia memoria." Pausa breve y abrir: "¿Qué hace vuestro sistema hoy para no olvidar entre ejecuciones?" Respuestas esperadas: CLAUDE.md, git log, comentarios en código, naming de ramas Si nadie responde: "Pensad en la última vez que volvisteis a un proyecto después de una semana. ¿Qué necesitaba el agente para reorientarse?" 💡 Zona de debate exploratoria: el gap entre lo que hacen hoy (manual) y el horizonte (autónomo) es muy tangible para quienes ya usan agentes en proyectos reales. 📌 Fuente: https://blog.dailydoseofds.com/p/types-of-memory-in-ai-agents ⏱ 5 min (3 exposición + 2 debate) ➡️ "Y cuando todo esto crece... ¿quién decide?"

🎯 Título de reto — Gobernanza 🎬 "¿Quién decide?" ⏱ 0.5 min ➡️ Pasar directamente al concepto-doble

🎯 Gobernanza (setup) — Hacer sentir el problema 💬 CLAUDE.md, comandos, hooks — son ficheros de texto, parecen triviales Pero definen cómo trabajan Todos los agentes de la organización Dejar que la simplicidad del artefacto aterrice antes del reveal 🎬 "Alguien modifica un contexto de la organización." Pausa de 3-5 seg Dejar que parezca inocuo ⏱ 1 min ➡️ Avanzar directamente a la revelación

🎯 Gobernanza (reveal) — El impacto oculto 💬 Un CLAUDE.md editado cambia cómo trabajan Todos los agentes de la organización Un hook de seguridad modificado afecta a toda ejecución autónoma Contextos que solo consumen agentes — ¿cómo los revisamos si no podemos "ejecutarlos" mentalmente? El impacto está oculto tras la simplicidad del artefacto Esto ES el problema de gobernanza 🎬 "Todos los agentes de la organización cambian de comportamiento." Dejar que la incomodidad trabaje "Un fichero markdown. Todos los agentes." "¿Cómo revisamos algo que solo consume una máquina?" 📌 Conecta con entregable contractual: "política de gobernanza de IA" ⏱ 2 min ➡️ "Pero esto debería sonarnos..."

🎯 Gobernanza: lo conocido (setup) — Generar curiosidad 💬 Transición de tensión a alivio El problema de gobernanza no es nuevo — lo resolvemos cada día con código Dejar que la frase genere la pregunta: ¿qué debería sonarnos? 🎬 "Pero esto debería sonarnos..." Pausa breve ⏱ 0.5 min ➡️ Avanzar directamente a la revelación

🎯 Gobernanza: lo conocido (reveal) — Conectar con prácticas que ya dominan 💬 La gobernanza agéntica es una extensión de prácticas que ya dominamos: Estructura: ¿comandos en cada repo o repo compartido? ¿Qué es de equipo y qué de organización? Proceso: un dev crea un comando → MR → review → merge. Mismo flujo que ya usamos para código. Versionado: los comandos son ficheros markdown en el repo — se versionan con git El músculo para gobernar la capa agéntica ya existe 🎬 "Monorepo o multi-repo. MRs. Code review." "Ya lo hacemos con código." "Los comandos son ficheros. Se versionan. Se revisan." "El músculo ya existe." ⏱ 2 min ➡️ "Pero..."

🎯 Gobernanza: warning organizacional — Las soluciones técnicas no cubren este caso 💬 Lo anterior funciona entre equipos técnicos — MRs, code review, repos Pero la capa agéntica afecta a toda la organización: Product define qué tareas se automatizan y cuáles no Legal necesita saber qué hace el agente con datos sensibles Seguridad define los hooks inmutables, las restricciones de acceso Las prácticas técnicas que acabamos de mencionar no funcionan cuando los stakeholders no son técnicos Gobernanza agéntica = gobernanza organizacional 🎬 "Pero..." "¿Quién hace code review de una política de IA?" Pausa "Product, legal, seguridad — no hacen MRs." "Las soluciones que acabamos de ver no cubren este caso." Abrir con una de estas dos preguntas: → "¿Cómo decidís en vuestro equipo quién puede tocar el CLAUDE.md de la organización?" → "Si Product quiere que el agente nunca responda en inglés — ¿cómo se convierte eso en una regla del sistema?" Dejar que el debate vaya donde quiera — gobernanza técnica vs. organizacional es territorio genuinamente abierto 👂 Respuestas esperadas: "no lo hemos pensado", "lo gestiona solo el equipo técnico", "tendríamos que crear un proceso nuevo" Todas son válidas — la incomodidad de no tener respuesta es el punto. 📌 Conecta con entregable contractual: "política de gobernanza de IA" Semilla para acompañamiento: definir quién participa en la gobernanza ⏱ 5 min (debate orgánico) ➡️ "Y la última dimensión: ¿cómo hacemos el sistema más inteligente?"

🎯 Título de reto — Orquestación 🎬 "¿Cómo hacemos el sistema más inteligente?" ⏱ 0.5 min ➡️ Pasar directamente a los patrones que ya usan

🎯 Patrón: Prompt Chaining — Ya lo hacemos 💬 Cadena secuencial y predefinida: cada paso alimenta el siguiente Ya lo hacemos: template → plan → implement El ADW es exactamente esto: una cadena de pasos donde la salida de uno es la entrada del siguiente El código define el orden. La IA opera dentro de cada paso. 🎬 "Prompt Chaining." "Template genera plan. Plan guía implementación." "Ya lo hacemos. Ahora tiene nombre." 📌 Referencia: "Building Effective Agents" de Anthropic ⏱ 1 min ➡️ Pasar directamente al siguiente patrón

🎯 Patrón: Routing — Ya lo hacemos 💬 El flujo se bifurca según el tipo de tarea Ya lo hacemos: classify del ADW analiza el issue y decide bug/chore/feature Cada tipo de tarea tiene su camino predefinido El agente clasifica, el código decide qué camino seguir 🎬 "Routing." "Classify analiza el issue. Bug, chore, feature — cada uno su camino." "También lo hacemos." 📌 Referencia: "Building Effective Agents" de Anthropic ⏱ 1 min ➡️ Pasar directamente al siguiente patrón

🎯 Patrón: Evaluator-Optimizer — Ya lo hacemos 💬 Ejecuta → valida → corrige → repite hasta que pase Ya lo hacemos: R-V-R es exactamente este patrón El bucle cerrado que construimos para que el agente se auto-corrija La evaluación decide si el resultado es aceptable o hay que iterar 🎬 "Evaluator-Optimizer." "Ejecuta, valida, corrige. R-V-R." "El bucle cerrado. También lo hacemos." "Tres patrones de Anthropic. Tres cosas que ya hacemos. Ahora tienen nombre." ⏱ 1 min ➡️ "Y hay patrones que todavía no usamos."

🎯 Patrón: Parallelization — Horizonte 💬 Múltiples agentes ejecutando simultáneamente, cada uno aislado Lo hemos rozado con ZTE — worktrees en paralelo, pero como proceso manual El patrón: un sistema que divide el trabajo, lanza agentes en paralelo y recoge resultados Cada agente tiene su rama, su contexto, su entorno aislado La diferencia con lo que hacemos: aquí el sistema orquesta automáticamente 🎬 "Parallelization." "Múltiples agentes trabajando a la vez. Cada uno aislado." "Lo hemos rozado con worktrees. Pero como proceso manual." "El patrón: un sistema que divide, lanza y recoge." 📌 Referencia: "Building Effective Agents" de Anthropic ⏱ 2 min ➡️ Pasar directamente al siguiente patrón

🎯 Patrón: Orchestrator-Workers — Horizonte 💬 Un agente central analiza la tarea y decide qué sub-agentes lanzar No hay caminos predefinidos — el orquestador decide en tiempo real Ejemplo: recibe un issue complejo, decide que necesita un agente de análisis, uno de implementación y uno de testing Cada worker es especializado — un agente, un propósito La diferencia clave: en los patrones anteriores el código decide el flujo. Aquí la IA decide. 🎬 "Orchestrator-Workers." "Un agente que analiza la tarea y decide qué delegar." "No hay caminos predefinidos — la IA decide en tiempo real." "Cada worker es especializado." Pausa y abrir: "¿Dónde está la línea en la que confíais en que la IA decida por sí sola qué hacer?" Respuestas esperadas: depende del riesgo de la acción, de si hay reversibilidad, del dominio Conectar con Control si surge: "Lo que acabamos de ver — hooks, tests — es precisamente lo que hace posible bajar esa línea." 💡 Mini-debate sobre confianza: la tensión entre autonomía y control es el nervio de todo el Acto II. Este momento la hace personal y concreta. 📌 Referencia: "Building Effective Agents" de Anthropic ⏱ 4 min (2 exposición + 2 debate) ➡️ "Y ahora, una paradoja."

🎯 Título de sección — Abrir Acto III: cierre 💬 Acto final. La paradoja de la nave generacional como hilo conductor. Lo que sabemos hoy se quedará obsoleto mañana. Lo importante no son los conocimientos técnicos — es el cambio de mentalidad. 🎬 Bajar el ritmo. Tono pausado, reflexivo. "Y ahora, una paradoja." ⏱ 0.5 min ➡️ "Imaginad una nave generacional."

🎯 Primera imagen — establecer la nave generacional visualmente 💬 Una nave generacional: diseñada para viajar durante generaciones enteras hasta su destino La lanzamos hoy con la mejor tecnología disponible Generaciones enteras nacerían y morirían a bordo antes de llegar 🎬 "Imaginad una nave generacional." "Diseñada para viajar cientos de años hasta su destino." "La lanzamos hoy, con lo mejor que tenemos." Pausa "Pero la tecnología no se detiene en Tierra." ⏱ 2 min ➡️ Siguiente imagen

🎯 Segunda imagen — la paradoja se materializa 💬 Una nave más rápida, lanzada décadas después, la adelanta Lo que construimos hoy con la mejor tecnología puede quedar obsoleto mañana Aplicado a nosotros: los comandos, los templates, los ADWs — pueden cambiar Los modelos cambian cada mes 🎬 "Una nave más rápida, lanzada después, la adelanta." Pausa larga "¿Entonces... esperamos?" "Pero si esperamos, nunca lanzamos." Dejar que la paradoja flote. No resolverla todavía. ⏱ 2 min ➡️ "Pero hay algo que no caduca."

🎯 Resolución de la paradoja — Lo que no caduca 💬 Comandos, templates, ADWs concretos → pueden quedar obsoletos Lo que no caduca: criterio para evaluar lo nuevo, músculo de construir sistemas agénticos, framework mental (12 puntos, SAPS, R-V-R) La capa agéntica no es un producto terminado — es una práctica que se renueva La nave que importa no es la nave — es la tripulación 🎬 Pausa de 3-5 seg tras mostrar "Lo que permanece no es la tecnología." "Es la capacidad de adaptarnos." ⏱ 2 min ➡️ "Y eso nos lleva a una pregunta."

🎯 La tesis — Honestidad radical 💬 Frase directa, sin adornos Lo que hemos aprendido en 8 sesiones es real Pero el terreno sigue moviéndose bajo nuestros pies No es una confesión de fracaso — es honestidad intelectual El que dice que sabe exactamente cómo cambia el trabajo con la IA, miente 🎬 "El trabajo ha cambiado." Pausa larga "Y todavía no sabemos cómo." Dejar que la frase respire. No apresurar. ⏱ 2 min ➡️ "Nadie lo sabe."

🎯 Desarrollo — Nadie sabe, y eso no es una crisis 💬 Ni Anthropic. Ni OpenAI. Ni nosotros. Los modelos cambian cada mes. Las herramientas, cada trimestre. Esto no es una crisis — es el terreno Quien diga que tiene el mapa miente Pero hay una diferencia entre estar perdido y saber navegar sin mapa Nosotros sabemos navegar: tenemos frameworks (12 puntos, SAPS), tenemos práctica construyendo sistemas agénticos, tenemos criterio para evaluar lo que venga 🎬 "Nadie tiene el mapa." "Ni Anthropic. Ni OpenAI. Ni nosotros." Pausa "Pero hay una diferencia entre estar perdido y saber navegar sin mapa." "Tenemos frameworks. Tenemos práctica. Tenemos criterio." "Cuando aparezca algo nuevo — y aparecerá — sabremos evaluarlo." Abrir: "¿Cómo está navegando vuestra organización esta incertidumbre?" Respuestas esperadas: "esperando a ver qué pasa", "apostando fuerte", "sin estrategia clara", "mucho ruido, poca acción" Todas válidas — este debate no tiene respuesta correcta, y eso es el punto. 💡 Debate de aceptación: no se busca una solución — se busca que el grupo nombre cómo vive la incertidumbre. Es el puente hacia la paradoja final. ⏱ 5 min (2 exposición + 3 debate) ➡️ "Recordad la nave generacional."

🎯 Cierre del arco metafórico — Respuesta a la provocación 💬 Callback a la nave generacional del interludio La tecnología caduca. Las herramientas se reemplazan. Los modelos cambian. Lo que permanece: el equipo, el criterio, la forma de pensar Esta es la respuesta a la provocación del inicio ("¿qué seguirá siendo válido dentro de tres meses?") La respuesta: nosotros. La tripulación. 🎬 "Recordad la nave generacional." "La nave que importa no es la nave." Pausa "Es la tripulación." Silencio largo — dejar que aterrice "Eso es lo que seguirá siendo válido dentro de tres meses." 💡 Tono pausado. Este es el momento emocional más importante. No apresurarse. ⏱ 3 min ➡️ Mostrar la despedida

🎯 Despedida — El mantra del curso como última palabra 💬 Ya apareció en El Viaje como síntesis del arco Ahora es la última palabra antes del check-out No explicar — solo dejar que resuene Toda la sesión está encima de esta frase 🎬 Mostrar la slide Silencio de 5-10 seg No añadir nada. La frase habla sola. ⏱ 1 min ➡️ "Última ronda."

🎯 Despedida — El mantra del curso como última palabra 💬 Ya apareció en El Viaje como síntesis del arco Ahora es la última palabra antes del check-out No explicar — solo dejar que resuene Toda la sesión está encima de esta frase 🎬 Mostrar la slide Silencio de 5-10 seg No añadir nada. La frase habla sola. ⏱ 1 min ➡️ "Última ronda."

🎯 Check-out — Cierre emocional del grupo y del curso 💬 Última ronda del curso Una palabra o frase corta sobre cómo se van 🎬 "Última ronda. ¿Cómo os vais?" Ronda sin comentarios Si alguien quiere extenderse, dejar Última ronda — no apresurarse Terminar con agradecimiento al grupo ⏱ 5 min ➡️ Slide de fin

🎯 Fin — Cierre ceremonial del deck y del curso ⏱ 0 min ➡️ —