Mi app de Lovable o Bolt dejó de funcionar: cómo saber qué se rompió

Ayer tu app funcionaba. Hoy el botón de guardar no hace nada, la lista sale vacía o la pantalla se queda en blanco. Si la construiste con Lovable, Bolt, v0, Replit o Cursor, es muy probable que tu primer impulso sea escribirle a la IA "arréglalo". A veces funciona. Otras veces entras en un círculo donde cada intento cambia algo más y el problema sigue ahí.

Esta guía es para salir de ese círculo. No necesitas ser programador: necesitas un método para mirar lo que tu app ya te está diciendo.

1. Reproduce el error antes de tocar nada

Antes de pedir cambios, asegúrate de que puedes provocar el error a propósito. Anota:

1. Qué haces: "entro con mi usuario, abro Clientes y pulso Guardar".
2. Qué esperas: "que el cliente aparezca en la lista".
3. Qué pasa en realidad: "el botón gira un segundo y no pasa nada".
4. Dónde pasa: ¿en la vista previa, en la versión publicada o en las dos? ¿En el celular y en la computadora?

Prueba también en una ventana de incógnito. Si allí funciona, el problema puede ser una sesión vieja o datos guardados en tu navegador, no el código.

Esta descripción de cuatro líneas es lo más valioso que vas a producir hoy. Sirve para la IA, para ti y para cualquier persona que te ayude después.

2. Abre la consola del navegador

El navegador registra los errores aunque la pantalla no muestre nada. Para verlos:

• En Chrome o Edge: clic derecho en la página → Inspeccionar, o F12 (en Mac, Cmd + Option + I).
• Ve a la pestaña Console.
• Recarga la página y repite el paso que falla.

Busca líneas en rojo. Algunos mensajes típicos y lo que suelen significar:

• Cannot read properties of undefined: el código intenta usar un dato que no llegó. Muchas veces el problema real está en la consulta a la base de datos, no en la pantalla.
• is not defined o is not a function: algo se renombró o se borró en el último cambio.
• Failed to fetch o errores de CORS: la app no logra hablar con el servidor o con una API externa.

No tienes que entender todo el mensaje. Copia el texto completo del primer error rojo (no del último: el primero suele ser la causa y los demás, consecuencias).

3. Mira la pestaña Network

En la misma ventana de herramientas, abre Network y filtra por Fetch/XHR. Repite la acción que falla y observa las peticiones que aparecen. Fíjate en la columna Status:

• 200: la petición salió bien. Si aun así no ves datos, mira la respuesta (pestaña Response): puede venir vacía.
• 400: la app envió algo mal formado, por ejemplo un campo que no existe en la tabla.
• 401 / 403: problema de permisos o de sesión. Con Supabase, apunta casi siempre a la autenticación o a las reglas de seguridad de las tablas (Row Level Security).
• 404: la dirección no existe; quizá cambió el nombre de una función o de una tabla.
• 500: falló algo en el servidor. Ahí toca ir a los logs (paso 5).

Un detalle que confunde a mucha gente: en Supabase, si una tabla tiene Row Level Security activado y ninguna política te permite leer, la consulta no da error: devuelve una lista vacía. Si tu pantalla sale vacía con un 200, revisa las políticas de esa tabla.

4. Revisa qué cambió el último prompt

Los problemas casi nunca aparecen de la nada. Pregúntate cuál fue el último cambio antes de que se rompiera y revisa qué archivos tocó la IA. Lovable, Bolt y la mayoría de estas herramientas muestran los cambios de cada mensaje, y si tu proyecto está conectado a GitHub puedes ver cada commit con sus diferencias.

Señales de alerta en un cambio:

• Tocó archivos que no tienen nada que ver con lo que pediste.
• Cambió nombres de tablas, columnas o variables.
• Agregó o modificó una migración de base de datos.
• Borró código "que no se usaba".

5. Vuelve a la última versión que funcionaba

Casi todas las herramientas de vibe coding guardan un historial de versiones. Busca opciones como History, Restore o Revert. Volver atrás te devuelve a un punto estable desde el cual pedir el cambio de nuevo, esta vez con más cuidado.

Ten en cuenta una trampa: restaurar el código no siempre deshace los cambios en la base de datos. Si el último prompt creó o modificó tablas en Supabase, esas modificaciones pueden seguir ahí aunque el código vuelva atrás. Si después de restaurar algo sigue fallando, revisa la estructura de las tablas.

6. Lee los logs de Supabase

Si tu app usa Supabase, el panel tiene una sección de Logs con registros separados para la API, la base de datos (Postgres), la autenticación y las Edge Functions. Filtra por la hora en que reprodujiste el error y busca:

• Mensajes como new row violates row-level security policy (una política está bloqueando una inserción).
• Errores de columnas o tablas que no existen.
• Fallos en una Edge Function, con el mensaje exacto del error.

Si usas Firebase u otro backend, el principio es el mismo: busca el registro de errores del servidor en el momento exacto del fallo.

7. Escribe un prompt mejor (o deja de escribirle)

Con todo lo anterior ya tienes un prompt mucho más útil que "no funciona, arréglalo":

Al pulsar Guardar en la página Clientes, la petición POST a la tabla clients devuelve 403 y en los logs aparece "new row violates row-level security policy". El cambio empezó después de pedir el campo "empresa". No modifiques nada más; explícame primero qué política falla y por qué.

Pedirle que explique antes de cambiar reduce mucho los arreglos a ciegas.

Cuándo dejar de pedirle a la IA

Pon un límite. Si después de dos o tres intentos bien descritos el problema sigue, o aparece alguna de estas señales, para:

• Cada arreglo rompe otra cosa distinta.
• La IA vuelve a proponer una solución que ya probaste.
• Empieza a reescribir partes grandes de la app para un problema pequeño.
• El error involucra pagos, datos de usuarios o permisos.

En ese punto, seguir insistiendo suele empeorar el código. Lo mejor es volver a la última versión estable y pedir ayuda con la información que ya juntaste.

Resumen rápido

• Puedo reproducir el error y lo describí en cuatro líneas.
• Copié el primer error rojo de la consola.
• Revisé el código de estado en Network.
• Sé qué cambió el último prompt.
• Tengo identificada la última versión que funcionaba.
• Revisé los logs del backend a la hora del fallo.

Si sigues atascado

En este punto, una segunda mirada suele ahorrar días. En Devonauts ayudamos a personas que construyeron su app con IA a encontrar qué se rompió, arreglarlo y entender por qué pasó, sin juzgar el código. Puedes pasar el chequeo gratis, ver cómo funciona el rescate de apps hechas con IA o contarnos qué está fallando. Y si tu app ya está casi lista para salir, te puede servir nuestra checklist de seguridad antes de lanzar.