Del prompt al sistema: cómo crear aplicaciones
Pedirle a un chatbot que diseñe una actividad gamificada funciona una vez. A la segunda vez, con la misma fuente y el mismo prompt, el resultado cambia: otra cantidad de conceptos, otro formato, otro nivel de dificultad.
Nada de esto está mal en sentido estricto, es que simplemente no hay un proceso fijo detrás de la interacción, y por lo tanto no hay garantía de reproducibilidad. Cada intento es una improvisación nueva, dependiente del estado conversacional del momento.
Ese diagnóstico fue el punto de partida para construir ConectaBloques SCORM: una web app que genera actividades de "unir bloques" a partir de cualquier apunte, empaquetadas en formato SCORM 1.2 para su integración directa en Moodle. Lo relevante del caso no es únicamente la herramienta resultante, sino el método empleado para construirla: vibecoding, mediante Google AI Studio, sin escribir código de forma manual.
El vibecoding como método
El término vibecoding describe un modo de producción de software en el que quien conduce el proceso no escribe el código, sino que lo especifica con el nivel de detalle suficiente para que un modelo de lenguaje lo genere y lo ejecute. Esto no equivale a no requerir competencia técnica: equivale a desplazar esa competencia desde la sintaxis hacia la definición del problema.
Quien construye una aplicación mediante este método necesita anticipar, antes de escribir el primer prompt, qué información necesita el usuario final, qué debe ocurrir cuando algo falla, cómo se valida el resultado antes de su publicación, y qué condiciones de acceso o seguridad corresponden. Esta secuencia —definición, iteración, verificación— constituye una competencia digital de orden superior, distinta de la alfabetización instrumental en herramientas específicas. Desde ya queda claro que no se trata de apps que puedan competir con las comerciales sino que están creadas para ese propósito único y específico.
Necesidad de sistematizar antes que automatizar
Promptear un chatbot de manera fragmentada e iterativa —solicitar una trivia, luego pedir que se incremente su dificultad, luego solicitar un cambio de temática visual— produce resultados puntuales y aislados entre sí.
Este modo de trabajo es adecuado para una necesidad puntual, pero resulta insuficiente para sostener una práctica docente regular, en la que se requiere un nivel de calidad constante tanto en la primera ejecución como en la quincuagésima.
Sistematizar un proceso de este tipo requiere definir, con anterioridad a cualquier automatización, tres dimensiones: qué conceptos deben extraerse del material fuente, qué estructura organiza la actividad resultante, y bajo qué criterios se evalúa el desempeño del usuario.
Una vez tomadas estas decisiones de diseño, es posible automatizarlas, y quien las opera deja de negociar en lenguaje natural con un chatbot generalista para pasar a operar una herramienta propia, con una interfaz que no requiere formulación lingüística en cada uso.
La distinción entre usar IA frente a diseñar con IA no es meramente terminológica. Diseñar con IA implica que el proceso resultante no se reinventa en cada intento, mientras que usarla de forma no sistemática implica una dependencia permanente de la instancia conversacional.
Alcance y límites de la herramienta
Resulta necesario precisar qué es ConectaBloques SCORM y, con igual importancia, qué no pretende ser. No se trata de una plataforma que compita con Moodle ni con ningún sistema de autoría de contenidos educativos de uso general. No es una herramienta multipropósito, ni fue diseñada con esa ambición.
Su función es acotada y deliberadamente específica: convertir material de apunte en actividades gamificadas de forma consistente, reduciendo la variabilidad que introduce la interacción conversacional no estructurada. En este sentido, se trata de una solución de nicho, construida para resolver un problema puntual del propio proceso de trabajo, y no necesariamente transferible sin modificaciones a otros contextos de uso.
Valor sin mediación de mercado
El mercado laboral todavía no reconoce de manera directa la competencia de diseñar procesos mediante inteligencia artificial, salvo en un número reducido de roles técnicos especializados.
Sin embargo, el valor generado por esta competencia existe con independencia de su reconocimiento salarial: quien sistematiza una tarea repetitiva obtiene tiempo, consistencia, y la posibilidad de escalar un proceso que antes debía ejecutarse de forma manual, instancia por instancia.
Implicancias para la práctica docente
Lo señalado hasta aquí permite formular una hipótesis de trabajo: el vibecoding no habilita, en primer término, la construcción de aplicaciones comerciales complejas por parte de usuarios sin formación técnica. Habilita, en cambio, que cualquier persona con un problema bien definido, recurrente y de alcance acotado pueda construir una solución propia para ese problema específico, sin depender de un desarrollador externo ni de la disponibilidad de una aplicación comercial que atienda un nicho demasiado específico para justificar su desarrollo bajo una lógica de mercado.
Esta hipótesis tiene consecuencias directas para el ámbito educativo, donde abundan procesos repetitivos, de bajo volumen y alta especificidad institucional, que rara vez resultan atractivos para el desarrollo de software comercial, pero que consumen tiempo docente de manera sostenida.
Entonces:
¿Cuántos de los procesos que hoy se resuelven de forma manual, semana tras semana, en instituciones educativas, podrían sistematizarse con el mismo criterio metodológico que se aplicó en este caso?