¿Lovable gasta créditos en un bucle de arreglos? Córtalo así
Por qué Lovable 'arregla' una y otra vez el mismo error, cuánto cuesta cada intento y cómo salir del bucle con Plan mode y volviendo a una versión sana.
Read in English →
Si Lovable arregla un error, el error vuelve, y lo arregla otra vez, deja de reintentar después del segundo intento. Un bucle significa que nadie encontró la causa, y cada parche nuevo agrega código que la esconde todavía más. Pasa a Plan mode para investigar sin tocar el código, dale a Lovable el error exacto en lugar de una descripción, y vuelve a la última versión que funcionaba si los arreglos ya enredaron todo. Casi siempre sale más barato que tres intentos más a ciegas.
En esta guía verás por qué se forman los bucles, cuánto cuesta hoy cada reintento en Lovable, seis pasos para salir y cómo ponerle techo al gasto para que una mala tarde no te vacíe el saldo.
¿Por qué Lovable se queda arreglando lo mismo?
Casi todos los bucles siguen uno de estos patrones:
- El error no está en el código. Un secreto que falta, una política de la base de datos que bloquea una lectura, un webhook que apunta a la dirección equivocada o una clave vencida de otro servicio producen errores en tu app, pero se arreglan con un ajuste. La IA sigue reescribiendo código porque es lo único que puede cambiar.
- El arreglo ataca el síntoma. Un "Cannot read properties of undefined" recibe una validación, la pantalla deja de romperse y los datos siguen sin cargar. En el siguiente prompt aparece otro error en otro lado.
- Cada intento cambia más de la cuenta. Para el quinto intento, el componente tiene tres versiones de la misma lógica y ya nadie, ni persona ni IA, sabe cuál se ejecuta.
- El pedido era demasiado grande. "Agrega equipos, invitaciones y cobros" en un solo prompt toca tantos archivos que es difícil aislar qué falló.
La propia guía de depuración de Lovable lo dice sin rodeos: los arreglos a ciegas acumulan código que esconde el problema real, y pasar a Plan mode después de uno o dos intentos fallidos suele ser más rápido.
¿Cuánto cuesta cada reintento?
Los precios cambiaron varias veces, así que esto es lo que dice hoy la documentación de Lovable:
| Acción | Costo |
|---|---|
| Try to fix sobre un error de build | Gratis las primeras 10 veces en tu cuenta (compartidas con los arreglos de la vista Security, en todos tus workspaces). Cada arreglo gratis vuelve a estar disponible 24 horas después de usarlo. Luego cuenta como uso normal. |
| Mensaje en Build mode | Según el trabajo que haga |
| Mensaje en Plan mode | 1 crédito, más la investigación que haga mientras planifica |
| Mensaje en Chat mode | Según el trabajo, normalmente una fracción de crédito, cubierto primero por una asignación diaria de chat |
| Volver a una versión anterior | Los créditos de los mensajes revertidos no se devuelven |
Para ver cuánto costó un mensaje, abre el menú More options debajo de la respuesta y mira Credits used. Las tareas largas en Build mode se pausan con un "credit check-in" cuando un solo mensaje pasa cierto umbral (20 créditos por defecto), que puedes subir o desactivar en tus preferencias.
La trampa: cuando se acaban los arreglos gratis, un bucle de reintentos en Build mode es la forma más cara de depurar.
¿Cómo salgo del bucle?
1. Para y ubica dónde empezó
Sube por el chat hasta la última respuesta en la que la app funcionaba. Abre Show history arriba del editor y previsualiza esa versión para confirmarlo. Anota qué pediste justo después.
2. Consigue el error real
Una captura de pantalla de la página rota no alcanza. Junta al menos una de estas cosas:
- La primera línea roja de la consola del navegador (clic derecho, Inspeccionar, Console).
- La petición que falla en la pestaña Network: su dirección y su código (401, 403, 404, 500).
- La entrada del registro del backend en More → Cloud → Logs, filtrada por errores.
3. Investiga en Plan mode
Cambia el chat a Plan mode para que nada se modifique mientras Lovable investiga. Estos prompts funcionan bien:
¿Cuál es la causa de fondo de este error? Muéstrame el código relacionado y explícalo antes de proponer un arreglo.
¿Qué soluciones ya probamos para este error? Haz una lista para no repetirlas.
¿Esto lo causa el código, o un ajuste, un secreto o una política de la base de datos?
La tercera pregunta es la más importante. Si la respuesta es un ajuste, cámbialo tú y sáltate el cambio de código.
4. Decide: volver atrás o seguir
Si los últimos arreglos agregaron código que sobra, vuelve atrás. Pasa el cursor sobre tu mensaje de antes del bucle, haz clic en Edit message, escríbelo con más precisión y confirma con Revert and resend. También puedes revertir desde el historial.
Dos cosas antes de revertir: solo se restaura el código, no los datos de la base, y las edge functions se vuelven a desplegar para coincidir. Si algún prompt del bucle creó tablas o cambió registros, eso se queda.
5. Reconstruye en pasos chicos
Cuéntale a Lovable lo que hiciste ("Volví a antes de la función de invitaciones. Hagámosla de nuevo, en pasos más chicos.") y pide una pieza a la vez: la tabla, luego el formulario, luego el correo. Prueba cada una en la vista previa antes de seguir.
6. Deja la lección por escrito
Cuando lo resuelvas, pídele a Lovable un resumen de la causa y el arreglo y agrégalo al conocimiento del proyecto, para que la próxima sesión no repita el error.
¿Cómo sé si el problema es un ajuste y no código?
Estos errores casi siempre apuntan fuera del código:
permission denied for tableo una lista vacía donde esperas datos: una política de row level security. Lo explicamos en la guía de Row Level Security de Supabase en Lovable y Bolt.- Un 401 o 403 de una edge function, o "missing API key": un secreto sin configurar. Lo cubre la guía de errores de edge functions en Lovable.
- Un login que funciona en la vista previa pero no en tu dominio: las URL de redirección.
- Pagos que entran pero no desbloquean nada: el webhook. Mira pagos con Stripe en una app hecha con IA.
¿Cómo le pongo techo al gasto?
- Configura límites de uso. Los administradores pueden fijar límites de créditos y alertas de saldo bajo para el workspace, para cada proyecto y para cada miembro. Un límite por proyecto es una red de seguridad barata.
- Deja activo el check-in en un nivel en el que quieras que te pregunten.
- Marca versiones estables en el historial cada vez que algo funcione, para tener siempre un punto seguro al cual volver.
- Usa Chat o Plan mode para preguntas. "¿Por qué esto va lento?" no necesita Build mode.
Respuestas rápidas
¿Revertir me devuelve los créditos? No. Los créditos pagan el trabajo ya hecho, así que los mensajes revertidos cuentan igual.
¿Try to fix siempre es gratis? Solo los primeros 10 de tu cuenta, y cada uno vuelve a estar disponible 24 horas después de usarlo. Luego cuenta como uso normal.
¿Conviene empezar un proyecto nuevo? Casi nunca. Volver a la última versión que funcionaba conserva todo lo que estaba bien hasta ese punto.
¿Cuántos reintentos antes de parar? Dos. Después, investiga en Plan mode o pide que alguien más lo mire.
Cuando ya toca una persona
Si ya volviste atrás, planificaste y reconstruiste y lo mismo se sigue rompiendo, la causa probablemente es de estructura, y una revisión humana sale más barata que seguir gastando créditos. Haz el chequeo gratuito de tu app, mira cómo arreglamos apps de Lovable o cuéntanos dónde te trabaste.


