El día uno de una aplicación de vibe-coding es la mejor demo que jamás hayas dado. El prompt funcionó, las pantallas están limpias, la base de datos tiene registros y has publicado un tuit con una grabación de pantalla. Hemos pasado por ese día muchas veces. No queremos quitártelo.
Estamos aquí para hablar del día dos, porque nadie lo menciona en sus hilos de lanzamiento. El día dos es cuando un usuario real inicia sesión, hace algo que no pensaste probar y tu aplicación choca con la brecha entre lo “generado” y lo “ingenierizado”.
Cómo es realmente el día dos
Rara vez empieza con un colapso total. Empieza con algo extraño: un formulario que acepta datos basura, una página que falla para un usuario específico, un número que es incorrecto de una forma que nadie puede reproducir. Pegas el error en el chat. La IA lo corrige con confianza. La corrección rompe otra cosa.
Bienvenido al juego del topo de los prompts. Como la IA corrige los síntomas en lugar de las causas raíz, cada parche se coloca sobre el anterior y el código se convierte silenciosamente en lo que los desarrolladores llaman “código Frankenstein”: un mosaico de estilos conflictivos, funciones duplicadas y lógica enredada donde las consultas de la base de datos viven dentro del código de la interfaz. A medida que el proyecto crece más allá de la ventana de contexto de la IA, el modelo empieza a olvidar sus propias decisiones anteriores y propone código que las contradice. Ya no estás manteniendo una aplicación. Estás negociando con ella.
Hay una variante aún más cruel: el fallo de despliegue silencioso. Tu build de hosting falla por un error menor, la URL en vivo sigue mostrando la versión antigua y tú, al no ver cambios, le dices a la IA que su corrección “no funcionó”. Entonces, genera una solución completamente diferente y más compleja para un problema que ya estaba resuelto. Varias rondas después, tienes una versión 5 inflada de un código cuya versión 1 estaba bien.
La parte que no puedes ver
La cinta de correr de la depuración es, al menos, visible. Los problemas de seguridad no lo son, y esa es la razón por la que somos tan estrictos con esto en los desarrollos empresariales.
Las investigaciones al respecto son realmente inquietantes. El código generado por LLM compila correctamente alrededor del 90% de las veces, pero aproximadamente el 45% contiene vulnerabilidades del Top 10 de OWASP: comprobaciones de inicio de sesión eludibles, fallos de inyección, etc. Las herramientas de IA optimizan el resultado para que la demo funcione, lo que genera atajos predecibles: controles de acceso implementados en el navegador que cualquier usuario puede saltarse editando la página, permisos de base de datos totalmente abiertos para evitar errores durante la compilación y claves de API escritas directamente en los archivos porque el generador no sabe qué es una variable de entorno. Luego, esos archivos se suben a repositorios públicos de GitHub, donde los rastreadores de credenciales los encuentran sistemáticamente.
Esto es precisamente lo que lo convierte en un problema de “día dos”: una aplicación vulnerable funciona a la perfección. No hay ningún mensaje de error que diga “el cliente A puede técnicamente leer los registros del cliente B”. Te enteras a través de un usuario, si tienes suerte, o de formas mucho peores si no la tienes. Y el consejo estándar (“¡simplemente pruébalo!”) choca con la realidad: los creadores no técnicos prueban el camino feliz (happy path), mientras que el fallo reside en los casos límite: el error de concurrencia o el flujo de restablecimiento de contraseña olvidado que la IA nunca generó porque la demo no lo necesitaba.
La deuda de mantenimiento que nadie contabiliza
Si acumulas estas dinámicas durante meses, obtienes lo que podríamos llamar el “préstamo rápido” de la deuda técnica: software instantáneo ahora, intereses compuestos después. Cada atajo que tomó la IA es un arreglo futuro. Cada arreglo implica unos cuantos créditos más y un poco más de código redundante. Las actualizaciones de la plataforma se lanzan y rompen cosas que no tocaste; los creadores a largo plazo en plataformas de prompt-to-app informan que cobran a sus clientes cuotas mensuales de mantenimiento solo para gestionar las regresiones de la propia plataforma.
Aquí reside la ironía amarga: el vibe coding prometió democratizar el software y, para las aplicaciones en producción, lo que ha democratizado principalmente es la deuda técnica. El creador no técnico termina cargando precisamente aquello que utilizó la IA para evitar: una base de código que requiere el criterio de un desarrollador, con la diferencia de que ahora es el pilar de su negocio y no sabe leerla.
La bifurcación honesta
¿Qué se puede hacer entonces? Después de muchos despliegues y algunas cicatrices, creemos que todo se reduce a una bifurcación con dos caminos honestos; el camino intermedio, el deshonesto, es la única respuesta incorrecta.
Camino uno: aprender a mantener el código. Si te apasiona lo suficiente como para profundizar, el vibe coding se convierte en un acelerador legítimo en lugar de una trampa. Lee lo que escribe el agente. Aprende qué significa RLS antes de lanzar una aplicación que dependa de ello. Pasa de las herramientas basadas solo en prompts a Cursor o Replit, donde el código es la interfaz y puedes desarrollar un criterio real. Este camino es genuinamente fantástico; es simplemente un camino que requiere meses de recorrido. Fingir que estás en él mientras entregas código no leído a los clientes es la verdadera trampa.
Camino dos: basar las partes peligrosas en una infraestructura no generada. Sé honesto y reconoce que tu aplicación es una herramienta de negocio —un portal de clientes, un rastreador, un CRM interno— y date cuenta de que el 80% de ella consiste precisamente en la fontanería que la IA genera peor: autenticación, permisos, restablecimiento de contraseñas y acceso a datos. Construye esa categoría en una plataforma no-code como Softr, donde la fontanería es una infraestructura probada que configuras visualmente y el AI Co-Builder te sigue dando la velocidad del primer día. Cuando quieras un toque personalizado, su bloque de vibe-coding limita el código generado a un solo componente, permitiendo que la IA decore la casa sin comprometer la estructura del tejado. El “día dos” en este camino es una edición, no una excavación arqueológica; es por eso que lidera nuestro ranking de portales de clientes.
Sigue usando el vibe coding para las cosas divertidas sin miedo: los prototipos, los juguetes y los experimentos de fin de semana son precisamente aquello en lo que estas herramientas son brillantes. Solo decide, antes de que lleguen los usuarios reales, en qué lado de la bifurcación te encuentras. El “día dos” no pide permiso.