Hace unos meses me escribió un autónomo de Valencia con una frase que oigo cada vez más a menudo: «La aplicación ya la tengo, funciona, solo falta el último toque». Abrí su pantalla y, en efecto, funcionaba. Interfaz cuidada, los botones respondían, los datos aparecían. Todo montado en unos días con Lovable, casi sin escribir una sola línea de código. El problema es que ese «último toque» era, en realidad, todo lo que separa una demo de un producto. Y ese «todo» pesaba más que el trabajo anterior junto.
Este fenómeno ya tiene nombre: «vibe coding». En este artículo te explico qué es, por qué es genial para un prototipo y peligroso para un producto, qué le falta exactamente a una app hecha con vibe coding, cuándo basta de sobra (sí, a veces basta) y cómo convertir ese prototipo en un producto real que aguante en producción, con clientes españoles, pagos y la normativa que aquí es obligatoria.
Qué es el vibe coding
El «vibe coding» es una forma de programar en la que creas la aplicación no escribiendo código, sino describiéndole en lenguaje natural a una IA lo que quieres. «Hazme una app de lista de tareas con inicio de sesión y modo oscuro»: y a los pocos segundos tienes una pantalla funcionando. No te gusta el color, pides cambiarlo. Falta un botón, pides añadirlo. No escribes línea a línea: vas guiando por sensación, pides, miras el resultado y pides corregir. De ahí lo del «vibe».
Las herramientas que hacen esto ya son conocidas: Lovable y Bolt generan la aplicación entera, v0 genera la interfaz, y Cursor y ChatGPT escriben código a partir de la conversación. Es una tecnología realmente impresionante y no la menosprecio: yo mismo uso IA a diario en mi trabajo. La pregunta nunca fue «si la IA puede escribir código». La pregunta es «si lo que ha escrito aguanta el mundo real».
Porque el vibe coding tiene una propiedad invisible: está optimizado para que parezca que funciona. La IA genera código que pasa la prueba evidente: pulsas un botón y pasa algo. Pero «funciona en mi pantalla» y «funciona en producción con clientes reales» son dos cosas completamente distintas, y entre ambas está justo el trabajo que la IA no hace por sí sola.
Por qué es genial para un prototipo y peligroso para un producto
La tarea de un prototipo es una sola: demostrar la idea. Le basta con funcionar para ti, una vez, por el camino feliz (así llamo al escenario en el que el usuario lo hace todo bien y nada se rompe). Si quieres enseñarle a un inversor cómo se verá tu servicio, o comprobar tú mismo si la idea tiene sentido, el vibe coding aquí no tiene rival. Lo que antes requería una semana y varios miles de euros ahora se hace en una tarde. Eso es una ventaja real y enorme.
La tarea de un producto es otra. Un producto tiene que funcionar no para ti, sino para desconocidos. Con mala conexión. Con datos mal introducidos. Con alguien que intenta colarte un dato falso. De madrugada, mientras tú duermes. Seis meses después, cuando una librería ha cambiado. Con mil usuarios a la vez, no con uno. Ahí es donde un prototipo de vibe coding empieza a desmoronarse, y no se rompe por donde se ve, sino por donde no se ve hasta que ya es tarde.
La ilusión más peligrosa del vibe coding
Cuando la aplicación parece terminada al 90 %, la intuición te dice que queda un 10 % de trabajo. La realidad es justo la contraria: la parte visible (interfaz, botones, pantallas) es la fácil, la que la IA hace bien. La parte invisible (seguridad, datos, casos límite, despliegue, cumplimiento legal) es a la vez la más difícil y la más cara. Sobre ese 30 % difícil escribí aparte en «Empezaste tu app con IA y te has atascado: qué hacer ahora».
7 cosas que le faltan a una app hecha con vibe coding
Cuando me llega a las manos un proyecto hecho con vibe coding, casi siempre faltan las mismas siete cosas. No porque la IA sea «mala»: simplemente genera lo que le pides, y nadie pide estas cosas porque ni siquiera sabes que existen hasta que se convierten en un problema.
| Qué falta | Por qué importa en producción |
|---|---|
| 1. Tests automáticos | Sin tests, cada cambio es una apuesta. Arreglas una cosa y, sin verlo, se rompe otra. En el código de vibe coding casi nunca hay tests, así que el proyecto se vuelve más frágil cuanto más se toca. |
| 2. Gestión de errores | Qué pasa cuando se cae la conexión, el servidor no responde o el usuario mete basura? En un prototipo, pantalla en blanco o caída. En un producto debe haber un mensaje claro, un camino alternativo y el registro silencioso del error. |
| 3. Seguridad | Claves de API expuestas en el propio código, una base de datos sin proteger donde cualquiera saca datos ajenos, cero validación de entradas. Es el fallo más frecuente y más peligroso del vibe coding (el clásico «Lovable + Supabase mal configurado»), y se explota en minutos. |
| 4. Migraciones de datos | Cuando añades un campo o cambias la estructura, los datos que ya tienen tus usuarios deben «mudarse» sin pérdidas. En un prototipo el esquema se cambia borrando y recreando; en producción eso significaría clientes borrados. |
| 5. Monitorización | En producción tienes que enterarte del problema antes que el usuario. Sin seguimiento de errores ni logs, no ves que la mitad de la gente no puede entrar: te enteras solo cuando dejan de volver. |
| 6. Escala | El código que va bien con un usuario puede desmoronarse con cien. Consultas sin optimizar, sin caché, todo en un solo hilo: al prototipo le da igual, al producto le resulta letal el primer día que tenga éxito. |
| 7. Mantenimiento | Las librerías envejecen, aparecen agujeros de seguridad, cambian las reglas de pagos e identidad. Un producto exige cuidado continuo. Un código de vibe coding que nadie entiende se vuelve irreparable tras la primera avería seria. |
Fíjate: ninguna de estas siete cosas la ve el usuario mientras todo va bien. Todas se manifiestan ese día malo, y precisamente por ellas construir un producto es más caro y más lento que un prototipo. No es el «barniz» del final, es el cimiento.
Cuándo basta de verdad con el vibe coding
Ahora, la parte más importante y más honesta de este artículo. El vibe coding no es «malo». Hay muchos casos en los que no solo basta, sino que es la opción más inteligente. Si caes en uno de ellos, no me contrates: ahorra el dinero y constrúyelo tú.
Aquí el vibe coding es más que suficiente
- Una herramienta interna para unas pocas personas. Una calculadora, una tabla, un sistemilla que usa tu equipo. Si no guarda datos ajenos ni cobra dinero, móntalo con IA y no le des más vueltas.
- Una demo para un inversor o un cliente. Necesitas enseñar cómo se verá la idea. A nadie le importa qué hay debajo del capó si el objetivo es convencer, no dar servicio.
- Visualizar una idea para ti. Quieres ver si tu planteamiento tiene sentido antes de invertir dinero en serio. Un prototipo de vibe coding responde a esa pregunta por el precio más barato posible.
- Un proyecto personal. Un hobby, un diario personal, una herramienta para ti. Si se rompe, se rompe solo para ti, y lo aguantas.
La regla general es sencilla: si la aplicación no guarda datos ajenos ni mueve dinero, el vibe coding seguramente te basta.
Cuándo el vibe coding ya no basta
Y ahora la otra cara. Hay una línea más allá de la cual «parece que funciona» se convierte en un riesgo que cuesta mucho más de lo que ahorraste construyéndolo. La cruzas en el momento en que tu aplicación empieza a usarla gente a la que no conoces, o cuando por ella circula dinero.
| El vibe coding basta | Hace falta una reconstrucción profesional |
|---|---|
| Lo usas solo tú o un círculo reducido de confianza | Lo usan desconocidos, clientes reales |
| Cero dinero en el sistema | Pagos con Bizum, tarjeta o Redsys, suscripciones, cobros |
| Los datos son irrelevantes o públicos | Datos personales, RGPD y LOPDGDD, privacidad del cliente |
| Que se rompa no cuesta nada | Una caída significa clientes o reputación perdidos |
| Vive unas pocas semanas | Tiene que funcionar y mantenerse durante años |
En cuanto aparecen clientes reales o pagos, cada una de esas siete cosas que faltan se convierte en una responsabilidad. Una base de datos sin proteger con tus clientes dentro ya no es un detalle técnico: es una infracción del RGPD y la LOPDGDD, con sanciones de la AEPD que en España llegan hasta los 20 millones de euros o el 4 % de la facturación. Cobros sin gestión de errores son dinero que se pierde entre tú y el banco. Y si vendes, en 2026 tu facturación tiene que ser conforme a Verifactu de la AEAT. Por eso aquí ya no es una cuestión de vibe coding, sino de producto.
Cómo convertir un prototipo de vibe coding en un producto
La buena noticia: un prototipo de vibe coding pocas veces es trabajo tirado, suele ser un punto de partida excelente. Ya has decidido qué hace la aplicación, qué aspecto tiene y qué lógica sigue. Esa es la parte más valiosa y más difícil de poner por escrito de una especificación, y ya está hecha. Solo queda cerrar ese 30 % difícil por el cual un prototipo no es un producto.
Cuando alguien me escribe con un proyecto hecho con vibe coding, lo primero que hago es revisar el repositorio y decidir una cosa: continuar sobre el código existente o reconstruir de forma limpia. Lo decide la estructura del código, no su cantidad. Si la lógica y el modelo de datos están sanos, continúo sobre ellos y añado la capa que falta. Si el código es caótico, con claves expuestas y un estado descontrolado, una reconstrucción limpia sale más rápida y más barata que ir parcheando. Profundizo en lo que pasa cuando el código de IA empieza a romperse (y al «arreglarlo» se rompe aún más) en «Lovable, Bolt, v0, Cursor: qué hacer cuando el código de IA se rompe».
El camino del prototipo a producción
- Auditoría. Reviso qué funciona de verdad y qué solo lo parece. Localizo los agujeros de seguridad y los puntos críticos.
- Una base sólida. Base de datos segura, inicio de sesión normal, claves ocultas y validación de entradas: lo que permite construir encima.
- El 30 % difícil. Pagos, integraciones, gestión de errores y casos límite. En España aquí suelen entrar las integraciones locales que la IA no conecta sola: Bizum y Redsys, pasarelas como Stripe, Mollie o MONEI con 3D Secure por PSD2, SEPA, identidad con Cl@ve o certificado de la FNMT, y facturación conforme a Verifactu.
- La red de seguridad. Tests, monitorización y logs para que del problema te enteres tú, no tu cliente.
- Despliegue y mantenimiento. Dominio real, hosting real, copias de seguridad y un acuerdo claro de quién lo mantiene a partir de ahí. Y, antes de salir, dejarlo legal: política de privacidad, aviso legal, condiciones de uso y un banner de cookies conforme a la guía de la AEPD (aceptar y rechazar al mismo nivel).
Mi propuesta nunca es «te arreglo el código». Es «te lo dejo funcionando, legal y vendiendo». La diferencia es esencial: arreglar código es cosmética, mientras que construir un producto significa que tus clientes pueden usarlo tranquilos, pagar con Bizum o tarjeta y volver, y que tú puedes dormir tranquilo.
Números reales
Vamos al precio en concreto, porque me lo vas a preguntar igual. Si el prototipo de vibe coding ya tiene lógica y pantallas, una reconstrucción limpia hasta producción (con autenticación, seguridad, despliegue e integraciones básicas) suele costar entre 1.500 y 6.000 € más IVA. Productos más complejos, con pagos (Bizum, Redsys, Stripe), integraciones locales y panel de administración, van desde 6.000 € en adelante. Los plazos suelen ser de 2 a 6 semanas, según hasta dónde llegó de verdad el prototipo. A eso hay que sumar los costes recurrentes que un prototipo nunca contempla: dominio 12–40 €/año, hosting 100–300 €/año y mantenimiento desde 100–300 €/año.
Puede sonar a bastante para un proyecto «casi terminado». Pero acuérdate de la tabla de las siete cosas que faltan: no pagas por el barniz, pagas por ese cimiento sin el cual la aplicación no es un producto, sino solo una foto de un producto.
El Kit Digital puede pagar buena parte
Si eres autónomo o PYME, no asumas que tienes que pagarlo todo de tu bolsillo. El Kit Digital (Red.es / NextGenerationEU) ofrece bonos de entre 3.000 y 12.000 € (hasta 29.000 € para medianas empresas), y desde 2026 incluye categorías de IA y automatización. Trabajo como agente digitalizador, así que parte de la reconstrucción de tu prototipo puede financiarse con esa ayuda y reducir mucho lo que sale de tu cuenta.
Tienes un prototipo de vibe coding que quieres convertir en un producto real?
Reviso tu proyecto de Lovable, Bolt, v0 o Cursor y te digo claro si conviene continuar sobre el código existente o sale más barato reconstruirlo limpio, con un precio y un plazo concretos. Te lo dejo legal y funcionando: RGPD, pagos con Bizum o tarjeta y facturación Verifactu. La primera llamada es sin compromiso.
Hablar de mi proyecto