114/365 · Vibe coding: iterar sin perder la pedagogía

Llevamos días hablando de vibe coding — cómo estructurar el trabajo, cómo evitar freírte, por qué los límites ayudan. Y hoy toca abordar el problema que veo más a menudo cuando docentes crean herramientas con IA: se enamoran de la tecnología y olvidan la pedagogía. Empiezan con un objetivo educativo claro — «quiero que mi alumnado practique fracciones» — y terminan con una aplicación llena de funcionalidades técnicamente impresionantes pero pedagógicamente vacías. Animaciones espectaculares, sistemas de puntos complejos, interfaces cargadas de elementos... que no enseñan nada mejor que una versión más simple habría enseñado.

Personalmente he caído en esta trampa muchas veces. Iterar con IA es tan fácil, tan tentador — «ahora añade esto», «ahora mejora aquello» — que pierdes de vista el para qué. La herramienta crece, se complica, añades capas sobre capas. Y cuando finalmente la pruebas con alumnado real, descubres que toda esa complejidad añadida no solo no mejora el aprendizaje, sino que a veces lo entorpece. Porque has añadido carga cognitiva extrínseca — elementos que distraen en lugar de apoyar — mientras que la carga cognitiva germana, la que realmente construye comprensión, se ha quedado igual o incluso ha disminuido.

Y esto conecta con algo fundamental que Sweller identificó hace décadas en su teoría de la carga cognitiva: el cerebro tiene capacidad limitada de procesamiento. Si saturas esa capacidad con elementos irrelevantes para el aprendizaje — animaciones llamativas, instrucciones complejas, interfaces confusas — no queda espacio mental para procesar lo que realmente importa: el contenido conceptual. Por eso iterar sin criterio pedagógico claro es peligroso. Puedes estar construyendo una herramienta técnicamente sofisticada pero educativamente inútil.

El problema de iterar sin brújula pedagógica

Voy a contar un ejemplo real de mi propia práctica. Hace unos meses creé una herramienta para trabajar vocabulario en inglés con tercero. Empecé simple: palabras con imágenes, el alumnado selecciona la traducción correcta, feedback inmediato. Funcionaba. Pero entonces empecé a iterar. Añadí animaciones cuando aciertan. Después un sistema de puntos. Después niveles de dificultad. Después un temporizador para añadir presión. Después sonidos. Después avatares personalizables. Después un ranking de clase.

Técnicamente era impresionante. Pero cuando lo probé con mi alumnado, fue un desastre. Los más competitivos se obsesionaron con el ranking y dejaron de prestar atención al vocabulario — solo querían acumular puntos rápido. Los más lentos se agobiaron con el temporizador y dejaron de intentarlo. Las animaciones distraían más que motivaban. Los sonidos molestaban. Y el objetivo original — aprender vocabulario — se había perdido completamente entre tanta parafernalia. Había iterado sin parar, pero sin criterio pedagógico. Y el resultado era peor que la versión simple inicial.

Este error es común porque la IA te facilita enormemente añadir funcionalidades. Le dices «ahora añade X» y lo añade en minutos. No hay fricción técnica que te obligue a pensar si realmente necesitas X. En programación tradicional, añadir una funcionalidad nueva implica horas de trabajo, así que te lo piensas dos veces antes de hacerlo. Pero con vibe coding, la facilidad de iterar puede ser contraproducente. Añades cosas porque puedes, no porque debas.

Anclar cada iteración a un objetivo pedagógico verificable

Entonces, ¿cómo iteras sin perder la pedagogía? Primera estrategia fundamental: antes de añadir cualquier funcionalidad nueva, pregúntate cómo mejora el aprendizaje específicamente. No «cómo hace la herramienta más atractiva» o «cómo la hace más moderna». Sino: ¿cómo contribuye esta funcionalidad concreta a que el alumnado comprenda mejor el concepto, practique más efectivamente la habilidad, desarrolle más profundamente la competencia?

Y necesitas ser brutalmente honesto en la respuesta. Si la respuesta es «bueno, la hace más divertida», eso no es suficiente. Porque «divertida» no equivale a «educativa». La investigación sobre gamificación — que hemos abordado en otros posts de la serie — es clara: elementos de juego que no conectan con el contenido de aprendizaje pueden aumentar el engagement superficial pero no mejoran el aprendizaje profundo. A veces incluso lo perjudican porque desvían la atención de lo importante.

