Lovable, Bolt, v0, Cursor: qué hacer cuando el código de IA se rompe

La escena la veo casi cada semana. Alguien monta en un fin de semana una demo que funciona con Lovable, Bolt o v0, se ilusiona y se la enseña a medio mundo. Luego quiere añadir una cosa más —los pagos, el registro de usuarios, otra pantalla— y todo empieza a desmoronarse. Le pide a la IA que lo arregle. Lo arregla. Una hora después se rompe algo que sí funcionaba. Vuelve a pedir un arreglo. Tras la décima vuelta, el código está en un punto en que ni él ni la IA entienden ya qué pasa.

Si te has reconocido aquí, no es culpa tuya ni señal de que no sepas. Estas herramientas están hechas precisamente para eso: enseñar una idea rápido. El problema empieza cuando intentas convertir esa demo en un producto real, listo para entregárselo a usuarios de verdad. En este artículo te cuento sin rodeos dónde llega su límite cada herramienta, por qué la IA arregla y vuelve a romper, qué preparar antes de pedir ayuda y cuándo merece la pena rescatar el código existente y cuándo sale más barato rehacerlo en limpio.

No hablo de teoría. Recojo este tipo de proyectos de forma habitual: cojo un código roto de Lovable o Bolt y lo convierto en algo que funciona en producción, con usuarios y dinero reales. Quiero que lo sepas, porque cambia lo que tiene sentido pedir.

Por qué la IA te lleva al 80 % y se queda ahí

Lovable, Bolt y v0 hacen a una velocidad asombrosa la parte que se ve: botones, formularios, pantallas, una maquetación bonita. Eso es más o menos el 80 % de lo que parece una app. Pero el 20 % que queda —pagos, autenticación, base de datos, deploy, seguridad, RGPD, casos límite— es lo más difícil, lo más caro y justo la parte que hace que la app funcione de verdad con personas reales. Ahí la IA no pule: ahí choca contra el muro.

El motivo es sencillo. Esa capa visible es repetitiva: en internet hay millones de formularios y pantallas parecidos, la IA los ha visto y los reproduce al instante. Pero ese 20 % es único de tu proyecto y exige decisiones que solo se toman entendiendo el conjunto: cómo fluyen los datos, dónde se guardan, quién puede ver qué, qué pasa cuando un pago falla. Eso no es copiar, es ingeniería. Y ahí es donde todo empieza a romperse.

Dónde se rompe según la herramienta

Cada herramienta tiene su carácter y su punto típico de fallo. Conocerlo ayuda mucho a entender qué tienes de verdad entre manos.

Lovable: el deploy y la base de datos

Lovable crea una aplicación completa (React + Supabase) y gestiona bastante por su cuenta, así que al principio parece magia. Pero se rompe en dos sitios. El primero, la base de datos de Supabase: cuando el modelo de datos se complica, empieza el lío con las reglas RLS (seguridad a nivel de fila), las relaciones entre tablas se enredan y las consultas devuelven o de más o nada. El segundo, el deploy y los entornos: en local o en la vista previa de Lovable funciona, pero en tu dominio real con las variables de verdad deja de funcionar, porque las claves, las URLs o el CORS estaban configurados solo para modo demo.

Bolt: el estado y las integraciones

Bolt genera un frontend interactivo a una velocidad estupenda. El muro llega cuando la app acumula mucho estado: el carrito, el usuario conectado, los filtros, formularios que dependen unos de otros. Ese estado empieza a escaparse: pulsas en un sitio y se actualiza algo que no tiene nada que ver en otro. El segundo punto de dolor de Bolt son las integraciones con sistemas reales: pagos, correo, una API externa. A nivel demo, Bolt enseña cómo quedaría, pero para conectarlo de verdad hace falta una parte de servidor, gestión de secretos y control de errores que la generación rápida no resuelve.

v0: interfaz preciosa, pero sin backend

v0 (de Vercel) es el mejor de este grupo para una cosa concreta: crear un componente o una vista de React/Next.js realmente bonita. Pero hay que entender qué hace: hace la fachada. No hay base de datos, no hay registro de usuarios, no hay lógica de servidor, no hay nada donde se guarden datos reales. La gente se atasca porque tiene una pantalla preciosa y cree que solo falta conectarla, cuando en realidad falta toda la parte pesada que v0 ni siquiera tenía que hacer. No es un defecto de v0, es un malentendido sobre para qué sirve.

Cursor: genera, pero tú tienes que entender

Cursor es distinto de los tres de arriba: es un editor con una IA potente, pensado para alguien que ya sabe leer código. Puede escribir mucho y rápido. Pero si no sabes valorar lo que ha escrito, simplemente te deja generar más deprisa algo que no entiendes. El escenario típico: Cursor genera una lógica compleja, casi funciona, le pides arreglar un detalle, reescribe más de lo necesario y de repente tienes 2.000 líneas que ni puedes leer ni tocar con seguridad. Cursor es magnífico para un desarrollador profesional y peligroso para quien espera que lo solucione todo solo.

