Mi hijo encontró los bugs: cómo montamos con IA un mapa de España para estudiar jugando

Cuando uno dice quiero una web para estudiar el mapa de España, parece que la parte difícil es conseguir el mapa. Y sí, hace falta una base geográfica decente, provincias reales, comunidades autónomas y una forma de pintar cada zona sin inventarse fronteras.

Pero el problema de fondo era otro: cómo convertir un mapa en una actividad de estudio. No bastaba con colorear España y poner etiquetas. Había que decidir qué pasa cuando el niño toca una provincia, cuando quiere ver los nombres, cuando quiere esconderlos, cuando se equivoca y cuando termina un reto.

La primera versión cumplía la idea general, pero todavía olía a prototipo. El mapa estaba ahí, los botones también, pero la experiencia tenía fricciones: demasiada cabecera, información lateral ocupando sitio, colores parecidos, etiquetas que se pisaban y un modo reto que, si mirabas con ojos de niño, tenía atajos absurdos.

Hay una diferencia enorme entre una aplicación que compila y una aplicación que funciona para quien la va a usar. En este caso, esa diferencia la puso Héctor.

El modo reto tenía un fallo evidente cuando lo mirabas desde el juego: si al pasar el ratón por encima aparecía el nombre de la comunidad o provincia, la pregunta perdía toda la gracia. No estabas recordando; estabas leyendo la respuesta.

También aparecieron errores de lógica: después de fallar, el sistema revelaba la respuesta correcta y permitía volver a pulsarla como si fuera un nuevo intento. El botón Siguiente podía usarse antes de responder. Y si se pulsaba varias veces la respuesta correcta, el marcador podía inflarse. Son bugs pequeños en código, pero enormes en aprendizaje: convierten un reto en algo trampeable.

Aquí es donde la historia se vuelve interesante para hablar de IA sin vender humo. ChatGPT ayudó a ordenar los problemas, pero no decidió por su cuenta qué era importante. Las pautas salieron de observar el uso real.

Héctor decía lo que estaba mal con una precisión muy útil: esto tapa Galicia, esto no se lee, aquí debería verse el progreso, esto no sirve porque ya me dice la respuesta, Ceuta y Melilla son muy pequeñas para pulsarlas. Ese tipo de feedback vale oro porque no habla en términos de tecnología, habla en términos de experiencia.

Después, esas observaciones se convirtieron en instrucciones para Codex: bloquear interacción tras responder, resetear estado al cambiar de nivel, evitar pistas vacías, renombrar Illes Balears a Islas Baleares, hacer que los nombres fijos estuvieran activos por defecto en modo estudio y ajustar etiquetas como Cantabria o Bizkaia para que no se pisaran.

Una de las correcciones más importantes no fue de código, sino de jerarquía visual. La primera pantalla tenía un diseño agradable, pero el mapa no mandaba lo suficiente. Para un niño que está estudiando geografía, el mapa no puede ser un componente más: tiene que ser el escenario principal.

La interfaz se fue compactando. La cabecera perdió peso. El título pasó a una sola línea: Explora el mapa de España. El personaje Héctor dejó de ocupar espacio arriba y se movió a la zona lateral. Los controles se integraron mejor y el mapa ganó presencia.

También cambiaron los colores. En un mapa educativo, repetir tonos demasiado parecidos no es un detalle estético menor: confunde. La solución fue separar mejor las familias cromáticas, alejar colores parecidos y hacer que las zonas deshabilitadas quedaran grisáceas cuando el niño decide filtrar provincias por dificultad.

Otra decisión clave fue separar bien modo estudio y modo reto. En modo estudio, el niño puede explorar sin presión: tocar zonas, ver relaciones y activar nombres fijos para que el mapa parezca una lámina imprimible.

Por eso, el modo estudio arranca ahora con Nombres fijos: sí. No obliga a pasar el ratón por cada zona para descubrirla. Primero permite mirar, orientarse y construir memoria visual.

El modo reto, en cambio, exige otra disciplina. La aplicación pregunta por una comunidad o provincia concreta, marca el progreso y no repite zonas dentro de la misma partida. Cuando se responde, el turno queda cerrado. Si aciertas, suma una vez. Si fallas, aprendes la respuesta y pasas a la siguiente. Es simple, pero esa simplicidad requiere estado bien gestionado.

