112/365 · Vibe coding: cómo evitar que te 'fría' la cabeza

Ayer hablábamos de los seis pasos para pasar de una idea nebulosa a un prototipo funcional usando vibe coding. Y todo suena muy bien en teoría: dialogas con la IA, iteras progresivamente, pruebas, ajustas, y voilà — tienes tu herramienta educativa. Pero la realidad es más complicada, y si has intentado crear algo mínimamente complejo con IA, lo sabes perfectamente. A veces te pasas tres horas dándole vueltas a un problema que la IA no termina de resolver correctamente. O peor: te metes en un bucle infinito de «prueba esto», «ahora esto otro», «vuelve atrás», hasta que ya ni recuerdas qué estabas intentando hacer originalmente. Y terminas con la cabeza frita, frustrado, pensando que esto del vibe coding es bonito pero impracticable.

Personalmente he estado ahí decenas de veces. Diálogos interminables con ChatGPT o Claude donde cada solución genera dos problemas nuevos, donde la IA me propone código que funciona a medias, donde pierdo el hilo de lo que estaba haciendo porque me he metido en tangentes técnicas que ni entiendo del todo. Y he entendido, después de mucho tiempo y muchos proyectos, que el problema no es la IA — el problema es cómo estructuras el trabajo con ella. Si no tienes claridad absoluta sobre qué quieres y qué modelo usar para cada tarea, te vas a freír. Garantizado.

Y esto conecta directamente con algo que llevamos viendo en otros posts: la importancia del diseño previo, de la planificación, de no lanzarte a hacer sin pensar antes. Porque cuando trabajas con IA, la tentación es empezar a dialogar inmediatamente — «hazme esto» — sin haber definido exactamente qué es «esto». Y ahí es donde se tuerce todo.

El problema de los diálogos infinitos: cuando la IA no sabe qué quieres

Empecemos por diagnosticar el problema principal. La mayoría de diálogos improductivos con IA tienen el mismo origen: instrucciones vagas. Le dices «crea una actividad educativa», y la IA genera algo genérico que no se ajusta a lo que necesitas. Entonces le dices «no, cámbialo así», y ajusta una cosa pero estropea otra. Después le dices «ahora añade esto», y genera código que entra en conflicto con lo anterior. Y así sucesivamente, en un bucle que puede durar horas sin llegar a ningún resultado satisfactorio.

El problema fundamental es que la IA no sabe lo que tú tienes en la cabeza. No puede adivinar el contexto completo, las restricciones específicas, el resultado exacto que esperas. Y cada vez que le das una instrucción parcial, toma decisiones basándose en lo que le has dicho hasta ese momento — pero esas decisiones pueden ser incompatibles con lo que querías pero no especificaste. Resultado: código que funciona parcialmente, soluciones que resuelven un problema pero crean otros, frustración creciente.

Juan José de Haro, que lleva meses trabajando intensivamente con vibe coding para crear recursos educativos, insiste en esto: la claridad inicial es crítica. No empieces a dialogar con la IA hasta que tengas absolutamente claro qué quieres crear, qué funcionalidades necesitas, qué restricciones técnicas tienes, qué resultado final esperas. Y eso requiere trabajo previo — pensar, planificar, estructurar — antes de abrir el chat con la IA. Parece obvio, pero es el error más común: saltar directamente a dialogar sin haber hecho ese trabajo previo de conceptualización.

Estructurar antes de dialogar: el trabajo invisible que evita el caos

Entonces, ¿cómo estructuras el trabajo para no freírte? Primera clave: documenta tu idea antes de pedirle nada a la IA. Y no mentalmente — por escrito. Abre un documento y escribe con detalle qué quieres crear: tipo de herramienta, objetivo pedagógico, funcionalidades específicas, restricciones técnicas (¿debe funcionar offline? ¿en qué dispositivos? ¿con qué navegadores?), público objetivo (edad, competencias digitales), aspecto visual (minimalista, rico en elementos, colores específicos). Cuanto más detallado sea este documento, mejores serán las respuestas de la IA.

