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. Veo este tipo de proyectos continuamente, y mi camino con ellos es siempre el mismo: no me hago cargo del código roto de Lovable o Bolt ni lo parcheo, sino que uso el prototipo como especificación y construyo el producto desde cero, para que funcione en producción, con usuarios y dinero reales. Quiero que lo sepas desde el principio, 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 el backend hay que revisarlo

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. Puede generar también base de datos, registro de usuarios y lógica de servidor, pero su punto fuerte es la interfaz. La gente se atasca porque tiene una pantalla preciosa y cree que solo falta conectarla, cuando en realidad la parte más difícil (seguridad, lógica de datos, gestión de errores) sigue sin revisar.

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 que el código existente lo arregle una persona —quien lo creó u otro programador—, 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, un programador te dirá bastante rápido si bastan arreglos puntuales o sale más barato rehacer, y cuál es el precio real. Sin ellas, solo frases genéricas que no le sirven a nadie. Si eliges el rehecho limpio conmigo, de esta lista solo necesito el tercer punto y un enlace al prototipo: no retomo código ajeno, así que no hace falta acceso al repositorio.

¿Rescatar o rehacer?

Es la decisión más importante, y puedes tomarla tú. Al contrario de lo que se suele pensar, la respuesta correcta no siempre es «tíralo todo y escríbelo desde cero». La lógica es más o menos esta.

Situación	Qué elegir
La interfaz está ordenada y los problemas son locales (no conectan los pagos, falla el deploy, una integración)	Rescatar. Arreglos puntuales, tú mismo o con quien lo creó. A menudo, el camino más barato.
El frontend es bueno, pero no hay backend real ni modelo de datos	Mixto. Conservar el frontend y construir debajo un backend limpio es trabajo para quien lo creó o para otro programador.
La lógica está dispersa, cada arreglo rompe otra cosa y nadie entiende la estructura	Rehacer. Lo visual se convierte en la especificación y el código se escribe limpio desde cero: este es mi trabajo.
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. Con la misma franqueza te digo lo que hago yo: solo el rehecho limpio desde cero; el rescate y los parches te los dejo a ti o a quien lo creó.

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	Backend, BD y registro se generan, pero requieren una revisión cuidadosa
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 construyo 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. No ofrezco arreglos ni finalización sobre el código existente, así que aquí van mis precios para rehacerlo limpio desde cero, con tu prototipo como especificación (precio cerrado de proyecto, sin IVA; empresas UE: inversión del sujeto pasivo):

• MVP / PWA con registro, datos y deploy (iOS y Android con una sola base de código): desde 2.900 €
• App de negocio con pagos e integraciones, conservando el buen diseño como especificación: desde 6.900 €
• Plataforma compleja con varios tipos de usuario y muchas integraciones: desde 14.900 €

El precio depende de lo que tiene que hacer el producto, no del estado de tu código, así que para el presupuesto ni siquiera necesito verlo. Las integraciones locales (Bizum, Redsys, Verifactu, certificado FNMT) se incluyen en el alcance, normalmente en el nivel de app de negocio desde 6.900 €. Estas cifras te ayudan a hacerte una idea del tamaño para que no te lleves un susto en ninguna dirección.

Preguntas frecuentes

¿Puedes hacerte cargo de mi proyecto de Lovable?

No. No me hago cargo de código ajeno ni generado por IA, ni lo arreglo ni lo continúo, aunque esté sincronizado con GitHub. En su lugar, rehago el producto limpio desde cero y uso tu prototipo de Lovable como especificación y referencia visual: las pantallas, los flujos y la lógica que has definido no se pierden. Para ti es mejor así: no pagas por desenredar código ajeno, no heredas el lío de reglas de Supabase ni fallos ocultos, y obtienes una base ordenada que cualquier desarrollador puede mantener. Si quieres seguir sobre el código existente, puedes hacerlo tú mismo o con la persona que lo creó.

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

El frontend suele verse bastante bien, 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 no me hago cargo del código de Bolt: uso lo visual y los flujos del proyecto como especificación y construyo el producto desde cero, con 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?

Depende del camino que elijas. Si el código existente lo va a arreglar quien lo creó u otro programador, necesitará tres cosas: acceso al código (el repositorio de GitHub o el proyecto exportado, no capturas de pantalla), acceso a los servicios que usas (Supabase, Vercel, la pasarela de pago, la cuenta de correo) y de cinco a diez frases explicando qué debe hacer la app y qué falla exactamente. Si eliges el rehecho limpio conmigo, no hace falta el código: basta con un enlace al prototipo o capturas, esas mismas cinco a diez frases sobre lo que tiene que hacer el producto y la información de las cuentas que ya tengas.

¿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. Esos arreglos los puedes hacer tú mismo o con quien lo creó. 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. Yo solo trabajo por este segundo camino: no me hago cargo de código ajeno y construyo el producto desde cero, con tu prototipo como especificación.

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

No ofrezco arreglos ni finalización sobre código generado por IA: eso lo puedes hacer tú mismo o con quien lo creó. Mis precios son para rehacer el producto limpio desde cero a partir de tu prototipo: MVP / PWA (iOS y Android con una sola base de código) desde 2.900 €, app de negocio con pagos e integraciones desde 6.900 €, plataforma compleja desde 14.900 €. Todo sin IVA (empresas UE: inversión del sujeto pasivo). El precio depende de lo que tiene que hacer el producto, no del estado de tu código, así que para el presupuesto ni siquiera necesito verlo. 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. Decide qué camino es el tuyo: arreglar el código existente (tú mismo o con quien lo creó) o rehacerlo limpio. Si eliges el segundo, describe lo que querías y tu prototipo se convertirá en la especificación: conservo tu buen trabajo y debajo construyo desde cero lo que evitará que se vuelva a caer, para que funcione y genere ingresos, no solo para que se vea bonito.