111/365 · Vibe coding: de la idea al prototipo en 6 pasos

Aprende vibe coding: convierte tus ideas en prototipos funcionales en 6 pasos usando IA, sin necesidad de ser programador. Guía práctica educativa.

Llevamos días hablando de IA en educación — cómo usarla, cuándo falla, por qué necesitamos pensamiento crítico. Y ahora toca abordar algo que me tiene absolutamente enganchado desde hace meses: vibe coding. Esa forma intuitiva de convertir una idea en un prototipo funcional usando IA como compañera de desarrollo, sin necesidad de ser ingeniero informático ni de dominar lenguajes de programación al dedillo. Porque lo que antes me habría llevado semanas o meses — o directamente sería imposible para mí — ahora lo puedo hacer en horas o días. Y eso cambia radicalmente lo que puedes hacer en el aula.

Juan José de Haro, docente de secundaria y pionero en redes sociales educativas y ahora en IA aplicada a educación, lo describe perfectamente: el vibe coding educativo no se refiere a una tecnología concreta ni a un lenguaje de programación determinado, sino a una forma de crear recursos digitales priorizando la intención pedagógica, la rapidez de iteración y la coherencia funcional por encima del dominio exhaustivo del código. Exactamente eso. No se trata de ser programador — se trata de saber qué quieres crear y dialogar con la IA para construirlo progresivamente.

Personalmente, he creado decenas de herramientas usando este método. Desde cuestionarios adaptativos hasta aplicaciones completas para trabajar conceptos específicos con mi alumnado de tercero. Y lo que me fascina es que el proceso es replicable — hay pasos claros que, si los sigues, aumentan enormemente las probabilidades de que termines con algo que funcione de verdad y que sea útil. Hoy voy a compartir esos seis pasos fundamentales que uso para pasar de una idea nebulosa a un prototipo operativo.

Paso 1: Pensar con exactitud qué quieres hacer

Este primer paso parece obvio, pero es donde la mayoría falla. No puedes empezar diciéndole a la IA «hazme algo educativo». Necesitas claridad absoluta sobre qué tipo de herramienta quieres crear: ¿un programa descargable? ¿Una aplicación web que funcione en el navegador? ¿Un sistema complejo tipo SaaS (Software as a Service) con gestión de usuarios y bases de datos? ¿Un simple cuestionario interactivo? ¿Una colección de recursos integrados? Cada tipo de producto requiere un enfoque diferente, tecnologías diferentes, complejidad diferente.

En mi caso, cuando empecé con esto hace meses, cometí el error de no definir bien. Le pedía a ChatGPT «crea una actividad para trabajar ortografía» sin especificar si quería algo imprimible, algo digital interactivo, algo que se autoevaluara, algo colaborativo. Y claro, la IA me daba algo genérico que luego había que rehacer completamente. Ahora soy mucho más preciso desde el inicio: «Necesito una aplicación web responsive que funcione en navegador, sin necesidad de instalación, donde el alumnado pueda practicar sumas y restas con números hasta el 100, con feedback inmediato y registro de progreso». Esa claridad inicial ahorra horas de iteración posterior.

Y esto conecta con algo fundamental en diseño educativo: el concepto de MVP (Minimum Viable Product o Producto Mínimo Viable). No intentes crear la herramienta perfecta y completa desde el principio. Define la versión más simple que cumpla el objetivo educativo básico. Después ya iterarás y añadirás funcionalidades. Pero si empiezas queriendo crear algo demasiado complejo, nunca lo terminarás — o te frustrarás en el intento.

Paso 2: Definir paso a paso el qué, el objetivo, el contexto y el producto final

Una vez que sabes qué tipo de herramienta quieres, necesitas detallar. Y aquí es donde la pedagogía entra en juego de forma directa. No estás creando tecnología por crear — estás creando una herramienta que debe resolver un problema educativo concreto, con alumnado concreto, en un contexto concreto. Por eso necesitas definir con precisión cuatro elementos clave antes de empezar a codificar nada.

Primero: el qué exactamente. Describe las funcionalidades específicas que necesitas. No «un cuestionario», sino «un cuestionario que presente 10 preguntas aleatorias de un banco de 50, que muestre feedback diferenciado según si la respuesta es correcta o incorrecta, que permita al alumnado repetir hasta que acierten todas». Cuanto más específico seas, mejor será el resultado que genere la IA.

