He construido con IA, en poco más de un día, una herramienta de autor gratuita para crear cursos e-learning: conviertes un PDF o un PowerPoint en un curso SCORM, le añades preguntas, vídeos o tarjetas y lo subes a tu plataforma de formación. Todo sin que el archivo salga de tu ordenador. Lo que lo hizo posible no fue saber pedírselo a la IA, sino un método: una IA que construye y varios «críticos», otras IA que revisan su trabajo buscando fallos, por turnos y con reglas claras. Aquí cuento cómo funciona y lo que no salió bien. Al final está el prompt (las instrucciones completas que le di a la IA), para que lo adaptes.
Todo empezó con un PDF y una herramienta online que prometía convertirlo en SCORM en un minuto.
Lo hacía. Pero antes había que subir el archivo a sus servidores. Era un documento de un cliente, y ahí me quedé atravesada. Una sube eso y ya no sabe dónde vive ni quién lo lee.
Así que me propuse lo contrario: una herramienta de autor que hiciera lo mismo, y algo más, sin que el archivo saliera nunca del ordenador. Todo ocurre en el navegador. No hay que crear cuenta, no hay un servidor que guarde nada y la herramienta no lleva IA dentro: la IA solo se usó para fabricarla.
Ya te adelanto el final: la herramienta existe, es gratuita y está en curiosea.org/herramientas/pdf-a-scorm. Lo interesante no es eso. Es cómo se hizo.
¿Por qué no basta con pedirle a la IA «hazme una aplicación»?
Porque la IA se revisa mal a sí misma. Cuando termina algo, repasa lo que ha pensado, lo encuentra coherente y da el trabajo por bueno. Nos pasa a todos al releer un texto propio: leemos lo que queríamos escribir, no lo que escribimos.
Yo lo comprobé pronto. Pedía una función, la IA decía que estaba hecha y probada, y en cuanto la usaba aparecía el fallo. No mentía. Simplemente nadie había mirado con otros ojos.
La solución fue copiar algo que en cualquier empresa de software es normal: separar a quien construye de quien revisa. Con IA eso se puede montar en una sola conversación, porque la IA puede repartir el trabajo entre varios agentes: copias de sí misma, cada una con su encargo, que trabajan por separado. El método lo conocí en el máster de IA que estoy haciendo, y tiene autor: Matt Shumer lo bautizó como gauntlet loop en julio de 2026, después de que se hiciera viral en X su demo de un videojuego construido entero por agentes de Claude. Lo explica en How to Run a Gauntlet Loop. Viene a ser «el bucle del pasillo de castigo». Yo lo llamo bucle con críticos, que suena menos medieval.
En su versión, cada parte del trabajo tiene una IA que construye y otra que critica. La que critica no ve lo que la primera ha ido pensando, y compara el resultado a ciegas con un ejemplo de buena calidad. Yo me quedé con esa idea y la adapté a una herramienta de formación: varios críticos especializados en vez de uno, una lista de comprobaciones medible y un máximo de rondas.
¿Cómo funciona el bucle con críticos?
Hay un agente constructor, que es el que programa. Y hay varios críticos, cada uno con un encargo distinto y una condición: no ven las explicaciones del constructor. Solo ven el resultado: la herramienta y su código. Si leyeran sus explicaciones, se dejarían convencer por ellas.
En mi caso fueron estos:
- Funcional. Comprueba, punto por punto, que cada función hace lo que tiene que hacer.
- Seguridad. Hace de atacante: prueba archivos trucados, intenta colar instrucciones maliciosas en los textos y vigila que no salga ningún dato.
- Accesibilidad. Usa la herramienta solo con teclado y con lector de pantalla.
- Usuaria nueva. No ha visto nunca el código. Con la ayuda como única guía tiene que convertir un PDF, montar un curso con preguntas y subirlo a un LMS. Cada atasco es un fallo.
- Experta en UX y diseño. Compara a ciegas capturas de nuestra herramienta y de otras del mercado. Si prefiere otra, tiene que explicar por qué.
Cada crítico devuelve los fallos numerados y con una gravedad: bloqueante, importante o menor.
Hay uno que hace y varios que miran. Funciona en tres pasos que se repiten:
- Constructor. Hace una versión.
- Críticos. La revisan, cada uno por su lado y con su papel.
- Fallos. Juntan lo que han encontrado, cada fallo con su gravedad.
Y de ahí, vuelta al constructor, que corrige esos fallos sobre lo que ya hizo, sin empezar de cero. Los críticos vuelven a revisar y así sucesivamente.
Cada vuelta es una ronda. Se para cuando ningún crítico encuentra nada bloqueante ni importante, o al llegar a cinco rondas. En la práctica bastaron dos o tres.
Hay una regla que parece pequeña y lo sostiene todo. La IA va dejando pruebas automáticas: pequeños exámenes que comprueban solos que cada cosa sigue funcionando. Esas pruebas no se tocan para que salgan bien. Si una mejora rompe algo que funcionaba, se arregla la mejora. Sin esa regla, la IA tiene la tentación de cambiar el examen en vez de estudiar.
¿Cómo se monta un prompt así?
El prompt, el texto con las instrucciones que le das a la IA, tiene ocho partes, y cada una está por algo. Si lo adaptas, esto es lo que no te puedes saltar.
1. Contexto y referencias. Un archivo que explique qué hay en la carpeta y qué está ya decidido, y una carpeta con capturas de herramientas del mercado. Las capturas enseñan recorridos mejor que cualquier descripción. Con una regla escrita: inspirarse, no copiar textos, logotipos ni diseño.
2. Un papel con nivel de exigencia. «Actúa como director técnico exigente de un producto de e-learning.» Fija el listón: decide, prioriza y no da nada por bueno sin probarlo.
3. Un principio que no se negocia. El mío: el archivo nunca sale del ordenador. Al ponerlo arriba condiciona todas las decisiones técnicas sin tener que repetirlo.
4. Qué hacer y qué no. Las funciones, en verbos y con ejemplos. Y la lista de lo que queda fuera, que importa tanto como la otra: sin ella, la IA «mejora» por su cuenta y gasta tiempo en lo que no pediste.
5. El equipo y el proceso. Quién construye, qué críticos revisan, qué ve cada uno y qué devuelve.
6. Una lista de verificación. «Terminado» convertido en cosas medibles: pruebas automáticas que pasan, cero errores técnicos en el navegador, accesibilidad sin incidencias, capturas en móvil y escritorio sin desbordes. Sin lista, la IA decide sola cuándo ha acabado. Y suele decidirlo pronto.
7. Cuándo parar. Todos aprueban, o un máximo de rondas. Protege el tiempo y obliga a entregar con una lista honesta de lo pendiente.
8. Qué entregar. La herramienta, las pruebas y un informe con resultados, límites e instrucciones de instalación para alguien que no programa. Ese informe fue la memoria del proyecto: cada versión empezaba leyendo el de la anterior.
Y luego una cosa que aprendí por las malas: una mejora grande por versión. Pedirlo todo de golpe sale peor que ir capa a capa. Yo fui así: conversor, editor, vídeo, maquetas y tema, tarjetas e infografías, centro de ayuda, imágenes. Nueve versiones en poco más de un día: empecé un domingo por la tarde y el lunes por la noche estaba publicada la novena. Muchas de esas horas la IA trabajaba sola, también de madrugada.
¿Qué no salió bien?
Bastantes cosas, y conviene contarlas.
Los agentes no ven lo que ve una persona. Tras una actualización, abrí la vista previa y las diapositivas salían apiladas y de tamaños distintos. Pensé que se había roto el diseño. No: yo había activado el modo accesible días antes, el navegador lo recordaba y el botón solo cambiaba de color. Ningún crítico lo vio, porque todos sabían lo que significaba ese botón. Ahora dice «activado» o «desactivado» con letras.
Lo que no es código también falla. Al publicar una versión, mi navegador mezclaba la página antigua, que tenía guardada (la caché), con el código nuevo, y el curso de ejemplo daba error. Los críticos trabajaban con una copia en el ordenador, no con la web publicada, así que no podían verlo. Hubo que revisar aparte la web real: caché, cookies y estadísticas.
No todos los críticos aportan siempre. Durante varias versiones hubo uno que comprobaba que los proyectos antiguos de los usuarios seguían abriéndose igual. Pero la herramienta aún no la usaba nadie: no había proyectos antiguos que proteger. Lo quité. El equipo se elige para cada versión.
Es lento y cuesta. Cada versión tardaba entre dos y tres horas y gasta buena parte del uso que incluye tu plan de IA (lo que se mide en «tokens»). Para las tareas mecánicas, como pasar comprobaciones o hacer capturas, conviene pedir un modelo de IA más barato. Para pensar a fondo, por ejemplo en seguridad, el más potente.
Y un límite de fondo, para que no parezca magia: yo sabía lo que quería y sabía leer lo que me devolvía. Eso no lo pone el método. El método pone la disciplina.
Y otro: tan poco tiempo da para mucho, pero no para todo. Seguro que quedan detalles por pulir, y me encantará ir mejorándolos con lo que me contéis.
En resumen
- La IA que construye se revisa mal a sí misma: separa a quien construye de quien revisa.
- Cada crítico mira una cosa distinta y no ve las explicaciones del constructor.
- «Terminado» tiene que ser una lista medible, con un máximo de rondas.
- Una mejora grande por versión, y un informe al final de cada una.
- Lo que ve una persona y la web real hay que revisarlo aparte.
Aquel PDF del cliente, por cierto, ya lo convertí. No salió de mi ordenador.
¿Hablamos?
¿Has construido algo con IA para tu trabajo en formación? ¿Le pusiste revisores o te fiaste de lo que te decía? ¿Qué crítico añadirías tú? Cuéntamelo en los comentarios. Y si pruebas la herramienta y algo no te funciona, también quiero saberlo.
Preguntas frecuentes
¿Hace falta saber programar para usar este método?
Para que funcione, no hace falta escribir código, pero sí saber qué quieres y poder probar lo que te entregan. Si no entiendes nada de lo que devuelve, no sabrás si los críticos se están dejando algo.
¿Con qué herramienta de IA lo hice?
Con Claude, de Anthropic, que permite repartir el trabajo entre varios agentes desde una misma conversación. El método no depende de una marca: sirve cualquier asistente de IA que pueda trabajar con archivos y repartir tareas entre agentes.
¿Cuántos críticos hacen falta?
Depende de la versión. Yo usé entre tres y seis. Seguridad y una usuaria nueva sin acceso al código me parecen imprescindibles casi siempre; el resto, según lo que cambie.
¿Qué es una herramienta de autor?
Un programa para crear cursos e-learning sin programar. Montas pantallas con texto, imágenes, vídeos y preguntas, y lo exportas en un formato que entiende tu plataforma de formación (LMS), como SCORM. Esta es gratuita, funciona en el navegador y parte de un PDF o un PowerPoint que ya tengas.
¿La herramienta usa IA?
No. La IA se usó para construirla, pero la herramienta funciona sin IA y sin servidor. Tu archivo se procesa en tu navegador.
El prompt, por si quieres adaptarlo
Es la versión que resume en uno solo los prompts que usé a lo largo de las versiones. Lo que va entre [corchetes] lo cambias tú.
Antes de empezar, lee LEEME.md: explica qué hay en esta carpeta y las decisiones ya tomadas. En referencias/ tienes capturas de herramientas del mercado. Úsalas para entender recorridos y tipos de pantalla, nunca para copiar textos, logotipos ni diseño.
Actúa como director técnico exigente de un producto de e-learning. Vas a construir una herramienta web gratuita para [tu web] que convierta PDF y PowerPoint (.pptx) en cursos SCORM 1.2 editables.
## Principio que no se negocia
El archivo de la persona **nunca sale de su ordenador**: todo ocurre en el navegador, sin servidor, sin cuentas y sin IA. Solo archivos estáticos (HTML, CSS, JS), con las librerías incluidas en /lib, compatible con una Content-Security-Policy estricta y alojable en un hosting compartido.
## Qué tiene que hacer
1. **Importar.**
- PDF: cada página como imagen fiel.
- PowerPoint, en dos modos: «mantener el diseño» o «editar los textos». En el segundo, avisa de qué se pierde.
- Comprueba el tipo real del archivo por su contenido y pon límites de tamaño y de páginas.
2. **Editor sin líneas de tiempo ni disparadores.**
- Miniaturas reordenables.
- Diapositivas con maquetas por celdas, o un lienzo libre.
- Elementos:
- texto, imagen y vídeo (archivo con subtítulos .vtt, o YouTube/Vimeo);
- tarjetas que giran;
- zonas sensibles sobre una imagen;
- infografías;
- preguntas (una respuesta, varias respuestas, verdadero/falso), con retroalimentación;
- pantalla de resultado.
- Deshacer y rehacer.
- Tema del curso: colores, tipografías y combinaciones accesibles.
3. **Exportar.**
- SCORM 1.2, con compleción, nota, aprobado/suspenso, reanudación y tiempo.
- PDF.
- Guardar y abrir el proyecto como archivo en el ordenador.
4. **Ayudar sin IA.**
- Recorrido guiado la primera vez.
- Ayuda contextual en cada panel.
- Mensajes de error que dicen qué ha pasado y cómo arreglarlo.
- Un asistente en forma de chat que solo responde con el contenido del centro de ayuda y nunca se inventa nada.
- Un centro de ayuda con páginas reales (indexables) y capturas generadas automáticamente.
5. **Curso de ejemplo** que enseñe todos los elementos con contenido formativo de verdad, no con textos de prueba.
## Estilo
Usa el sistema de diseño de [tu web]: colores, tipografías, radios y botones. La estructura de páginas puede inspirarse en las herramientas de referencia, pero con textos y diseño propios. Responsive desde 360 px y accesible según WCAG 2.1 AA.
## Equipo y proceso (el «bucle con críticos»)
- **CONSTRUCTOR:** implementa por secciones.
- **CRÍTICOS independientes:** no ven el razonamiento del constructor, solo el código y el resultado. Cada uno devuelve los fallos numerados con su gravedad (bloqueante / importante / menor):
- **funcional:** revisa contra la lista de verificación;
- **seguridad:** archivos manipulados, XSS, CSP y que nada salga del navegador;
- **accesibilidad:** axe, teclado y lector de pantalla;
- **usuaria nueva:** no ha visto el código; con solo la ayuda, convierte un PDF, monta un curso con preguntas y lo sube a un LMS, y anota cada atasco;
- **experta en UX y diseño:** compara a ciegas capturas propias y de las herramientas de referencia, y explica qué gana cada una.
- El constructor corrige y los críticos vuelven a revisar.
## Lista de verificación («terminado» significa todo esto)
1. Pruebas automáticas (Playwright) de cada función: importar, editar, cada tipo de elemento, exportar, y abrir el SCORM con una API SCORM 1.2 simulada que compruebe la nota y el estado.
2. Ninguna prueba anterior se cambia para que pase.
3. Accesibilidad sin incidencias; capturas a 360, 768 y 1440 px sin desbordes.
4. Cero errores en consola con la CSP activa y ninguna petición a terceros.
5. Sin código simulado, TODO ni textos de relleno.
## Condición de parada
- Para cuando todos los críticos aprueben sin fallos bloqueantes ni importantes.
- Máximo 5 rondas. Si no se alcanza, detente y entrega lo pendiente con tu recomendación.
## Entrega
- La herramienta lista para subir.
- Las pruebas.
- Un INFORME.md con resultados, limitaciones e instrucciones de instalación para alguien que no es técnico.Referencias
Ilustraciones creadas con ChatGPT (OpenAI).
Deja una respuesta