Pero si la respuesta es «esta funcionalidad proporciona feedback inmediato sobre un error conceptual específico que he observado que mi alumnado comete frecuentemente, y ese feedback está diseñado según los principios de Dylan Wiliam sobre evaluación formativa efectiva», entonces adelante. Esa iteración tiene fundamento pedagógico sólido. La diferencia entre ambas respuestas marca la línea entre iterar con sentido e iterar sin rumbo.

Cuando trabajé en herramientas como EDUmind Quiz o EDUmind Motor, cada funcionalidad que añadí pasó por ese filtro. ¿Por qué incluir la opción de repetir preguntas falladas? Porque la investigación sobre práctica espaciada demuestra que revisar contenido erróneamente comprendido en múltiples ocasiones mejora la retención a largo plazo. ¿Por qué mostrar explicaciones diferenciadas según el error cometido? Porque Hattie demuestra que el feedback específico tiene un tamaño del efecto mucho mayor que el feedback genérico. Cada decisión anclada a investigación educativa, no a preferencias técnicas o estéticas.

Probar con alumnado real antes de seguir iterando

Segunda estrategia crítica: prueba cada versión significativa con alumnado real antes de seguir añadiendo funcionalidades. No iteres en bucle cerrado contigo mismo y la IA. Saca la herramienta al mundo real, observa cómo la usa tu alumnado, recoge feedback, identifica problemas reales. Y solo después, basándote en esa observación directa, decides qué iterar a continuación.

Esto es metodología de diseño centrado en el usuario aplicada a educación. Y funciona porque el alumnado usa las herramientas de formas que tú nunca anticipaste. Pulsan botones en orden incorrecto. Malinterpretan instrucciones que a ti te parecían clarísimas. Se atascan en puntos que considerabas triviales. Ignoran funcionalidades que pensabas que serían las más usadas. Toda esa información es oro puro para decidir qué iterar y cómo.

Personalmente, cuando pruebo una herramienta nueva con mi alumnado de tercero, no intervengo inmediatamente cuando veo que se atascan. Observo. Anoto. ¿Dónde se confunden? ¿Qué preguntan? ¿Qué hacen de forma diferente a lo que esperaba? ¿Qué funcionalidad usan mucho y cuál ignoran completamente? Después de 20-30 minutos de observación, tengo una lista clara de mejoras necesarias. Y esas mejoras están basadas en evidencia real, no en suposiciones.

También pregunto directamente al alumnado. «¿Qué os ha parecido difícil?», «¿Qué cambiaríais?», «¿Os ha ayudado esto a entender mejor el concepto?». Sus respuestas son directas y sinceras — los niños de 8 años no tienen filtros diplomáticos. Si algo les parece aburrido, te lo dicen. Si algo les confunde, te lo dicen. Si algo les encanta, también. Ese feedback sincero es mucho más valioso que cualquier análisis teórico que hagas desde tu perspectiva adulta de docente.

Documentar el porqué de cada iteración

Tercera estrategia: documenta por qué haces cada iteración. No solo qué cambias, sino por qué. Esto sirve a dos propósitos fundamentales. Primero, te obliga a reflexionar antes de iterar — si no puedes articular una razón pedagógica clara para un cambio, probablemente no deberías hacerlo. Segundo, crea un registro de decisiones de diseño que puedes consultar más adelante o compartir con otros docentes que quieran adaptar tu herramienta.

Yo mantengo un documento de iteraciones para cada proyecto de vibe coding. Incluye: versión (v1.0, v1.1, etc.), fecha, qué cambió, por qué cambió (observación específica que motivó el cambio), y resultado esperado. Por ejemplo: «v1.2 - 15/03/2025 - Añadido botón 'Ver explicación' en preguntas falladas - Observé que 5 de 20 estudiantes repetían el mismo error sin entender por qué - Esperado: que puedan acceder a explicación conceptual sin tener que preguntarme, fomentando autonomía».

Esa documentación es valiosa porque cuando vuelves a un proyecto meses después — para actualizarlo, mejorarlo, o crear algo similar — puedes recordar exactamente por qué tomaste cada decisión. Y cuando compartes la herramienta con otros docentes, ese historial de decisiones les ayuda a entender el razonamiento pedagógico detrás del diseño. No es solo código — es pedagogía codificada, y esa diferencia importa.