Segundo: el objetivo pedagógico. ¿Qué quieres que aprendan? ¿Qué competencia están desarrollando? ¿Cómo se conecta con el currículo? Esto te obliga a pensar en términos educativos, no solo técnicos. Y cuando se lo explicas a la IA, puede sugerirte funcionalidades que no habías considerado pero que apoyan mejor ese objetivo. Por ejemplo, si le dices que el objetivo es desarrollar metacognición sobre el proceso de resolución de problemas, puede proponerte que la herramienta incluya preguntas reflexivas después de cada ejercicio.

Tercero: el contexto de uso. ¿Dónde y cómo se va a usar esta herramienta? ¿En el aula con tu supervisión directa o en casa de forma autónoma? ¿En ordenadores o en tablets? ¿Con conexión a Internet estable o en entornos con conectividad limitada? ¿Individualmente o en grupos? Cada respuesta afecta decisiones de diseño. Si es para usar en tablets sin conexión fiable, necesitas que funcione offline. Si es para trabajo en grupos, necesitas pantalla compartida o funcionalidades colaborativas.

Cuarto: el producto final deseado. ¿Cómo debe verse y sentirse? ¿Necesita ser visualmente atractivo o la funcionalidad prima sobre la estética? ¿Debe tener una interfaz minimalista para no distraer o puede ser más rica en elementos visuales? ¿Qué nivel de complejidad pueden manejar tus estudiantes? Con mi alumnado de tercero, necesito interfaces muy claras, con instrucciones visuales, con botones grandes, con colores que guíen la atención. Eso es muy diferente de lo que diseñaría para secundaria o bachillerato.

Paso 3: Iterar hasta pulir

Una vez que tienes claridad sobre qué crear y para qué, empieza el proceso iterativo. Y aquí es donde el vibe coding se diferencia radicalmente de la programación tradicional. No escribes todo el código de golpe y después pruebas a ver si funciona. Vas construyendo progresivamente, probando constantemente, ajustando, refinando. Dialogas con la IA: «ahora añade esta funcionalidad», «esto no funciona como esperaba, cámbialo así», «mejora la accesibilidad de este elemento».

El proceso es orgánico y requiere paciencia. Personalmente puedo hacer entre 20 y 50 iteraciones para una herramienta medianamente compleja. Empiezo con la estructura básica: «crea el HTML y CSS para una página con estas secciones». Pruebo. Funciona. Siguiente paso: «añade JavaScript para que cuando pulse este botón ocurra esto». Pruebo. Falla. Pido a la IA que revise el error. Lo corrige. Pruebo. Ahora funciona. Siguiente paso: «añade validación para evitar que introduzcan datos incorrectos». Y así sucesivamente.

Lo interesante es que cada iteración te va enseñando cómo funciona el código, incluso si no eres programador. Empiezas a reconocer patrones, a entender qué hace cada parte, a anticipar qué puede fallar. Y eso conecta con teorías constructivistas del aprendizaje — aprendes haciendo, probando, equivocándote, corrigiendo. Piaget estaría orgulloso de este proceso: puro conflicto cognitivo resuelto mediante acción y reflexión.

Herramientas como EDUmind Pasos nacieron exactamente así — iteración tras iteración, probando con alumnado real, viendo qué funcionaba y qué no, ajustando la interfaz, simplificando procesos, añadiendo ayudas visuales. No salió perfecta a la primera (ni a la décima), pero cada versión era mejor que la anterior porque incorporaba aprendizaje real del uso en contexto.

Paso 4: Subir el producto a un servidor o espacio accesible

Bien, ya tienes algo que funciona en tu ordenador. Ahora necesitas que sea accesible para tu alumnado. Y aquí muchos docentes se atascan porque piensan que necesitan conocimientos técnicos avanzados, contratar hosting caro, configurar servidores. La realidad es mucho más simple: existen opciones gratuitas y sencillas que te permiten publicar aplicaciones web en minutos.

Opciones que uso habitualmente: GitHub Pages (gratis, ideal para páginas estáticas), Netlify (gratis, permite despliegue automático), Vercel (gratis, muy bueno para aplicaciones con frameworks modernos), incluso Google Sites o simples carpetas compartidas si la aplicación es muy básica. La clave es elegir la opción que se adapte a la complejidad de tu herramienta. Si es HTML/CSS/JavaScript puro sin backend, GitHub Pages es perfecto. Si necesitas funcionalidades más complejas, Netlify o Vercel son mejores opciones.

