El primer día de una app creada con vibe-coding es la mejor demo que jamás hayas hecho. El prompt funcionó, las pantallas están limpias, la base de datos tiene filas y publicaste un tweet con una grabación de pantalla. Hemos pasado por ese día muchas veces. No estamos aquí para quitártelo.
Estamos aquí para hablar del día dos, porque ningún hilo de lanzamiento lo menciona. El día dos es cuando un usuario real inicia sesión, hace algo que no pensaste probar y tu app choca con la brecha entre lo “generado” y lo “diseñado”.
Cómo es realmente el día dos
Rara vez empieza con un fallo crítico. Empieza con algo extraño: un formulario que acepta basura, una página que se rompe para un usuario específico, un número que está mal de una forma que nadie puede reproducir. Pegas el error en el chat. La AI lo soluciona con confianza. La solución rompe otra cosa.
Bienvenido al juego del whack-a-mole de prompts. Como la AI soluciona síntomas en lugar de causas raíz, cada parche se asienta 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 supera la ventana de contexto de la AI, el modelo empieza a olvidar sus propias decisiones anteriores y propone código que las contradice. Ya no estás manteniendo una app. Estás negociando con ella.
Hay una variante aún más cruel: el fallo de despliegue silencioso. La compilación de tu 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 AI que su solució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 v5 inflada de un código cuya v1 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 estrictos con esto en las versiones para empresas.
La investigación al respecto es genuinamente incómoda. El código generado por LLM compila con éxito 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. Las herramientas de AI optimizan para que la demo funcione, lo que produce atajos predecibles: control de acceso implementado en el navegador donde cualquier usuario puede saltárselo editando la página, permisos de base de datos totalmente abiertos para que nada dé error durante la compilación y claves API escritas directamente en los archivos porque el creador no sabe qué es una variable de entorno. Esos archivos luego se suben a repositorios públicos de GitHub, donde los rastreadores de credenciales los encuentran puntualmente.
Esto es lo que convierte esto específicamente en un problema del día dos: una app vulnerable funciona perfectamente. No hay un mensaje de error que diga “el cliente A puede técnicamente leer los registros del cliente B”. Te enteras por un usuario, si tienes suerte, o mucho peor 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, mientras que el fallo vive en los casos límite: el bug de concurrencia, el flujo de restablecimiento de contraseña olvidado que la AI nunca generó porque la demo no lo necesitaba.
La deuda de mantenimiento que nadie detalla
Suma esas mecánicas durante meses y obtendrás lo que consideramos el préstamo rápido de la deuda técnica: software instantáneo ahora, intereses compuestos después. Cada atajo que tomó la AI es una futura corrección. Cada corrección son unos cuantos créditos más y un poco más de código inflado. Salen actualizaciones de la plataforma y rompen cosas que no tocaste; los creadores a largo plazo en plataformas de prompt-to-app informan que cobran a sus clientes tarifas de mantenimiento mensuales solo para gestionar regresiones de la propia plataforma.
Esta es la broma amarga en el centro de todo: el vibe coding prometió democratizar el software y, para las apps de producción, mayormente ha democratizado la deuda técnica. El creador no técnico termina cargando exactamente aquello que usó la AI para evitar, una base de código que requiere el juicio de un desarrollador, excepto que ahora es el soporte de su negocio y no puede leerla.
La bifurcación honesta
Entonces, ¿qué haces realmente? Después de muchas compilaciones y algunas cicatrices, creemos que todo se reduce a una bifurcación con dos caminos honestos, y el medio deshonesto es la única respuesta incorrecta.
Camino uno: aprende a mantener el código. Si te apasiona esto 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 app que dependa de ello. Pasa de las herramientas solo de prompt a Cursor o Replit, donde el código es la interfaz y puedes desarrollar un juicio real. Este camino es genuinamente genial, es simplemente un camino que requiere meses de caminata, y fingir que estás en él mientras envías código no leído a los clientes es la trampa.
Camino dos: pon las partes peligrosas sobre una base que no sea generada. Sé honesto y reconoce que tu app es una herramienta de negocio, un portal de clientes, un rastreador, un CRM interno, y date cuenta de que el 80% de ella es precisamente la fontanería que la AI genera peor: auth, permisos, restablecimientos de contraseña, acceso a datos. Construye esa categoría en una plataforma no-code como Softr, donde la fontanería es infraestructura probada que configuras visualmente, y el AI Co-Builder todavía te da 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, para que la AI pueda decorar la casa sin derribar el techo. El día dos en este camino es una edición, no una excavación arqueológica, es por eso que encabeza nuestro ranking de portales de clientes.
Sigue haciendo vibe coding de las cosas divertidas sin miedo: los prototipos, los juguetes y los experimentos de fin de semana son exactamente aquello en lo que estas herramientas son brillantes. Solo decide, antes de que lleguen los usuarios reales, en qué lado de la bifurcación estás. El día dos no pregunta educadamente.