Resistir la tentación de la complejidad innecesaria

Cuarta estrategia, y esta requiere disciplina consciente: resiste activamente la tentación de añadir complejidad que no sirve al aprendizaje. La IA te va a sugerir constantemente mejoras técnicas, funcionalidades adicionales, formas de hacer la herramienta más sofisticada. Y muchas de esas sugerencias sonarán geniales. Pero pregúntate siempre: ¿esto hace que el alumnado aprenda mejor, o solo hace que la herramienta parezca más impresionante?

Hay un principio de diseño que me encanta y que aplico constantemente: la simplicidad es sofisticación. Las mejores herramientas educativas no son las más complejas — son las que resuelven un problema pedagógico concreto de la forma más simple posible. Cuando miro herramientas como EDUmind App o EDUmind Motion, lo que me gusta no es la complejidad técnica, sino cómo cada elemento tiene un propósito pedagógico claro y no hay nada superfluo.

También conecta con el concepto de MVP (Producto Mínimo Viable) que hemos mencionado en posts anteriores. El MVP no es una versión pobre de tu visión ideal — es la versión más simple que cumple el objetivo pedagógico central. Y a menudo, esa versión simple funciona mejor que versiones más complejas. Porque es más fácil de usar, más rápida de cargar, menos propensa a errores, y más fácil de mantener y actualizar.

Cuando sientas la tentación de añadir «solo una funcionalidad más», para. Pregúntate: ¿la herramienta actual ya cumple su objetivo pedagógico? Si la respuesta es sí, quizá no necesitas añadir nada. Quizá lo que necesitas es probarla más extensamente, recoger más datos sobre su efectividad, usarla con diferentes grupos. La mejora no siempre significa añadir — a veces significa consolidar lo que ya tienes y entenderlo mejor.

Conectar iteración con evaluación formativa continua

Quinta estrategia: trata el proceso de iteración como evaluación formativa de tu herramienta. Dylan Wiliam define evaluación formativa como cualquier evidencia sobre el aprendizaje del alumnado que se usa para ajustar la enseñanza. Aplica ese mismo principio a tus herramientas: cualquier evidencia sobre cómo el alumnado usa la herramienta debería informar cómo la ajustas.

Esto significa recoger datos sistemáticamente. No solo impresiones generales — datos concretos. ¿Cuántos estudiantes completan la actividad? ¿Dónde se atascan más frecuentemente? ¿Qué errores cometen más a menudo? ¿Cuánto tiempo les lleva? ¿Repiten la actividad voluntariamente o solo cuando se les pide? ¿Mejoran sus resultados en evaluaciones posteriores sobre ese contenido? Todas esas preguntas te dan información sobre si la herramienta está funcionando pedagógicamente.

Y después usas esa información para iterar con propósito. Si ves que la mayoría se atasca en el mismo punto, ese punto necesita mejor andamiaje — quizá una pista adicional, una explicación más clara, un ejemplo trabajado. Si ves que completan la actividad muy rápido sin errores, quizá es demasiado fácil y necesitas aumentar la complejidad. Si ves que la abandonan a mitad, quizá es demasiado larga o frustrante. Datos reales informando decisiones de diseño pedagógico — eso es iterar con sentido.

Resumen

Puntos clave sobre iterar sin perder la pedagogía:

• Ancla cada iteración a un objetivo pedagógico verificable. Antes de añadir funcionalidades, pregúntate cómo mejoran el aprendizaje específicamente, no solo cómo hacen la herramienta más atractiva o moderna.
• Prueba con alumnado real antes de seguir iterando. No iteres en bucle cerrado. Observa cómo usan la herramienta, recoge feedback directo, identifica problemas reales antes de decidir qué cambiar.
• Documenta el porqué de cada cambio. Mantén un registro de decisiones de diseño que incluya qué cambió, por qué, y qué resultado esperas. Esto te obliga a reflexionar y crea conocimiento reutilizable.
• Resiste la complejidad innecesaria. Más funcionalidades no siempre significa mejor aprendizaje. A menudo la versión más simple que cumple el objetivo pedagógico es la más efectiva.
• Trata la iteración como evaluación formativa continua. Recoge datos sistemáticos sobre uso real y úsalos para informar mejoras concretas basadas en evidencia
  
  Nos vemos mañana 😀
  Luis