![Imagen de portada de [Vibe Coder #6] Ayer funcionaba y hoy no; ¿por qué, si no toqué el código?](/assets/images/posts/2b464497-056e-46c0-9685-7296bcdf8cf7/it-worked-yesterday-suspects-1.jpg)
«No toqué ni una línea de código, pero la aplicación que funcionaba perfectamente hasta ayer hoy no funciona». Es la queja más frecuente en las comunidades de vibe coding y una de las situaciones que más misteriosas parecen. Parece cosa de fantasmas, pero en realidad los sospechosos son pocos. Si los investigas en orden, normalmente encontrarás al culpable antes del mediodía.
Primero hay que corregir una premisa. «No cambié nada» solo significa «no cambié mi código». Mi aplicación no funciona en el vacío. Depende del navegador, de cientos de bibliotecas externas, de servidores de otras empresas (como OpenAI y Supabase) y de un plan de pago. Aunque yo no haga nada, el mundo cambia. Este episodio es una lista de las cosas que cambian.
Sospechoso 1: caché del navegador — estás viendo una copia antigua
Los navegadores guardan los archivos descargados una vez y los reutilizan para acelerar la carga. Esa copia guardada es la caché. El problema aparece cuando la aplicación cambia a una versión nueva, pero el navegador insiste en usar la copia antigua. El código nuevo y el antiguo se mezclan y el comportamiento se vuelve extraño.
Por suerte, comprobarlo es muy sencillo: abre la aplicación en una ventana de incógnito (ventana de navegación privada). Las ventanas de incógnito no usan la caché; si allí funciona, la culpable es la caché. Haz una recarga forzada (Cmd+Shift+R en Mac, Ctrl+Shift+R en Windows) para ignorarla y descargar los archivos de nuevo. Esta prueba de 30 segundos va primero porque muchos incidentes terminan, sorprendentemente, aquí.
Sospechoso 2: dependencias — cambió el código de otra persona
La mayor parte del código de mi aplicación no es realmente mío. Para funciones comunes como el inicio de sesión, el renderizado de pantallas y el cálculo de fechas, uso bibliotecas creadas y publicadas por desarrolladores de todo el mundo. Normalmente hay cientos conectadas entre sí; las llamamos dependencias. La enorme carpeta node_modules del directorio del proyecto es su almacén.
El problema es que estas bibliotecas se actualizan por separado. Si entre ayer y hoy moviste el proyecto a otro ordenador, reinstalaste algo o una IA añadió una biblioteca nueva y arrastró consigo las existentes, el código puede seguir igual mientras cambia el suelo bajo tus pies. El síntoma suele ser un error de compilación repentino y desconocido. En ese caso, envía a la IA el error completo junto con «Es posible que las dependencias hayan cambiado desde ayer. Compruébalo». Es el mismo método para transmitir información que aprendimos en la parte 5.
Sospechoso 3: servicios externos — el servidor de otra persona tiene problemas
Los servicios externos de los que depende mi aplicación funcionan en servidores de otras empresas. Esos servidores fallan, reciben mantenimiento y cambian sus políticas.
- Interrupción: Servicios como OpenAI, Supabase y Vercel mantienen páginas de estado (status page). Busca «OpenAI status» para comprobar al instante si hay una interrupción. Si la hay, no puedes hacer nada. Solo esperar.
- Límites y caducidad: Estos son sospechosos más silenciosos. Se agotaron los créditos gratuitos, se superó el uso mensual del plan gratuito o caducó la tarjeta registrada. El servicio retira silenciosamente hoy la cortesía de ayer. Abre Usage y Billing en el panel de cada servicio para verlo de inmediato.
Sospechoso 4: en realidad, tu yo de ayer — cambiaste algo
El último sospechoso es esa persona que no queremos reconocer: nosotros mismos. Quizá corregimos «solo una cosa pequeña» antes de acostarnos o una modificación solicitada a la IA afectó a más archivos de lo esperado. Por suerte, Git, aprendido en la parte 3, conserva el registro de la coartada. Pide a la IA «Muéstrame los commits y archivos modificados desde ayer» y listo. Los registros son más sinceros que la memoria.
Orden de investigación: empezar por lo más barato
La clave es el orden: empieza por las comprobaciones rápidas y baratas y continúa con las caras y lentas.
- Prueba en ventana de incógnito (30 segundos): Si funciona, es la caché. Termina con una recarga forzada.
- Comprobar el historial de Git (1 minuto): «¿Qué cambió desde ayer?». Si hubo cambios, ese es el principal sospechoso.
- Estado y uso de servicios externos (3 minutos): Comprueba la página de estado y Usage/Billing en el panel.
- Recopilar errores e investigar con IA (después): Si los tres puntos anteriores están descartados, sigue la rutina de la parte 5: recopila la consola del navegador y los registros del servidor y pide a la IA que investigue.
Si saltas este orden y empiezas por el paso 4, es fácil que la IA «repare» código sano y termine creando el problema real. Cambiar el código siempre es el último recurso.
Resumen
- «No cambié nada» solo significa «no cambié mi código». La caché del navegador, las bibliotecas, los servicios externos y los planes siguen cambiando.
- Si funciona en una ventana de incógnito, es la caché. Una recarga forzada lo soluciona.
- Si aparece de repente un error de compilación desconocido, sospecha de un cambio en las dependencias.
- Vale la pena guardar en favoritos las páginas de estado y los menús Usage/Billing de los servicios externos.
- Investiga de lo más barato a lo más caro: incógnito → historial de Git → estado externo → recopilar registros e investigar con IA. El código se modifica al final.
La próxima parte trata el tema que todos temen: la explosión de costes. Veremos cómo se facturan por separado los costes de AI API, DB y hosting, y cómo configurar salvaguardas que detengan la explosión desde el origen.