Personalmente uso un template que relleno antes de empezar cualquier proyecto de vibe coding. Incluye secciones como: nombre provisional de la herramienta, objetivo pedagógico (qué aprenderán), competencias que desarrolla, contexto de uso (dónde, cuándo, cómo), funcionalidades principales (listadas una a una con detalle), tecnologías preferidas (sí, tengo preferencias), restricciones técnicas, referentes (otras herramientas similares que me gustan), boceto visual (aunque sea un esquema hecho a mano). Rellenar ese template me lleva entre 20 y 40 minutos. Pero esos minutos ahorran horas de diálogos improductivos con la IA.

Y aquí conecta algo que hemos visto en posts sobre diseño educativo: el concepto de MVP (Producto Mínimo Viable). En tu documento de planificación, diferencia claramente entre funcionalidades imprescindibles para la primera versión y funcionalidades deseables que añadirás después. Si intentas que la IA te cree todo de golpe — versión completa, con todas las campanas y silbatos — te vas a perder en la complejidad. Mejor crear primero la versión más simple que funcione, probarla, y después iterar añadiendo funcionalidades progresivamente.

Elegir el modelo adecuado para cada tarea: no todos sirven para todo

Segunda clave fundamental que he aprendido con el tiempo: no todos los modelos de IA son iguales para todas las tareas. Y usar el modelo inadecuado para una tarea específica puede multiplicar el tiempo de trabajo y la frustración. Personalmente uso diferentes modelos según qué necesito en cada momento del proyecto, y esto ha cambiado radicalmente mi eficiencia.

Para diseño conceptual y planificación inicial, modelos como Claude (especialmente Claude Sonnet) funcionan muy bien — son buenos entendiendo contexto complejo, haciendo preguntas aclaratorias, ayudándote a estructurar ideas nebulosas. Para generación de código, especialmente cuando necesitas crear desde cero, GPT-4 o Claude siguen siendo sólidos. Pero para debugging — encontrar errores en código existente — a veces modelos más especializados funcionan mejor. Y para tareas específicas como generar documentación o explicar código de forma pedagógica, de nuevo Claude destaca por su capacidad de claridad y detalle.

Meng Li, ingeniero de IA con una década de experiencia que publica en su Substack «AI Disruption», comparte constantemente análisis sobre qué modelos funcionan mejor para qué tareas. Y una de sus lecciones clave es esta: no te cases con un solo modelo. Prueba, compara, identifica cuál te funciona mejor para cada tipo de tarea. Y cuando encuentres esa combinación que te funciona, documéntala — anota qué modelo usas para qué, porque tu memoria no es fiable y dentro de dos meses habrás olvidado qué te funcionaba bien.

También están surgiendo espacios como «IA para Todos» en Substack, newsletters que ayudan a profesionales no técnicos a sacar partido profesional a la IA de forma sencilla. Y uno de los consejos recurrentes es justo este: aprende a elegir la herramienta adecuada para cada tarea. No uses siempre ChatGPT por inercia — a veces Claude es mejor para tu caso específico, o Gemini, o incluso herramientas más especializadas. La herramienta correcta puede reducir tu tiempo de trabajo a la mitad.

Dividir el proyecto en módulos independientes

Tercera estrategia para no freírte: divide el proyecto en módulos o componentes independientes. En lugar de pedirle a la IA que te cree toda la aplicación de golpe, pídele que cree primero la estructura HTML básica. Prueba que funciona. Después pídele que añada los estilos CSS. Prueba. Después pídele que añada JavaScript para una funcionalidad específica. Prueba. Y así sucesivamente. Este enfoque modular tiene dos ventajas enormes.

Primera: cada paso es más simple y manejable. La IA puede concentrarse en una tarea concreta sin tener que gestionar la complejidad de todo el proyecto simultáneamente. Y tú puedes verificar que cada módulo funciona correctamente antes de añadir el siguiente, lo que facilita enormemente detectar dónde están los problemas cuando algo falla.

Segunda ventaja: si un módulo no funciona como esperabas, solo tienes que rehacer ese módulo, no todo el proyecto. Imagina que has generado una aplicación completa de golpe y descubres que una funcionalidad no hace lo que querías. ¿Cómo la cambias sin romper todo lo demás? Es complicado. Pero si trabajaste modularmente, solo revisas ese módulo específico, lo ajustas, y lo integras de nuevo. Mucho más manejable.