Y aquí la IA también te ayuda enormemente. Le dices: «tengo este código, quiero publicarlo en GitHub Pages, guíame paso a paso». Y te da instrucciones detalladas adaptadas a tu nivel de conocimiento técnico. Yo he usado este proceso decenas de veces para publicar herramientas como EDUmind Quiz o EDUmind Motor — aplicaciones funcionales, accesibles desde cualquier navegador, sin instalación, sin complicaciones.

Lo importante es que el producto esté disponible con una URL permanente que puedas compartir con tu alumnado. Nada de «descargad este archivo y abridlo en vuestro navegador» — eso genera problemas técnicos innecesarios. Una URL limpia que funcione en cualquier dispositivo es el objetivo.

Paso 5: Probar y probar hasta lograr el resultado, revisando lo visible y lo invisible

Aquí es donde el pensamiento crítico que hemos trabajado en posts anteriores se vuelve crucial. Una vez que la herramienta está publicada, necesitas probarla exhaustivamente. Y no solo tú — también con alumnado real, porque ellos van a usar la herramienta de formas que nunca anticipaste. Van a pulsar botones en orden incorrecto, van a introducir datos raros, van a intentar cosas que no deberían funcionar. Y tu herramienta tiene que resistir todo eso.

Pero además de probar lo visible — la interfaz, las funcionalidades, la experiencia de usuario — necesitas revisar lo invisible: el código subyacente. Y aquí es donde mucha gente que hace vibe coding comete errores graves. Aceptan el código que genera la IA sin revisarlo críticamente, sin verificar si está bien estructurado, si es eficiente, si tiene vulnerabilidades de seguridad, si sigue buenas prácticas.

Personalmente, una vez que tengo una versión que parece funcionar, le pido a la IA que haga una auditoría del código adoptando el rol de «auditor senior de sistemas» o «ingeniero de sistemas senior». Le digo: «revisa este código completo desde la perspectiva de seguridad, eficiencia, accesibilidad, y buenas prácticas. Identifica problemas y sugiere mejoras». Y casi siempre encuentra cosas que yo no había visto: código redundante, posibles fallos de seguridad, problemas de accesibilidad para personas con discapacidad, ineficiencias que ralentizan la aplicación.

Esta fase de revisión profunda es fundamental. Herramientas como EDUmind App han pasado por múltiples rondas de auditoría y corrección antes de llegar a versiones estables. Y el proceso no termina nunca — cada vez que descubro un bug o una mejora posible, vuelvo a iterar. La documentación también entra aquí: comentar el código para que sea entendible, crear guías de uso para el alumnado, preparar instrucciones para otros docentes que quieran usar o adaptar la herramienta.

Paso 6: Poner la licencia al producto final

Y llegamos al último paso, que muchos olvidan pero que es crítico si crees en el conocimiento como bien común: licenciar tu trabajo. Todas las herramientas que creo las publico con licencia GNU GPL v3, que garantiza que el software será siempre libre — que cualquiera puede usarlo, estudiarlo, modificarlo, distribuirlo, mejorar sobre él. Y que cualquier derivación también debe ser libre.

Esto no es solo una cuestión técnica o legal — es una posición pedagógica y ética. Yo soy más del software libre y creo firmemente que la IA va a ayudar a darle un enorme impulso. Si creamos herramientas educativas con financiación pública, con tiempo que nos pagan las administraciones, usando IA entrenada con conocimiento colectivo, esas herramientas deben volver al bien común. No tiene sentido privatizar ese conocimiento, ponerle barreras de acceso, restringir quién puede usarlo o modificarlo.

Juan José de Haro, que lleva años trabajando con software libre en educación (eXeLearning, recursos educativos abiertos, herramientas colaborativas), defiende esto constantemente. El software libre debería ser la opción preferente de los centros educativos porque está basado en el altruismo de ofrecer el trabajo a los demás con la única recompensa del beneficio ajeno. Y cuando añadimos IA al proceso — cuando docentes sin formación técnica avanzada pueden crear herramientas potentes y compartirlas libremente — estamos democratizando la creación de recursos educativos de una forma nunca vista.

Elegir la licencia adecuada es sencillo con ayuda de la IA. Le preguntas qué licencia se adapta mejor a tus objetivos (si quieres que sea completamente libre, si permites uso comercial o no, si exiges que las derivaciones sean también libres) y te guía en el proceso. Añades el archivo de licencia a tu repositorio, incluyes la nota en tu código, y listo. Tu trabajo pasa a formar parte del conocimiento libre accesible para cualquiera.

De la teoría a la práctica: crear herramientas que realmente usen en clase

Estos seis pasos no son