Durante los últimos cursos universitarios he venido creando decenas de infografías interactivas y simuladores (single page applications o SPA) para apoyar mis clases. Actualmente aplico este enfoque en dos asignaturas de la Universitat Jaume I (UJI):
- 🖥️ Administración de sistemas informáticos (4.º curso del grado en Ingeniería Informática, código EI1044): https://sites.google.com/uji.es/ei1044-2026
- 🎮 Ingeniería del software (3.er curso del grado en Diseño y Desarrollo de Videojuegos, código VJ1224): https://sites.google.com/uji.es/vj1224-2026
(Nota: ambos espacios están vivos y en revisión continua a lo largo del cuatrimestre, mostrando actualmente los contenidos desplegados de los primeros temas).
En estas materias, las SPA cubren desde modelos de decisión multicriterio y algoritmos PROMETHEE hasta pequeños laboratorios de análisis de rendimiento, detección de cuellos de botella o recursos didácticos tan visuales como la clásica analogía de la pizza para entender los modelos de computación en la nube (On-premise, IaaS, PaaS y SaaS).
Hasta ahora, mi flujo habitual de trabajo descansaba en dos herramientas muy familiares en el ecosistema educativo de Google:
- 💬 Conversación con un Gem personalizado en la app web de Gemini, aportando los apuntes y PDF del tema.
- 🎨 Creación iterativa en Canvas de cada SPA en HTML, CSS y JavaScript (agitados, nunca mezclados), dentro de un archivo único.
- 📋 Copiar el bloque de código a mano e insertarlo en el componente de inserción de Google Sites.
- 🔁 Si detectaba una errata o quería retocar un estilo… vuelta a copiar y pegar.
El problema: la fragilidad del proceso manual y los límites de escala
Aunque este sistema me permitía arrancar con rapidez y trabajar desde cualquier lugar, pronto aparecieron cuellos de botella propios de un mantenimiento artesanal:
- Reescrituras incontroladas: El Canvas de Gemini es caprichoso. Pedir un cambio puntual a menudo provoca que el modelo regenere todo el archivo, en ocasiones liándola bastante parda. Sí, hay un comando deshacer, pero a veces me ha dejado tirado. Eso obliga a guardar copias de seguridad manuales de versiones intermedias para no perder avances funcionales.
- Refactorizaciones globales inviables: Cambiar de golpe el pie de página, los enlaces al departamento o la licencia en más de 20 recursos era una pesadilla manual.
- El tope oculto de Google Sites: El cajetín de inserción de código tiene un límite práctico (~50–65 KB). Cuando el simulador o la lógica JS crecía, Sites sencillamente fallaba al guardar los cambios en Google Drive.
La solución: tratar los materiales como software (con Antigravity y Gemini 3.8 Flash)
Esta misma tarde decidí dar el salto y trasladar todo el proyecto a un entorno de desarrollo asistido por agentes. Con la asistencia directa de Antigravity 2.0 trabajando codo con codo con el modelo Gemini 3.8 Flash (Medium), el cambio de paradigma ha sido radical:
- 🌿 Control de versiones con Git: Cada modificación se aplica quirúrgicamente en líneas concretas del archivo, manteniendo un historial limpio, ramas y trazabilidad total.
- 📦 Refactorizaciones en bloque en segundos: Le pedí homogeneizar firmas de autoría, licencias CC BY-NC-SA y enlaces institucionales en todo el repositorio, y lo resolvió de forma impecable en un abrir y cerrar de ojos.
- 🚀 GitHub Pages + inserción por URL (mi verdadero CD): Decidí publicar el repositorio en GitHub Pages e incrustar las SPA en Sites mediante URL en lugar de código crudo. ¿El resultado? El límite de tamaño de Sites desaparece y, gracias a GitHub Pages, un simple
git pushactualiza al instante lo que ven mis estudiantes sin tener que tocar jamás el editor de Sites. - 🎛️ Detección contextual de iframe para navegación: En Google Sites la inserción se realiza página a página (cada tema o sección de Sites aloja una SPA concreta). Por tanto, los enlaces de navegación secuencial («Anterior» / «Siguiente») diseñados para moverse entre archivos dentro de GitHub Pages no tendrían sentido aquí: atraparían la navegación dentro del marco del iframe en lugar de avanzar en la estructura del sitio de Google Sites. Para resolverlo, he implementado un detector ligero que identifica si la SPA está embebida y oculta automáticamente esos controles para evitar inconsistencias de navegación.
- 🛡️ Plantilla maestra y sandboxing resuelto: Cuando detecté que la API de Clipboard moderna fallaba dentro de los iframes de Sites por políticas de permisos (
Permissions-Policy), creé con la asistencia del agente una plantilla maestra con fallback transparente (execCommand). Ahora todas las SPA heredan esa robustez de serie.
💡 «Tener a tiro de agente cualquier cambio en los materiales del curso —desde un ajuste quirúrgico de tres líneas hasta una refactorización masiva en 20 recursos a la vez— con publicación inmediata es, sencillamente, una auténtica gozada.»
🔄 Hacia la sustitución progresiva de Google Sites por GitHub Pages
Google Sites ha sido un andamiaje fabuloso para estructurar la asignatura y presentar los contenidos de manera limpia y accesible. De hecho es lo que uso siempre en mis clases para secuenciar los bloques unitarios de teoría / debate / actividad. Sí, los PDF de docenas de páginas me producen sarpullidos.
Sin embargo, la propia madurez del proyecto me está empujando de forma natural hacia el siguiente paso: la sustitución progresiva de Google Sites por el propio portal alojado en GitHub Pages. Incrustar mediante URL ha sido el puente perfecto, pero eliminar la capa de Sites en el futuro me permitirá:
- Suprimir definitivamente las fricciones de los
<iframe>: problemas de redimensionamiento dinámico, políticas de permisos restrictivas para APIs del navegador o enlaces secuenciales confinados en marcos. Cosas, enm definitiva, que deben ser tenidas muy en cuenta cuando diseñas contenidos interactivos que vas a incrustar en un marco o un elemento de inserción de página completa de Sites. - Centralizar toda la experiencia en un único portal web con buscador, filtrado por temas y visor modal integrado, desarrollado directamente en el repositorio.
- Reducir la pila tecnológica: un solo punto de verdad donde código, contenidos y publicación conviven sin capas intermedias.
index.html), con búsqueda instantánea y filtrado por temas, listo para servir como punto de acceso único a todos los módulos docentes.💻 Un punto clave: democratización del hardware en el aula
Aunque he trabajado sobre la interfaz gráfica de Antigravity 2.0, todo este flujo es 100% reproducible desde la terminal mediante su interfaz de línea de comandos en la consola de texto del sistema (Antigravity CLI).
Esto me parece especialmente prometedor en el ámbito educativo: permite disponer exactamente de la misma potencia y flujo de trabajo agéntico asistido por Gemini 3.8 Flash en terminales ligeras o equipos modestos, como los Chromebooks tan habituales en aulas y laboratorios docentes donde la comunidad de Google Workspace for Education se mueve a diario.
Cierto es que desde que Google desmembró el artista anteriomente conocido como Antigravity en tres pedazos (2.0, IDE, CLI), el componente agéntico (del que te hablo aquí) ha adelgazado yo diría que sensiblemente. Y es que siempre viene bien tener a mano un alternativa más liviana, aunque también hay que decir que CLI necesita correr sobre el subsistema Linux de tu Chromecosa.
🔮 Lo que viene: mejoras a partir del tema 3
Este pipeline no se queda aquí. Para los siguientes módulos de la asignatura ya tengo planificado el siguiente salto:
- 📂 Ingesta directa en el repositorio: Volcar los PDF y esquemas fuente en una carpeta local para que el agente extraiga conceptos y cree una versión preliminar de las SPA interactivas sin intermediarios.
- 🤖 Generación automatizada del catálogo: Un script que escanee las carpetas del repositorio y reconstruya dinámicamente el catálogo de recursos de la portada del portal (
index.html). - 🧪 Pruebas visuales y auditoría con Chrome DevTools: Ejecutar pruebas automatizadas en local a través del control automatizado, vía el servidor MCP de las herramientas para desarrollador del navegador, para cazar errores de JavaScript en consola y validar maquetaciones móviles antes de desplegar a producción.
🔗 Repositorio del proyecto
Si tienes curiosidad por ver la estructura, las SPA o la propia plantilla maestra:
👉 https://github.com/pfelipm/uji-ei1044
💬 Conclusión
La IA generativa en educación alcanza su verdadero valor cuando dejamos de verla como una simple ventana de chat y la integramos como un compañero de pair-programming dentro de las buenas prácticas de la ingeniería de software: Git, componentes reutilizables y despliegue continuo.
Esto no para. Y espérate que vienen curvas. ¡Seguro! 😅