Una pista que dice empieza por A no enseña casi nada. Solo convierte el reto en un juego de adivinanza por letras. Para estudiar mapas, la pista tiene que ayudar a orientar.

El sistema pasó a usar pistas espaciales: está al norte, al sur, cerca de tal zona, junto al Mediterráneo, en el interior o dentro de cierta parte de su comunidad. En provincias grandes o comunidades con muchas provincias, esto es especialmente importante porque el niño no solo necesita saber el nombre, sino situarlo mentalmente.

Ese cambio parece pequeño, pero transforma la pista en aprendizaje. No regala la respuesta: da una brújula.

Uno de los bugs detectados era casi invisible hasta que completabas la partida: al terminar, podía aparecer una pista vacía. Es el típico detalle que en desarrollo se escapa porque estás probando el flujo feliz, no el final real.

La corrección fue clara: si no hay contenido, no se muestra el componente. Y si el reto está completado, el mensaje tiene que decir algo útil, no dejar una caja vacía esperando sentido.

Esto resume una lección bastante general: una aplicación educativa no solo necesita acertar durante la pregunta. Tiene que cuidar los bordes: inicio, fallo, acierto, siguiente, reinicio, cambio de nivel y final.

El mapa de provincias completo puede ser demasiado para empezar. Así que apareció una idea práctica: permitir filtrar por comunidades según cuántas provincias tienen.

El niño puede centrarse en las sencillas, como comunidades de una provincia, o saltar a las más difíciles, como las de cinco o más provincias. También puede combinar grupos. Las zonas que no entran en el filtro no desaparecen: quedan grisáceas, como contexto deshabilitado.

Esto mantiene el mapa entero de España visible, que era una condición importante, pero reduce la carga cognitiva. El niño no estudia un recorte aislado: estudia dentro del conjunto.

La parte de Codex fue menos espectacular de lo que suele imaginarse y precisamente por eso fue útil. No se le pidió solo hazlo bonito. Se le pasaron criterios de aceptación muy concretos.

La instrucción importante era que el sistema no pudiera hacer trampas: bloquear respuestas después de fallar o acertar, impedir múltiples aciertos por clicks repetidos, deshabilitar Siguiente hasta responder, resetear correctamente al cambiar de nivel y mejorar tablet para no obligar a hacer scroll constante.

A partir de ahí, Codex hizo lo que mejor hace cuando el problema está bien descrito: tocar estado, eventos, layout, textos, rutas y despliegue. La calidad no salió de un prompt mágico, sino de un bucle de observación, pauta, implementación y verificación.

Al final, el mapa dejó de ser una página suelta y pasó a vivir dentro de una pequeña zona de estudios en `/estudiar`. Por ahora solo hay un juego, el mapa de España, pero la estructura ya permite crecer.

La navegación también se ajustó: en vez de un botón flotante que podía pisar la interfaz, el mapa incluye un botón integrado arriba para volver a la zona de estudios. El personaje deja de ser solo decoración y pasa a funcionar como ayudante Héctor, una figura reconocible dentro del entorno.

No es un LMS, ni pretende serlo. Es algo más pequeño y más doméstico: una herramienta hecha alrededor de una necesidad real, probada por su usuario real y mejorada con IA como copiloto.

La primera lección es que la IA trabaja mucho mejor cuando alguien observa de verdad. Sin Héctor diciendo que era injusto, confuso o inútil, la app podría haberse quedado en una demo visualmente bonita pero pedagógicamente floja.

La segunda es que los niños son testers implacables porque no respetan las excusas técnicas. Si algo tapa Galicia, tapa Galicia. Si Ceuta no se puede pulsar, no se puede pulsar. Si el reto da la respuesta al pasar el ratón, el reto está roto.

La tercera es que programar con IA no elimina el oficio de producto. Lo cambia de sitio. Hay que saber describir estados, detectar trampas, convertir quejas en requisitos y pedir verificaciones. En este caso, el código lo escribió Codex, pero el criterio salió de una conversación familiar muy concreta.