Cuando creé herramientas como EDUmind Quiz o EDUmind Motor, trabajé exactamente así. Primero estructura básica. Después sistema de preguntas. Después lógica de corrección. Después feedback visual. Después registro de progreso. Cada módulo lo probé independientemente antes de integrarlo con los demás. Y cuando algo fallaba, sabía exactamente dónde buscar porque había aislado las funcionalidades.

Usar proyectos y memoria contextual de la IA

Cuarta estrategia, y esta es más reciente pero tremendamente útil: aprovecha las funcionalidades de proyectos y memoria contextual que ofrecen algunas herramientas de IA. Claude, por ejemplo, permite crear proyectos donde puedes cargar documentos de contexto — tu documento de planificación, ejemplos de código que te gustan, restricciones técnicas, estilo de interfaz que prefieres. Toda esa información queda disponible para la IA en todas las conversaciones de ese proyecto, sin que tengas que repetirla constantemente.

Esto reduce drásticamente la carga cognitiva de cada diálogo. No tienes que recordar qué le dijiste tres conversaciones atrás, ni repetir constantemente «recuerda que esto debe funcionar en tablets», ni volver a explicar el contexto cada vez. La IA tiene acceso a toda esa información de forma persistente. Y eso hace que las respuestas sean más consistentes y ajustadas a lo que realmente necesitas.

También conecta con algo que vimos en el post sobre Vibe Coding: primeros pasos — la importancia de la documentación. Si documentas bien tu proyecto desde el principio y cargas esa documentación en el proyecto de IA, estás creando un espacio de trabajo compartido donde tanto tú como la IA tenéis acceso a la misma información. Eso elimina malentendidos y acelera el proceso enormemente.

Saber cuándo parar y cambiar de enfoque

Quinta estrategia, y esta es crítica para tu salud mental: aprende a detectar cuándo estás en un bucle improductivo y cambia de enfoque. Si llevas más de 30 minutos intentando que la IA resuelva un problema específico y no avanza, para. No sigas insistiendo con la misma aproximación esperando resultados diferentes. Eso es freírte la cabeza garantizado.

¿Qué hacer en esos momentos? Opciones: primera, reformula completamente el problema. A veces la forma en que estás planteando la pregunta es el problema. Explícaselo a la IA de otra manera, con otros términos, desde otro ángulo. Segunda opción: divide el problema en partes más pequeñas. Si no consigues que funcione X completo, intenta primero hacer funcionar una parte mínima de X y después amplía. Tercera opción: cambia de modelo de IA. A veces lo que Claude no resuelve bien, GPT-4 sí, o viceversa. Cuarta opción: busca información externa — documentación oficial, Stack Overflow, tutoriales — y después vuelve a la IA con más contexto.

Y quinta opción, la más infrautilizada: descansa. Deja el problema, vete a hacer otra cosa, y vuelve más tarde con la mente fresca. Muchas veces, después de un descanso, ves el problema de otra forma y la solución emerge con facilidad. El cansancio cognitivo nubla el juicio y te hace insistir en aproximaciones que no funcionan. Reconocerlo y parar a tiempo es una competencia profesional importante.

Iterar sin perder el rumbo: el arte de no desviarte del objetivo

Sexta estrategia: recuerda constantemente cuál es tu objetivo pedagógico y no te desvíes por tangentes técnicas fascinantes pero irrelevantes. Esto me pasa todo el tiempo: estoy creando una herramienta para practicar sumas, y de repente la IA me sugiere añadir un sistema de logros gamificados con ranking y avatares personalizables. Y claro, suena genial, me meto en eso, y dos horas después he perdido el foco completamente.

El vibe coding tiene ese riesgo: la facilidad para añadir funcionalidades te tienta constantemente a ir más allá de lo necesario. Y no digo que no debas experimentar — a veces esas tangentes generan ideas valiosas. Pero necesitas disciplina para preguntarte constantemente: ¿esto sirve al objetivo pedagógico original? ¿Mi alumnado realmente necesita esta funcionalidad? ¿O me estoy complicando la vida porque me parece técnicamente interesante?

Cuando trabajas en herramientas como EDUmind MiApp o EDUmind Motion, es fácil caer en la trampa de la sobreingeniería. Añadir capas y capas de funcionalidades hasta que la herramienta se vuelve demasiado compleja para el alumnado objetivo, o hasta que el tiempo de desarrollo se multiplica innecesariamente.

Nos vemos mañana,

Luis V.