Lovable en bucle y no corrige el error: qué hacer
Cuando Lovable o Bolt corrige una cosa y rompe otra, deje de pedir la misma corrección. Vuelva a la última versión que funcionaba, aísle el error, lea el log e investigue en un modo que no toca el código. Si el error vuelve igual, lleve el código a GitHub y pida a alguien que lo lea.
Recomendación de Heartscale: después de dos intentos sin resultado, vuelva a la última versión buena, márquela en el historial y conecte GitHub antes de pedir otra corrección. Si el error toca login, pagos o datos de la base, pida a alguien que lea el código antes del próximo cambio.
Cada intento cuesta créditos, y repetir el mismo pedido rara vez cambia el resultado. Los pasos de abajo usan recursos que las propias plataformas documentan.
Por qué la IA entra en bucle
Cuatro causas suelen aparecer juntas.
La memoria de la IA tiene límite. La documentación de Bolt lo llama ventana de contexto: la memoria de trabajo que reúne los archivos del proyecto y todo lo que usted envió en el chat (Managing project context). Cuando se llena, Bolt conserva solo los mensajes recientes y puede olvidar los antiguos. La documentación advierte que un contexto demasiado grande puede generar errores, respuestas más lentas y resultados peores.
Código repetido. En lugar de corregir una función, la IA a veces escribe una segunda versión en otro archivo. La corrección entra en una copia y el error sigue en la otra. Bolt recomienda borrar archivos sin uso y dividir archivos de más de unas 700 líneas, probando después de cada cambio.
Falta de pruebas. Sin pruebas automatizadas, nada avisa que la corrección de hoy rompió la pantalla de ayer. Usted lo descubre haciendo clic, y la IA también.
La causa está fuera del código que la IA modifica. Un secreto que falta, una política de la base que bloquea la escritura o un servicio externo caído se ven como un error en pantalla. La IA reescribe la pantalla y el error sigue. El error “new row violates row-level security policy” es un ejemplo común. La guía Configurar RLS en Supabase explica cómo resolverlo.
Paso 1: deténgase en el segundo intento
Si la misma corrección falló dos veces, el tercer intento tiende a repetir el camino. Calcule el costo antes de insistir:
- Lovable: el botón Try to fix aparece en la tarjeta de actividad cuando hay un error de build. La cuenta tiene 10 correcciones gratis, compartidas con las del área de seguridad, y cada una vuelve 24 horas después de usarla. Después, Try to fix consume créditos (Troubleshooting).
- Bolt: cada intento automático gasta tokens. Bolt aconseja no hacer clic en Attempt fix una y otra vez, e investigar el error cuando las correcciones automáticas no funcionan (Maximizing token efficiency).
Paso 2: vuelva a la última versión que funcionaba
Bolt recomienda usar el historial en lugar de pedir a la IA que deshaga un cambio. En Lovable, el camino es el mismo.
En Lovable (Version history):
- Haga clic en History en la barra superior, o en el menú junto al cuadro de mensaje, en Project → History.
- Haga clic en una versión para ver cómo estaba, sin modificar el proyecto. Back to latest vuelve a la actual.
- Busque la última que funcionaba y haga clic en Revert. Confirme.
El chat tiene atajos (Chat). Undo latest edit, debajo de la última respuesta, deshace el cambio más reciente. Edit message, en un mensaje suyo, abre Revert and resend: el proyecto vuelve al estado anterior a ese mensaje y ejecuta el pedido reescrito.
Tres advertencias de la documentación:
- revertir restaura el código y vuelve a publicar las Edge Functions, pero no deshace los datos de la base. Los registros creados y las migraciones ejecutadas después de esa versión siguen ahí;
- revertir no devuelve créditos;
- las versiones muy antiguas muestran “Cannot revert this far back in history”.
Cuando llegue a una versión buena, márquela con Bookmark in history. Pasa a ser su punto seguro.
En Bolt (Rollback and backup): abra Version history (ícono de reloj), haga clic en la versión, luego en Restore this version y confirme con Restore version. La documentación indica que restaurar no cambia las bases de Bolt ni de Supabase, y que el historial restaura sin gastar tokens.
Paso 3: investigue sin dejar que la IA toque el código
Los dos constructores tienen modos que conversan sin modificar archivos.
Lovable: en el selector junto al cuadro de mensaje (o con Alt+P), elija:
- Chat, para hablar de la app. Cada mensaje cuesta en general una fracción de crédito y usa primero la cuota diaria de chat;
- Plan, para investigar y escribir un plan que usted aprueba antes de cualquier código. Cada mensaje cuesta un crédito, más la investigación que haga, y la documentación indica que Plan nunca modifica el código (Plan mode).
Bolt: haga clic en Plan, en la esquina inferior derecha del cuadro de mensaje. Cuando el plan esté bien, Implement this plan pasa al modo de construcción (Plan Mode). Si Bolt se traba o deja de responder, escriba /clear y haga clic en Clear context. Eso limpia la memoria de la conversación y conserva los archivos.
Una pregunta útil en estos modos: “Liste los archivos que tratan esto y diga si hay código duplicado”. Muestra la causa del bucle antes de cualquier cambio.
Paso 4: aísle el error y lea el log
La IA corrige mejor cuando recibe el error exacto. Antes del próximo pedido, reúna:
- El texto del error, copiado, sin resumir.
- Los pasos para que aparezca: qué pantalla, qué botón, qué usuario.
- Lo esperado y lo que pasó.
- Desde cuándo: la primera versión del historial en la que aparece el error.
Dónde encontrar el log:
- Consola del navegador: CTRL+SHIFT+I en Windows o CMD+OPTION+J en macOS, pestaña Console. Bolt sugiere pedir a la IA que agregue logs de depuración, reproducir el error en otra pestaña y pegar el resultado en el chat (Troubleshooting).
- Lovable Cloud: en el menú More de la barra del proyecto, abra Logs (Lovable Cloud).
- Imagen: en Lovable, Take a screenshot y Draw marcan el punto exacto en la pantalla.
Trate un problema a la vez, descrito en un mensaje completo. Lovable recomienda juntar en un solo pedido lo que serían varios mensajes rápidos seguidos.
Paso 5: lleve el código a GitHub
Con el código en GitHub, cada cambio de la IA se vuelve un commit con lo que cambió, línea por línea. Usted ve qué cambió entre la versión buena y la rota, y otra persona puede leer y correr el proyecto fuera de la plataforma.
- Lovable: Project settings → Git → GitHub, luego Connect. Lovable crea un repositorio nuevo, privado por defecto, y sincroniza en los dos sentidos, una rama a la vez (GitHub).
- Bolt: haga clic en el ícono de GitHub en la esquina superior derecha, en Log in to GitHub y en Install & Authorize. Bolt hace commit de los cambios y trae las actualizaciones de GitHub cada 30 segundos (GitHub).
Conecte GitHub antes del próximo error. Guarda la historia que el chat no muestra.
En nuestras revisiones, abrimos en GitHub la diferencia entre la última versión buena y la primera con el error. En ese tramo buscamos funciones duplicadas, secretos que faltan y políticas de la base que bloquean la escritura.
Cuándo llamar a quien revisa código
Si los pasos de arriba no lo resuelven, pida a alguien que lea el código. Las señales:
- el error vuelve después de revertir y pedir de nuevo, con el error exacto;
- la falla involucra login, pagos o datos personales;
- la corrección exige cambiar la base, y revertir no deshace datos;
- nadie sabe ya qué hace cada parte del código.
Si el problema parece estar en la propia plataforma, Lovable indica el soporte en lovable.dev/support para los planes pagos. Para el código de su app, el camino es una revisión. Vea también ¿Es seguro Lovable? para los riesgos que suelen aparecer junto.
¿Hacerlo usted mismo o contratar?
Usted puede seguir los pasos 1 a 5 sin ayuda técnica. La tabla resume cuándo conviene llamar a un equipo.
| Situación | Camino |
|---|---|
| Un error nuevo en una pantalla, y volver a la versión buena lo resuelve | Siga los pasos 1 a 5 y marque esa versión en el historial |
| El mismo error vuelve después de revertir y pedir de nuevo con el texto exacto | Pida a alguien que revise el código en GitHub |
| La falla involucra login, pagos o datos personales | Deje de insistir en el chat y pida una revisión antes de la próxima publicación |
| La app tiene usuarios reales, la corrección toca la base y nadie del equipo lee código | Solicite el diagnóstico de Heartscale |
Solicite un diagnóstico de Heartscale
La IA llevó su app hasta donde pudo. Nuestro equipo lee el código en GitHub, encuentra la causa del bucle y lista lo que hay que cambiar, por gravedad y con el precio de cada corrección. Vea el servicio de revisión de código generado por IA. No prometemos plazos antes de leer el código.
El diagnóstico, a precio de lanzamiento, cuesta US$ 19 (antes US$ 79) y se descuenta si contrata la corrección. Solo trabajamos en apps de quien demuestra ser su dueño.