Por qué la IA arregla y vuelve a romper

Es una de las preguntas que más me hacen: «¿por qué arregla una cosa y rompe otra?». La respuesta es la pérdida de contexto. La IA no ve todo tu proyecto a la vez como un sistema entero. En cada arreglo trabaja con una parte limitada y visible, «recuerda» solo lo que cabe y adivina el resto. Al arreglar el sitio A, cambia sin querer algo de lo que depende el sitio B, que en ese momento no estaba mirando.

Cuanto más grande es el proyecto, antes arranca esta rueda. Al principio, con pocos archivos, la IA aún lo mantiene todo «en la cabeza» y parece increíble. Al pasar cierto tamaño, cada arreglo nuevo tiene más probabilidad de romper algo. Pides arreglos más a menudo, ella reescribe cada vez más, el código se dispersa, y de pronto estás en una rueda de la que la IA no te va a sacar, porque ella misma es la causa de esa rueda.

Una persona rompe la rueda de forma sencilla: mantiene toda la arquitectura en la cabeza, entiende la causa y no solo el síntoma, y arregla una vez de manera que quede arreglado. Donde la IA pone diez parches, una persona que entiende lo que hace arregla una sola vez.

Qué hacer ANTES de pedir ayuda

Si has decidido buscar ayuda —conmigo o con quien sea—, hay tres cosas que, si las preparas, hacen que la evaluación sea rápida y precisa en lugar de una conjetura cara. Puedes prepararlas tú mismo en media hora.

Con estas tres cosas puedo decirte en bastante poco tiempo si bastan arreglos puntuales o sale más barato rehacer una parte, y cuál es el precio real. Sin ellas, solo frases genéricas que no le sirven a nadie.

¿Rescatar o rehacer?

Es la decisión más importante. Y, al contrario de lo que se suele pensar, la respuesta correcta no siempre es «tíralo todo y escríbelo desde cero». Lo decido mirando el código, pero la lógica es más o menos esta.

Situación	Qué hago
La interfaz está ordenada y los problemas son locales (no conectan los pagos, falla el deploy, una integración)	Rescato. Arreglos puntuales, a menudo el camino más barato.
El frontend es bueno, pero no hay backend real ni modelo de datos	Mixto. Conservo el frontend y construyo debajo un backend limpio.
La lógica está dispersa, cada arreglo rompe otra cosa y nadie entiende la estructura	Rehago. Uso lo visual como especificación y escribo el código en limpio.
Es una herramienta interna o una demo, no para clientes reales ni dinero	Quizá te basta la IA. Te lo digo claro si no me necesitas.

Quiero subrayar la última fila. Si tu proyecto es un hobby, una herramienta interna para un equipo de pocas personas o la visualización de una idea, la IA te va a bastar de sobra, y te lo voy a decir. No intento vender trabajo donde no hace falta. Esto, por cierto, es la garantía de que cuando digo «aquí hay que rehacer», no lo digo por la factura.

Qué herramienta sirve para qué, y dónde está su límite

Una tabla breve para que no te líes al elegir. No es un ranking de «mejor a peor», sino un mapa de para qué trabajo está pensada cada una y dónde se acaban sus posibilidades.

Herramienta	Para qué sirve	Dónde está el límite
Lovable	Demo completa con BD y registro, MVP rápido para validar una idea	Reglas de Supabase, deploy a un dominio real, modelo de datos que crece
Bolt	Prototipo de frontend interactivo, vista rápida de cómo funcionaría	Estado complejo, integraciones reales, pagos, parte de servidor
v0	Componentes y páginas React/Next.js bonitas, base de interfaz	No hay backend, BD ni registro: solo la fachada
Cursor	Desarrollo más rápido para quien sabe leer y valorar código	Sin ese criterio, generas deprisa algo que ya no controlas

Si quieres profundizar en por qué un prototipo de IA todavía no es un producto y qué separa el «funciona en mi pantalla» del «funciona para usuarios reales», lo trato aparte en el artículo sobre vibe coding: el prototipo de IA frente al producto real. Y si lo que te interesa es el desarrollo a medida que viene después, lo cuento en mi página de desarrollo de aplicaciones.

Lo que un proyecto a medio hacer suele incumplir (y un gancho de valor)

Hay una parte que casi ningún proyecto montado con IA contempla y que en España no es opcional: el marco legal. Toda web que recoja datos necesita política de privacidad, aviso legal, política de cookies y condiciones de uso, además de un banner de cookies conforme a la guía de la AEPD, con aceptar y rechazar al mismo nivel y con solo las cookies técnicas exentas. El RGPD y la LOPDGDD se incumplen casi siempre en estos prototipos, y las sanciones de la AEPD son reales y crecientes. Cuando recojo un proyecto, lo dejo cumpliendo: privacidad, cookies, pagos con SCA por PSD2 y, si hay facturación, alineado con Verifactu y la factura electrónica B2B que llega por la Ley Crea y Crece. No es relleno; es lo que separa una demo de algo que puedes publicar sin riesgo.

