Bolt rompe la app con cada cambio: cómo frenarlo

Bolt.new rompe funciones que andaban porque cada prompt deja que el agente reescriba código que solo ve en parte y que no recuerda del todo, y después nadie comprueba que lo anterior siga funcionando. Se frena cambiando una sola cosa por prompt, bloqueando los archivos que ya funcionan, dejando tus reglas en el conocimiento del proyecto, marcando versiones buenas a las que volver y probando una lista corta después de cada cambio. Cuando algo se rompe, restaura la última versión buena en vez de escribir otra vez "arréglalo".

Aquí verás por qué aparecen las regresiones, qué hacer en los primeros cinco minutos y una rutina para que sean la excepción.

¿Por qué Bolt rompe lo que funcionaba?

Casi todo se explica con estas causas:

• El agente olvida. Bolt guarda en el contexto los mensajes recientes y descarta los viejos. Algo que decidiste hace veinte prompts ("deja el checkout como está") puede ya no estar ahí.
• Los archivos grandes se reescriben completos. Si una página de 1.500 líneas maneja cinco funciones, cambiar una implica regenerar código alrededor de las otras cuatro.
• La misma lógica vive en dos lugares. Después de muchos intentos de arreglo, una misma regla (quién ve una factura, cómo se calcula un precio) puede estar en dos componentes. El arreglo cae en uno y el otro conserva el error.
• Los prompts vagos invitan a cambiar de más. "Mejora el panel" le da permiso al agente para tocar todo en esa pantalla.
• Los arreglos automáticos se acumulan. Cada Attempt fix cambia más código a partir de una suposición, y la propia documentación de Bolt aconseja no presionarlo una y otra vez.
• Los cambios en la base no se deshacen con el código. El historial de versiones restaura archivos, no tablas. Si un cambio tocó la base, volver atrás el código puede dejarlos desfasados.

¿Qué hago apenas se rompe algo?

1. Deja de escribir prompts. Cada intento nuevo agranda la distancia entre "funcionaba" y "ahora", y la vuelve más difícil de entender.
2. Restaura la última versión buena. Haz clic en el icono del reloj en el menú superior para abrir el historial, elige la versión anterior al cambio, revisa la vista previa y presiona Restore this version. No gasta tokens.
3. Revisa la base de datos. Si el cambio creó o modificó tablas, la restauración no lo deshizo. Mira las tablas en la configuración de la base antes de seguir y lee nuestra guía sobre migraciones de base de datos en Bolt.
4. Rehaz el cambio en un paso más chico, con el patrón de prompt que verás abajo.

¿Cómo evito que vuelva a pasar?

Ten una prueba rápida de cinco minutos

Anota los recorridos que siempre tienen que funcionar y repásalos después de cada cambio que toque algo más que textos o colores. Por ejemplo:

Cinco minutos de clics atrapan la mayoría de las regresiones antes que tus usuarios.

Marca las versiones que funcionan

En el historial de versiones, pasa el cursor sobre una versión y usa Bookmark, o cámbiale el nombre ("pagos funcionando, 20 oct"). Cuando algo se rompa dos días después, sabrás exactamente a dónde volver.

Bloquea lo que ya está terminado

En la vista de código, clic derecho sobre un archivo y Lock file, o Lock all para una carpeta, y Bolt no lo tocará. Bloquea la configuración del login, los manejadores de pagos y todo lo que ya probaste. Usa Target file para dirigir a Bolt al único archivo que sí quieres cambiar.

Escribe las reglas una sola vez

Deja las reglas fijas en Project settings > Knowledge o en un archivo agents.md, que Bolt lee solo y que sobrevive a un /clear. La función de skills de Bolt también guarda instrucciones reutilizables. Las reglas útiles son concretas:

- No cambies autenticación, pagos ni el esquema de la base salvo que el prompt lo pida.
- No renombres ni borres columnas existentes de la base de datos.
- Mantén cada componente por debajo de 400 líneas; si crece, crea un archivo nuevo.
- Después de cada cambio, lista todos los archivos que modificaste.

Pide un cambio a la vez, con límites

Compara "arregla la página de reservas" con:

Solo en BookingForm.tsx: si la fecha ya pasó, muestra el error
"Elige una fecha futura" debajo del campo y desactiva el botón Enviar.
No cambies ningún otro archivo. No cambies el diseño.

El segundo dice qué archivo, qué hacer, qué no tocar y cómo lo vas a comprobar. Para lo que abarque varias pantallas, empieza en modo Plan, acuerda los pasos y constrúyelos de a uno.

Parte los archivos que siempre se rompen

Si el mismo archivo aparece en casi todas las regresiones, seguramente es demasiado grande. Pídele a Bolt que lo divida en componentes más chicos, dejando el original como envoltorio, y prueba después de cada división. El centro de ayuda de Bolt sugiere refactorizar los archivos de unas 500 líneas o más.

Suma pruebas automáticas cuando ya hay usuarios

La prueba manual deja de escalar en algún momento. Las pruebas unitarias (por ejemplo con Vitest) para las reglas importantes, como precios, permisos y fechas, se corren en la terminal con un comando antes de publicar. Las pruebas de punta a punta con Playwright conviene correrlas en tu computadora o en GitHub Actions. En pruebas para código generado con IA te contamos por dónde empezar.

Usa una rama de GitHub para lo riesgoso

Con GitHub conectado, crea una rama desde el menú de GitHub en Bolt antes de un cambio grande. Si sale mal, vuelves a main. La fusión se hace en GitHub, que además te muestra exactamente qué cambió.

¿Cuándo ya no es un problema de prompts?

Si el mismo error vuelve tres veces, arreglar una pantalla rompe otra que no tiene nada que ver, o encuentras la misma función escrita dos veces, el problema es la estructura del código, no tus prompts. A esa altura, una limpieza (quitar duplicados, separar el acceso a datos de las pantallas, poner pruebas alrededor de las reglas clave) sale más barata que otra semana de parches. En ¿reescribir o arreglar tu app? te ayudamos a decidir hasta dónde ir.

Respuestas rápidas

¿Restaurar una versión gasta tokens? No. Restaurar desde el historial es gratis; pedirle a Bolt que deshaga un cambio, no.

¿Restaurar una versión deshace los cambios en la base? No. La documentación del historial de versiones de Bolt aclara que restaurar no modifica tu base de Bolt ni de Supabase.

¿Cambiar al agente Max evita las regresiones? Razona más en cambios complejos e interconectados, pero no puede recordar lo que nunca vio. Pesan más los prompts claros y los bloqueos.

¿Cada cuánto marco una versión? Después de cada función que probaste y te dejó conforme.

¿Cansado de arreglar lo mismo dos veces?

La revisión gratuita es un primer vistazo rápido a la app publicada. Si las regresiones no paran, nuestro servicio para arreglar apps de Bolt busca la causa en la estructura y pone precio a cada arreglo antes de empezar, y un plan de mantenimiento deja a alguien atento después de cada versión. También puedes contarnos qué se rompe.