Ingenieros senior leen tu terminal más rápido de lo que hablas, y prueban tus afirmaciones preguntando la pregunta que esperabas omitir. Este manual es el plan operacional para una sesión en directo de 60-120 minutos sobre una herramienta como Claude Code, Kubernetes, o n8n: línea de tiempo, salvaguardas de demo, y qué decir cuando alguien te presiona.
Estructura de la sesión
Cuatro cosas suceden independientemente de la duración: gana atención, establece contexto, muéstraselo funcionando, deja a la audiencia tocarlo. Mantén contexto corto – una audiencia senior se desconecta pasada la cuarta diapositiva de antecedentes.
Sesión de 60 minutos
| Tiempo | Bloque | Qué sucede |
|---|---|---|
| 0:00-0:05 | Apertura en frío | Una pregunta o cosa rota en pantalla, sin diapositivas |
| 0:05-0:12 | Contexto | Por qué importa esto, qué está dentro/fuera de alcance |
| 0:12-0:30 | Demo 1 | Flujo de trabajo central de extremo a extremo, narrado |
| 0:30-0:48 | Hands-on | La audiencia ejecuta los mismos pasos en un repositorio compartido |
| 0:48-0:55 | Demo 2 / romper-la | Caso de borde, o la audiencia elige algo para romper |
| 0:55-1:00 | Q&A + cierre | Aparcadero, próximos pasos, enlace de repositorio |
Sesión de 120 minutos
| Tiempo | Bloque | Qué sucede |
|---|---|---|
| 0:00-0:05 | Apertura en frío | Versión de mayor apuesta de la misma idea |
| 0:05-0:15 | Contexto | Alcance, prerrequisitos, qué hoy omite |
| 0:15-0:35 | Demo 1 | Flujo de trabajo completo, un pase, sin interrupciones |
| 0:35-1:00 | Hands-on 1 | La audiencia reproduce demo 1 en el repositorio pre-cocido |
| 1:00-1:10 | Descanso | Parada firme, anuncia el tiempo de retorno en voz alta |
| 1:10-1:30 | Demo 2 / romper-la | Caso más difícil, falla inyectada a propósito |
| 1:30-1:45 | Pairing / hands-on 2 | Pares trabajan el caso más difícil juntos |
| 1:45-1:55 | Q&A | Piso abierto, aparcadero para cualquier cosa que necesite investigación |
| 1:55-2:00 | Cierre | Recapitula, enlaces, línea de tiempo de grabación |
Mantén la apertura en frío bajo cinco minutos incluso en dos horas. El tiempo extra pertenece a hands-on, no a una intro más larga.
Ingeniería de demo
Una demo en directo es un sistema con modos de falla – ingenierízalo como uno.
Repositorio pre-cocido, checkpoints etiquetados. Construye el repositorio por adelantado con una etiqueta por paso de demo. Si paso 3 se rompe mid-sesión, recupera con un comando en lugar de re-tipear quince minutos de setup:
# reset the working tree to the step-2 checkpoint
git checkout step-2 -- .
Nombra etiquetas después del paso, no la fecha (step-2, no oct-27), así el repositorio es reutilizable.
Grabación de fallback. Graba la demo completa una vez en el hardware real de presentación. Mantenla cargada, silenciada, pausada al inicio. Si una corrección en directo tomará más de 60 segundos, cambia a la grabación y narra sobre ella.
Setup de terminal. Fuente de 18pt mínimo, tema de contraste alto, prompt corto para que comandos no se envuelvan. Limpia scrollback antes de que empieces para que errores anteriores no sean visibles cuando hagas scroll arriba.
Modos seguros para cualquier cosa que se ejecute. Decide la barandilla antes de estar frente a la gente. --permission-mode plan en Claude Code prevé ediciones sin aplicarlas (lista completa de banderas en la hoja de trucos de Claude Code). Si el agente debe realmente escribir archivos, mantén Ctrl+C más git checkout al último etiquetado como los dos movimientos que conoces bien. Hooks que registran o bloquean comandos merecen estar habilitados para una audiencia que preguntará qué sucedió bajo el capó.
Infraestructura desechable. Para Kubernetes, corre contra un cluster local que puedas eliminar y reconstruir en menos de dos minutos – kind delete cluster --name demo luego kind create cluster --name demo (trade-offs entre kind, minikube, y k3d están en la comparación de cluster). Para n8n, comienza desde un estado docker compose conocido-bueno (el primer lab de flujo de trabajo n8n) con una segunda instancia manteniendo el flujo de trabajo terminado como respaldo.
Diseño de interacción
Ingenieros senior participan cuando el formato pide algo específico de ellos, no «¿alguna pregunta?» en silencio.
- Pregunta de apertura en frío. Pregunta algo atado al trabajo de la sala («¿quién ha golpeado un deploy flaky este mes?») en lugar de declaar tu bio. Llama a alguien si las manos no suben en cinco segundos.
- Polls. Una poll por 30 minutos, fraseada como predicción («¿qué imprimirá este comando?»), respondida ejecutando el comando en lugar de una diapositiva.
- Pairing. Para el bloque hands-on más difícil, empareja a la gente en lugar de dejarlos solos – pairing saca desacuerdos en voz alta, que es donde aprendes qué cree la sala.
- Ejercicio «romper-la». Entrega la demo de trabajo y pide a la sala romperla en tres minutos. Produce casos de borde mejores que encontrarás solo, y reenmarcar falla como esperada en lugar de vergonzosa.
Manejo de preguntas difíciles
Ingenieros senior hacen preguntas para encontrar el borde de tu conocimiento. Usa los mismos cuatro movimientos cada vez:
- Reconoce. «Buena pregunta» está bien si es verdad; no lo digas reflexivamente.
- Reestá. Una oración, tus palabras – confirma que entendiste y compra tiempo para pensar.
- Responde o aparkaala. Responde en menos de un minuto, o escríbela en un aparcadero visible con el nombre del preguntador.
- Haz seguimiento en escrito. Cierra cada item aparcado dentro de 24 horas, incluso si la respuesta es «no.»
Cuando no sabes: dilo en una oración, aparkaalo, sigue adelante. Improvisar una respuesta insegura es la forma más rápida de perder un salón senior – la verifican después y recuerdan la adivinanza.
Cuando un participante está equivocado: no discutas el punto abstractamente. Ejecuta el comando o abre el doc que lo resuelve; «déjanos verificar,» dicho en voz alta y luego hecho, resuelve más que una corrección verbal y lo mantiene impersonal.
Cuando alguien desafía el valor de la herramienta: no la defiendas en principio. Pregunta contra qué la compararían y qué barra necesita cruzar. Escribe esa barra en el aparcadero y pruébala en directo si puedes en dos minutos. Si no puedes, di que la brecha es real y sigue adelante.
Simulacros de falla
Ensaya estos de antemano.
La demo se rompe mid-paso. Declara qué se rompió en una oración, cambia a la grabación de fallback o salta al siguiente etiquetado de git, sigue narrando. No te disculpes más de una vez.
La red muere. Por esto la infraestructura es local: un cluster kind o una instancia Dockerizada de n8n sigue corriendo sin internet. Si una demo genuinamente necesita una API remota, ten un sustituto offline listo (respuesta registrada, mock local) y di que estás cambiando a él.
El agente se desvía del script. Un agente de IA editando archivos que no esperabas necesita una parada inmediata, no un wait-and-see. Golpea el interruptor de parada – interrumpe el proceso, git checkout de vuelta al último etiquetado conocido-bueno – y di qué sucedió. Enmarcado como un ejemplo en directo de por qué las barandillas importan (ver la lista de verificación de gobernanza de IA), un error se convierte en contenido en lugar de un slot desperdiciado.
Lista de verificación de pre-vuelo
| Verificación | Por qué importa |
|---|---|
| Repo fijado a las etiquetas de la sesión, laptop principal y respaldo | La recuperación depende de que esto sea exacto |
| Demo ensayada dos veces, una a velocidad de presentación | Atrapa derivación de tiempo antes de que la sala lo haga |
| Grabación de fallback hecha en el hardware de presentación | Una máquina diferente puede comportarse diferente |
| Infra local (cluster, contenedores) pre-jalados | Ninguna descarga en directo debe bloquear una demo |
| Interruptor de parada para cualquier agente en directo probado | No decidas esto mid-edit |
| Fuente de terminal/tema configurada, conteo de diapositivas bajo 10 | Confirma desde la parte de atrás de la sala |
| Doc de aparcadero creado, cronómetro visible solo para ti | Necesitado dentro de los primeros 20 minutos |
| Ruta independiente de internet para cada paso | Asume que el Wi-Fi del venue falla |
Lista de verificación post-sesión
| Tarea | Plazo |
|---|---|
| Recorta y sube la grabación | Mismo día |
| Responde cada item del aparcadero en escrito | 24 horas |
| Comparte el enlace del repositorio y estado final | Mismo día |
| Envía notas a cualquiera que preguntó | 24 horas |
| Archiva aparcadero y notas con la fecha | Una semana |
Plantilla reutilizable
Pega esto y llena los corchetes antes de cada sesión.
# Plan de sesión: [topic]
Audiencia: [rol / seniority]
Duración: [60 | 120] minutos
Repositorio: [url], etiquetas step-1 .. step-N
Grabación de fallback: [ruta/enlace]
Interruptor de parada: [combinación de tecla o comando]
## Línea de tiempo
- 0:00 Apertura en frío: [pregunta o cosa rota]
- 0:05 Contexto: [alcance]
- 0:xx Demo 1: [flujo de trabajo]
- 0:xx Hands-on: [tarea, estado del repositorio de inicio]
- 0:xx Demo 2 / romper-la: [caso de borde o piso abierto]
- 0:xx Q&A
- fin Cierre: [enlaces, próximos pasos]
## Aparcadero
| Pregunta | Preguntado por | Estado | Respondido |
| --- | --- | --- | --- |
## Pre-vuelo
- [ ] Repo fijado y etiquetado
- [ ] Grabación de fallback lista
- [ ] Infra pre-jalada y local
- [ ] Interruptor de parada probado
Trampas
Demasiadas diapositivas. Un deck sobre diez diapositivas para una audiencia técnica señala que estás llenando tiempo en lugar de mostrar el trabajo de la herramienta. Corta la diapositiva, muestra la terminal.
Generar todo en directo. Tipear cada línea desde cero es más lento que la paciencia de la sala e multiplica la chance de un typo descarrilando el flujo. Pre-cocina las partes aburridas; reserva tipeo en directo para la una o dos líneas que son el punto.
Ignorar al uno experto silencioso. Cada salón senior tiene a alguien que no dice nada por 40 minutos, luego hace la pregunta que revela una brecha en tu demo. Mira quién dejó de tomar notas o comenzó a verificar algo en su propia pantalla, y llama directamente a ellos durante Q&A.
Preguntas frecuentes
¿Cuánto tiempo debe durar una sesión de entrenamiento técnico en directo para ingenieros senior?
60 minutos para una demo y un bloque de hands-on. 120 minutos para dos demos, un descanso, y un ejercicio de pairing. Auditorios senior se desconectan pasadas dos horas independientemente del contenido, así divide cualquier cosa más larga en dos sesiones.
¿Cuál es la forma más segura de ejecutar una demo en directo que podría fallar?
Fija el repositorio a etiquetas de git por paso para que puedas saltar a cualquier checkpoint con un comando, y mantén un fallback pre-grabado de la demo completa listo para reproducir. La audiencia perdona una falla; no perdonan cinco minutos de debugging silencioso.
¿Cómo respondo una pregunta difícil que no puedo responder en directo?
Reconoce que requirió pensamiento, reestá en una oración, luego responde en menos de 60 segundos o aparkaala en una lista visible con el nombre del preguntador. Envía la respuesta real en escrito dentro de 24 horas. Adivinar en voz alta cuesta más credibilidad que aparcar la pregunta.
¿Qué pasa si un ingeniero senior dice que la herramienta no vale la pena?
No la defiendas. Pregunta contra qué la compararían y qué necesitaría para ganar un slot. Escribe ese estándar en el aparcadero y pruébalo en directo si puedes en menos de dos minutos. Si no puedes, admite la brecha y sigue adelante.
¿Cuál es un interruptor de parada para un agente de codificación de IA durante una demo en directo?
Un movimiento único que detiene al agente de hacer más cambios sin explicar por qué: Ctrl+C en la terminal, luego git checkout de vuelta al último commit etiquetado. Decide esto antes de la sesión, no mientras el agente está en medio de una edición.
Cómo se verificó esta guía
Escrita a mano a partir de la documentación oficial, con cada comando comprobado de nuevo y una segunda revisión antes de publicar. Última revisión: .
Fuentes oficiales consultadas para este artículo