Rangos de precio reales en España

Con franqueza, porque nadie lo dice claro. Los precios dependen de cuánto se conserve, pero los rangos son estos (precio cerrado de proyecto, más IVA del 21 %):

• Arreglos locales sobre un proyecto ordenado (deploy, una integración, un fallo de estado): desde 600–1.500 €
• Terminar un MVP de IA hasta el lanzamiento real con registro, pagos, datos y deploy: 2.500–6.000 €
• Reconstrucción limpia hasta producción, conservando el buen diseño: desde 4.000–8.000 € en adelante según las integraciones

El número exacto lo doy solo después de ver el código; sin eso, cualquier cifra sería una conjetura. Pero estos rangos ayudan a hacerte una idea del tamaño para que no te lleves un susto en ninguna dirección. Y a menudo empezamos por un paso pequeño: evalúo, te enseño qué está roto de verdad y entonces decides con el panorama completo.

Preguntas frecuentes

¿Puedes hacerte cargo de mi proyecto de Lovable?

Sí. Lovable permite sincronizar el código con GitHub: cuando tengo acceso al repositorio, recojo el proyecto como una aplicación React/Vite + Supabase normal. Primero lo descargo en local, lo ejecuto, veo qué se rompe de verdad y solo entonces decido si bastan arreglos puntuales o sale más barato rehacer una parte en limpio. No necesitas desmontar nada de antemano: dame acceso y una descripción breve de lo que querías conseguir.

¿El código de Bolt sirve para producción?

El frontend suele ser bastante bueno y merece la pena conservarlo. Pero «apto para producción» no es solo una interfaz bonita: hace falta una gestión de estado ordenada, un backend seguro, una base de datos real, autenticación, pagos con Bizum y SCA, y control de errores. Bolt genera una demo rápida, no esa capa pesada. Por eso, un proyecto de Bolt real lo dejo normalmente como base de interfaz y debajo construyo un backend fiable y las integraciones para que funcione con usuarios y dinero reales.

¿Por qué la IA arregla y vuelve a romper el mismo código?

Porque la IA no ve todo el proyecto a la vez ni mantiene un contexto estable. En cada arreglo trabaja con una parte limitada del código, así que al tocar un sitio rompe sin querer otro que había «olvidado». Cuanto más grande es el proyecto, antes empieza esta rueda. Una persona mantiene toda la arquitectura en la cabeza y arregla la causa, no el síntoma, así que el arreglo se queda arreglado.

¿Qué debo preparar antes de pedir ayuda con un proyecto de IA roto?

Tres cosas. Primera, acceso al código: el repositorio de GitHub o el proyecto exportado, no capturas de pantalla. Segunda, acceso a los servicios que usas (Supabase, Vercel, la pasarela de pago, la cuenta de correo). Tercera, de cinco a diez frases explicando qué debe hacer la app y qué falla exactamente. Con eso puedo evaluar el estado rápido y decirte si bastan arreglos o conviene rehacer, además del precio real.

¿Cuándo conviene rescatar el código de IA existente y cuándo sale más barato rehacerlo?

Rescatar merece la pena cuando la interfaz y la estructura están ordenadas y los problemas son locales: no conectan los pagos, falla el deploy, no funciona una integración. Rehacer sale más barato cuando la lógica está dispersa, no hay un backend real ni un modelo de datos, y cada arreglo rompe otra cosa. A menudo lo mejor es mixto: conservo el frontend bueno y construyo debajo un backend limpio. Lo decido después de mirar el código, no de antemano.

¿Cuánto cuesta arreglar o terminar un proyecto generado con IA en España?

Depende de cuánto se conserve. Arreglos locales sobre un proyecto ordenado, desde 600–1.500 €. Terminar un MVP de IA hasta el lanzamiento real con autenticación, pagos, datos y deploy, normalmente entre 2.500 y 6.000 €. Una reconstrucción limpia hasta producción, desde 4.000–8.000 € en adelante según las integraciones. Todo más IVA. El precio exacto lo doy solo después de ver el código, y parte puede financiarse con el Kit Digital. Sobre el coste oculto de las soluciones de IA «gratis» escribo en detalle en el artículo sobre el coste real de una web de IA gratis.

En resumen

Lovable, Bolt, v0 y Cursor son herramientas excelentes para lo que están pensadas: enseñar una idea rápido. No se rompen porque sean malas, sino porque intentas convertir una demo en algo que requiere ingeniería: un backend seguro, integraciones reales (Bizum, Redsys, Stripe), datos ordenados y cumplimiento legal. La IA parchea síntomas y pierde el contexto; una persona arregla la causa. Si tu proyecto se ha atascado, no des la vuelta número veinte. Exporta el código, reúne los accesos, describe lo que querías y deja que lo mire. A menudo conservo tu buen trabajo y debajo construyo lo que evitará que se vuelva a caer, para que funcione y genere ingresos, no solo para que se vea bonito.