Cómo usar Claude para preparar una charla técnica sin perder tu voz

Preparar una charla técnica consume más tiempo del que parece razonable: estructura, ritmo, ejemplos que funcionen en vivo, transiciones que no suenen forzadas. Un desarrollador publicó esta semana en su blog un relato detallado de cómo usó asistencia de IA para mejorar una presentación real, y el post circuló por Hacker News generando suficiente interés como para valer la pena analizarlo.

Lo interesante no es que «la IA le escribió la charla». Es exactamente lo contrario: el autor mantiene su voz, sus argumentos y sus ejemplos. El modelo actúa como interlocutor crítico, no como ghostwriter.

Qué hizo exactamente

El flujo descrito en el artículo tiene varias fases concretas:

• Estructura inicial: volcó sus notas brutas y pidió que se identificaran los huecos argumentales, no que se reescribiera nada. El objetivo era detectar qué daba por supuesto frente a lo que realmente explicaba.
• Ensayo simulado: describió la audiencia esperada (perfil técnico, tiempo limitado, contexto de conferencia) y pidió preguntas incómodas que un asistente escéptico podría hacer. Esto le permitió preparar respuestas antes de estar en el escenario.
• Revisión de transiciones: pegó el guion y pidió que se marcaran los saltos bruscos entre secciones, sin sugerir redacciones alternativas automáticamente.
• Ajuste de densidad: identificó los segmentos donde la densidad de conceptos nuevos era demasiado alta para el tiempo asignado.

El artículo no especifica qué modelo usó, así que no lo asumimos. Lo que sí queda claro es que el prompt engineering aplicado es deliberadamente restrictivo: el autor pide análisis, no producción de contenido.

Por qué este enfoque es distinto al uso habitual

La mayoría de tutoriales sobre «IA para presentaciones» terminan en plantillas generadas, diapositivas automáticas o resúmenes executivos de dudosa utilidad. El problema de ese enfoque es que el presentador pierde la familiaridad con su propio material: cuando alguien en la audiencia hace una pregunta lateral, no hay contexto propio del que tirar.

El flujo descrito invierte esa lógica. El modelo nunca tiene la autoría; tiene el rol de revisor con criterios explícitos. Esto encaja bien con algo que hemos visto en otros casos documentados: Claude tiende a ser más útil cuando el usuario sabe exactamente qué tipo de fricción quiere introducir en su proceso, en lugar de delegar el proceso completo.

Para quienes preparan charlas con regularidad —developer advocates, ingenieros que presentan en conferencias, consultores técnicos— este tipo de uso tiene sentido práctico inmediato. No requiere integraciones complejas ni configuración especial: es conversación estructurada con prompts bien diseñados.

Lo que falta en el artículo

El post original es honesto sobre sus limitaciones: no mide si la charla mejoró objetivamente (difícil de hacer), no compara con preparaciones anteriores y no documenta los prompts exactos utilizados, lo que reduciría su reproducibilidad. Son limitaciones razonables para un relato personal, pero conviene tenerlas en cuenta antes de adoptar el método sin adaptación.

También queda sin explorar si este flujo escala a charlas más largas o con múltiples ponentes, donde la coordinación de voces añade otra capa de complejidad.

Para quién es útil esto

El caso tiene aplicación directa para:

• Desarrolladores que presentan en meetups o conferencias y no tienen un equipo de comunicación detrás.
• Profesores o formadores técnicos que preparan sesiones con frecuencia y necesitan feedback rápido antes de cada entrega.
• Cualquiera que haya sufrido el problema de «tengo el contenido, pero no sé si fluye» sin tener un colega disponible para escucharle.

No es un flujo pensado para quienes necesitan que alguien les escriba el contenido desde cero. Para ese caso, los resultados suelen ser genéricos y el presentador acaba distanciado de su propio material.

---

Desde ElephantPink valoramos este tipo de documentación práctica precisamente porque pone el foco en el proceso, no en el resultado espectacular. Que alguien se tome el tiempo de explicar cómo usó una herramienta de forma contenida y deliberada es más útil para el ecosistema que otro caso de éxito sin metodología.