El problema «funcionaba ayer»: por qué las apps generadas por IA dejan de funcionar

Qué significa realmente el problema “funcionaba ayer"

El problema “funcionaba ayer” se siente injusto porque parece que no cambió nada. Misma app. Mismo usuario. Mismo botón. Y de repente aparece una pantalla en blanco, un mensaje de error o un login que gira sin avanzar.

La mayoría de las veces, “ayer” no significa que la app se rompió al azar. Significa que algo cambió en silencio en el fondo, y tu app dependía de eso sin que te dieras cuenta. En las apps generadas por IA, esas dependencias ocultas tienden a ser mayores porque el código se produce rápido, las configuraciones quedan dispersas y la app puede apoyarse en valores por defecto temporales que nunca fueron pensados para usuarios reales.

Algunos cambios invisibles provocan esto más a menudo de lo que se espera:

• Una sesión o permiso expiró, así que la app ya no tiene acceso a lo que necesita.
• Una clave, contraseña o variable de entorno se rotó, renombró o eliminó.
• Un proveedor cambió un límite, una regla de seguridad o un ajuste y tu app ahora falla una comprobación.
• El código se regeneró o se volvió a copiar, y un arreglo que funcionaba fue sobrescrito.

Por eso aparece tan a menudo en prototipos y primeros lanzamientos. Un prototipo suele construirse para demostrar un flujo, no para sobrevivir a condiciones reales como timeouts, nuevos usuarios, límites de uso o un redeploy accidental. Las herramientas de IA pueden generar una demo funcional rápido, pero a menudo omiten las barreras que hacen que los fallos sean previsibles y fáciles de diagnosticar.

Un ejemplo simple: presentas un flujo de registro el lunes usando tu propio navegador. El martes, un usuario nuevo lo intenta y queda bloqueado. Nada cambió en la UI, pero la app dependía de un token temporal guardado en tu navegador, o de una configuración de backend que solo funcionaba con tu cuenta.

La buena noticia es que estas fallas suelen ser prácticas, no misteriosas. Si tratas “funcionaba ayer” como una pista de que algo cambió fuera de pantalla, se convierte en una investigación con un final claro, no en un juego de adivinanzas.

Por qué las apps generadas por IA se topan más con esto

El patrón “funcionaba ayer” puede pasar en cualquier software, pero es extra común en apps generadas por IA porque el objetivo suele ser una demo rápida, no la estabilidad a largo plazo. La app parece terminada en la superficie, mientras que el trabajo de fiabilidad debajo falta.

Por qué la velocidad crea fragilidad

Las herramientas de IA son estupendas para producir algo que se ejecute una vez: una pantalla de login, una tabla de base de datos, una llamada a una API, un dashboard. Las apps en producción necesitan guardarraíles alrededor de esas partes. Sin ellos, los cambios normales pueden romper flujos críticos.

Patrones comunes: manejo laxo de configuraciones y secretos, auth que solo funciona en el camino feliz, falta de tests, demasiadas integraciones añadidas rápidamente y una estructura desordenada donde un cambio afecta inesperadamente a varias pantallas.

Los cambios pequeños se propagan más

En una base de código limpia, un cambio de clave normalmente rompe un solo lugar y el error te apunta a ello. En un código generado con prisas, ese mismo valor puede estar duplicado en archivos distintos, o una función helper puede existir en versiones ligeramente diferentes. Depurar empieza a sentirse aleatorio.

Ejemplo: un fundador actualiza una API key para pasar de una cuenta de prueba a una cuenta real. La app sigue compilando, pero un endpoint usa la clave antigua desde un archivo de config olvidado. La auth falla y los usuarios quedan atrapados en un bucle de login.

Este es el tipo de situación para lo que existe FixMyMess: tomar prototipos generados por IA y añadir guardarraíles básicos (entornos claros, manejo más seguro de secretos y una estructura más mantenible) para que la demo de ayer no se convierta en la caída de hoy.

Sesiones y tokens expirados (auth que caduca)

Muchas fallas “funcionaba ayer” son simplemente pases de login que expiran.

En palabras sencillas, una sesión o token es un pase temporal que demuestra que ya iniciaste sesión. Las apps lo usan para que no tengas que escribir tu contraseña en cada clic. El problema es que esos pases están diseñados para expirar, a veces tras minutos u horas.

Los prototipos generados por IA suelen fallar en las partes poco glamorosas de la auth: renovar el pase, manejar timeouts y evitar que los usuarios queden atascados. Así todo parece correcto justo después del sign-in y luego se rompe más tarde.

Desencadenantes típicos: tokens que expiran sin flujo de refresh, refresh implementado pero no integrado en la UI, relojes de servidor y cliente desincronizados, o tokens almacenados en el lugar equivocado (así la app “se olvida” de ti al refrescar).

Síntomas que puedes detectar sin leer código: usuarios que se desconectan aleatoriamente, la misma acción funciona justo después de loguearse pero falla después, o la app muestra errores de “Unauthorized”. En logs puede aparecer 401 o 403, que generalmente significa “no tienes permiso” o “tu pase ya no es válido.”

Preguntas rápidas que lo acotan:

• ¿Falla solo después de un tiempo?
• ¿Refrescar la página lo empeora?
• ¿Cerrar sesión y volver a entrar lo arregla temporalmente?

Ejemplo: un usuario de demo inicia sesión, prueba el checkout y funciona. Dos horas después, usuarios reales pulsan “Guardar” y vuelven a la pantalla de login. Ese patrón sugiere fuertemente expiración de tokens.

Equipos como FixMyMess suelen arreglar esto haciendo el refresh de tokens fiable, manejando timeouts con gracia y verificando el comportamiento con tiempos de espera reales, no solo una prueba rápida del camino feliz.

Claves API cambiadas, variables de entorno y ajustes de proveedor

Otra causa común no es un bug en tu código: es una conexión rota a algo de lo que depende tu app, como email, pagos, mapas, almacenamiento o login.

Las apps hablan con esos servicios usando secretos: claves API, client IDs, webhooks y URLs de callback. Esos valores pueden vivir en variables de entorno en tu host, en un dashboard del proveedor (Stripe, SendGrid, Google, etc.), en un archivo de config en el repo o en un gestor de secretos. Cuando cualquiera de ellos cambia, todo puede verse bien localmente pero fallar en producción.

¿Qué puede cambiar de la noche a la mañana? Los proveedores rotan claves, revocan claves tras actividad sospechosa o deshabilitan una clave expuesta en un repo público. Terminan trials. Se alcanzan límites de uso. Alguien edita ajustes en un dashboard y se olvida. Incluso pequeños cambios como modificar una URL de redirect o alternar un modo pueden bloquear usuarios reales.

Los síntomas son confusos porque la app sigue cargando, pero funcionalidades específicas dejan de funcionar: pagos fallan, mapas no se renderizan, emails no se envían, subidas devuelven errores 403 o el login regresa a la página de inicio de sesión.

Comprobaciones rápidas que suelen ahorrar tiempo:

• Confirma que estás en el entorno correcto (prod vs dev) y que allí están las claves correctas.
• Busca cambios recientes en proveedores: claves revocadas, trials expirados, cuotas superadas.
• Revisa los logs de despliegue por variables faltantes, errores de permisos o mensajes de “invalid API key”.
• Verifica que las URLs de webhook y redirect/callback coincidan con tu dominio actual.
• Asegúrate de que nadie haya hardcodeado una clave en un archivo que se sobrescribe durante el deploy.

Si heredaste una app generada por IA, es común encontrar placeholders, claves duplicadas entre entornos o secretos hardcodeados en el lugar equivocado. FixMyMess suele empezar con una auditoría rápida para localizar cada secreto y confirmar qué ajuste del proveedor está rompiendo producción.

Dependencias y actualizaciones de plataforma que rompen la compilación

A veces nada en tu repo cambió y la app sigue fallando. Eso es porque el código no es la única parte que se mueve. Tu app depende de paquetes, runtimes, ajustes de hosting y servicios de terceros que pueden cambiar sin que lo notes.

Los proyectos generados por IA son especialmente vulnerables porque a menudo fijan mal las versiones (o no las fijan). Puedes ver un package.json sin lockfile, rangos vagos como ^1.2.0 o instrucciones que tiran de “latest” cada vez. La siguiente instalación o despliegue descarga una dependencia un poco más nueva que se comporta distinto y ahora una función que antes funcionaba falla.

Las plataformas también cambian. Un host puede actualizar la versión por defecto de Node, una base de datos gestionada puede actualizar su engine, un proveedor serverless puede endurecer límites de petición o una actualización del navegador puede exponer un caso límite de CSS o JavaScript. No parece “un cambio que hiciste tú”, pero sigue siendo un cambio con el que tu app debe lidiar.

Señales que apuntan a dependencias o actualizaciones de plataforma:

• Nuevas advertencias o errores de build que antes no existían
• Despliegues que de pronto fallan en el proveedor de hosting
• Una función que funciona localmente pero falla en producción tras una instalación fresca
• La UI se ve un poco mal sin ediciones de diseño
• Errores que mencionan el nombre de un paquete, versión de Node/Python o un driver de base de datos

Escenario: tu demo funcionó el viernes. El lunes, un deploy fresco jala una nueva versión de una librería de fechas y un formulario de checkout empieza a rechazar fechas válidas. Nadie tocó el código, pero el comportamiento cambió.

Para reducir roturas repetidas, céntrate en builds repetibles: commitea lockfiles, evita rangos de versión vagos, fija versiones de runtime (Node, Python) en la configuración del proyecto y lee los logs de despliegue antes de fiarte de lo que muestra la UI.

Si heredaste un codebase generado por IA con builds inestables, FixMyMess puede auditarlo e identificar qué dependencia o cambio de plataforma está causando la rotura antes de que pierdas horas adivinando.

Regeneración de código que sobrescribe tus arreglos previos

Una causa sigilosa es la regeneración de código. Muchas apps creadas con IA no se tratan como codebases normales. Se tratan como output que puede rehacerse en cualquier momento. Eso es cómodo hasta que borra silenciosamente los cambios que hicieron que la app funcionara.

La regeneración puede ocurrir cuando alguien vuelve a preguntar a la herramienta, pulsa un botón de auto-fix, re-sincroniza un proyecto o pide una reconstrucción limpia tras un error menor. Algunas herramientas también reescriben archivos cuando cambias un ajuste de alto nivel o añades una función.

Los arreglos desaparecen porque el cambio se hizo en un lugar que el generador “posee”. Por ejemplo, parcheas un bug directamente en un archivo de componente y la siguiente ejecución reemplaza ese archivo desde una plantilla. Sin una regla clara de “este archivo es seguro para editar”, realmente no posees el código que tocaste.

Los síntomas suelen ser:

• El mismo bug vuelve tras un cambio menor
• Un archivo que editaste parece más nuevo, pero tus líneas han desaparecido
• Las cosas fallan de una manera que parece viaje en el tiempo: “¿por qué volvió esto?”
• El historial de Git (si lo tienes) muestra reescrituras grandes en lugar de ediciones pequeñas

Ejemplo: arreglas una redirección de login cambiando dos líneas. Al día siguiente, pides a la IA que añada una página de ajustes. Regenera el archivo de rutas y tu arreglo de redirección desaparece.

Para evitarlo, protege los arreglos: marca archivos clave como propiedad humana, anota qué cambiaste y por qué, centraliza la lógica crítica cuando sea posible y usa control de versiones para comparar y restaurar.

Equipos como FixMyMess ven este patrón en proyectos construidos con Lovable, Bolt, v0, Cursor o Replit. Un buen primer paso es identificar qué archivos se están sobrescribiendo y mover la lógica crítica fuera de la zona de impacto.

Paso a paso: cómo acotar qué cambió

Cuando aparece “funcionaba ayer”, no adivines. Encuentra el cambio más pequeño que explique la rotura.

Empieza con una línea de tiempo corta desde la última vez que funcionó. Incluye todo lo que parezca menor: un deploy, un ajuste en el dashboard de un proveedor de auth, alguien limpiando variables de entorno o una herramienta de IA regenerando parte de la app.

Luego confirma dónde estás probando. Muchas apps hechas con IA se comportan diferente en dev, staging y producción porque usan claves distintas, bases de datos distintas o URLs de callback distintas. No compares “local funcionó” con “producción roto” sin comprobar primero.

Un flujo simple:

• Bloquea tu prueba: misma cuenta, mismo dispositivo/navegador, mismos pasos cada vez.
• Captura el primer error que veas. Anota la hora y dónde aparece (mensaje en pantalla, logs del servidor, consola del navegador).
• Elige un área sospechosa: auth/sesión, claves API y vars de entorno, base de datos o un cambio reciente de deploy/build.
• Prueba un cambio controlado: deshaz o haz rollback de un solo cambio reciente (o prueba el deploy anterior) y vuelve a testar.
• Anota qué pasó tras cada prueba para no volver a suposiciones antiguas.

Ejemplo: de pronto los usuarios no pueden iniciar sesión. Si empezó justo después de un deploy, sospecha URLs de callback de auth o variables de entorno. Si empezó después de “esperar toda la noche”, sospecha expiración de tokens o ajustes de sesión. Si empezó justo después de regenerar código, sospecha un arreglo sobrescrito.

Si heredaste un prototipo generado por IA y la rotura se siente aleatoria, FixMyMess suele comenzar con un diagnóstico rápido que sitúa la falla en uno de estos buckets y luego verifica la solución con pruebas repetibles.

Trampas comunes que gastan horas

La forma más rápida de perder un día es perseguir lo que ves (un botón roto, una página en blanco) en lugar de lo que cambió detrás de escena. Las apps generadas por IA suelen fallar donde la UI no puede explicarlo: sesiones que expiran, un valor de config faltante o la app hablando con el servicio equivocado.

Una trampa común es depurar en el entorno equivocado. Arreglas cosas localmente y todo parece bien, pero producción sigue rota porque la app desplegada tiene variables de entorno distintas, secretos distintos o otra base de datos. Si el problema solo ocurre para usuarios reales, asume que el bug vive en producción hasta que demuestres lo contrario.

Otra pérdida de tiempo es compartir solo capturas de pantalla. Una imagen oculta el texto exacto del error, la marca temporal y la petición que lo disparó. Copia el mensaje de error, anota cuándo pasó y guarda la línea completa del log si la tienes. Una línea a menudo apunta directo a un token expirado, una clave API faltante o un cambio de permisos.

Errores que causan más thrash:

• Arreglar la página visible cuando la causa real es auth, permisos o config
• Editar settings de dev cuando la rotura está solo en staging o producción
• Pegar errores parciales (o capturas) en vez del mensaje completo y la hora
• Cambiar varias configuraciones a la vez y luego no saber cuál importaba
• Pulsar regenerate para resetear y sobrescribir el arreglo que funcionaba ayer

Ejemplo: actualizas un prompt para limpiar el flujo de login, regenera el código y la app compila otra vez. Pero la regeneración reemplazó tu lógica de refresh de sesión, así que los usuarios empiezan a desconectarse a los pocos minutos.

Si este patrón se repite, un changelog simple y una auditoría rápida de auth, secretos y despliegues pueden ahorrarte problemas. Los equipos traen estos casos a FixMyMess cuando necesitan a alguien que rastree el cambio real y haga que la solución perdure tras la siguiente regeneración.

Lista rápida antes de entrar en pánico

El objetivo no es adivinar la causa. Es saber si la rotura está ligada a un usuario, a una sesión del navegador, a un deploy o a un servicio de terceros.

Haz estas pruebas rápidas primero:

• Intenta la misma acción en una ventana privada/incógnito. Si funciona allí, probablemente trates con una sesión caducada, una cookie atascada o código frontend cacheado.
• Pregunta si alguna clave API, contraseña o secreto cambió en las últimas 24–72 horas (pagos, email, apps OAuth, contraseñas de DB).
• Recuerda: ¿redeployaste, cambiaste ajustes de hosting o actualizaste un paquete? Pequeños cambios de config pueden romper producción.
• Revisa los logs alrededor del momento exacto en que se rompió. Busca timestamps del primer error y mensajes como “invalid token”, “unauthorized”, “missing env” o “cannot connect”.
• Confirma quiénes están afectados. ¿Todos, o solo ciertas cuentas/roles/nuevas inscripciones? Eso apunta a permisos, comprobaciones de roles o diferencias en los datos.

Ejemplo: el fundador aún puede entrar, pero los usuarios nuevos no. Eso suele significar que el flujo de signup está fallando (clave del proveedor de email cambiada, límites de tasa alcanzados o un bug en la asignación de roles), no que toda la app esté rota.

Si puedes responder estas cinco comprobaciones en 10 minutos, normalmente evitas horas de suposiciones. Si heredaste código generado por IA y las señales están confusas, FixMyMess puede ejecutar una auditoría de código gratuita y decirte qué cambió y qué arreglar primero.

Un escenario simple: la demo funcionó y luego los usuarios quedaron bloqueados

Un fundador presenta una app nueva generada por IA a un inversor el martes. El login funciona, el dashboard carga y la prueba de pago pasa. El miércoles por la mañana, usuarios reales empiezan a registrarse y todos los intentos de login fallan. El fundador no cambió código, así que parece aleatorio.

Una causa probable es el manejo de tokens y sesiones. Muchos prototipos usan tokens de corta duración o una configuración de auth solo para dev que parece correcta en una demo rápida. De la noche a la mañana, la vida del token termina, falta el flujo de refresh o la app no puede renovar la sesión. Los usuarios son devueltos al login o ven un error genérico de “unauthorized”.

El fundador comprueba: ¿falla solo después de un tiempo, o inmediatamente en nuevos logins? Prueba iniciar sesión en un navegador limpio y luego busca en los logs “token expired” o “invalid session”. Si aparece, la solución suele ser un flujo de refresh correcto, comportamiento predecible del servidor y almacenamiento seguro de tokens.

Otra causa común es una clave API rotada. Una clave de pago, email o auth puede cambiarse, deshabilitarse o sustituirse. La app sigue usando la clave antigua guardada en una variable de entorno, así que las peticiones empiezan a fallar.

Forma rápida de acotarlo:

• Vuelve a probar el login en una ventana incógnito para descartar sesiones cacheadas.
• Revisa logs por “expired token” vs “invalid API key”.
• Verifica los valores actuales de las claves en el entorno del despliegue.
• Confirma los ajustes del proveedor (dominios permitidos, URLs de callback, límites de tasa).
• Tras un arreglo, ejecuta el mismo flujo dos veces: ahora y otra vez mañana.

Para evitar la misma sorpresa la próxima semana, fija dónde viven los secretos (no hardcodear), añade monitorización básica para fallos de auth y claves, y evita regenerar código sobre arreglos en producción. Si el codebase es generado por IA y difícil de desenredar, una auditoría enfocada de FixMyMess puede determinar si el problema es manejo de tokens, secretos o una sobrescritura por regeneración.

Siguientes pasos para que deje de pasar

Para reducir el patrón “funcionaba ayer”, trata tu app hecha con IA como un producto real, no como una demo de una sola vez. La mayoría de las “roturas misteriosas” son cambios pequeños sin registro, sin comprobaciones y sin alarmas.

Estabiliza lo que más cambia

Empieza por congelar las partes que se mueven. Si tu app depende de librerías, defaults de hosting o ajustes de proveedor, pequeñas actualizaciones pueden cambiar el comportamiento en silencio.

• Fija versiones de dependencias para que las instalaciones sean repetibles.
• Asegura variables de entorno y secretos (quién puede cambiarlos y dónde viven).
• Añade monitorización básica: una comprobación de uptime más alertas por errores de login y llamadas a APIs fallidas.
• Mantén los releases aburridos: un método de deploy, un lugar para ver logs.
• Haz la regeneración opt-in: no dejes que una herramienta reescriba archivos sin revisión.

Si un ajuste puede romper pagos, login o datos críticos, no debería poder editarse a la ligera.

Haz visibles los cambios y prueba los caminos de riesgo

Lleva un changelog ligero: cambios de prompt, rotaciones de claves, tiempos de deploy y actualizaciones de proveedores. Cuando algo se rompe, puedes comparar “último funcionando” con “primero roto” en minutos.

Añade algunos tests guardarraíles para flujos que tienden a fallar: login, signup, reset de contraseña y cualquier cosa que dependa de una clave API. Incluso comprobaciones simples antes del deploy pueden detectar vars de entorno faltantes, redirects rotos y fallos obvios de auth.

Si las roturas vuelven o ves problemas de seguridad como secretos expuestos o riesgo de inyección SQL, conviene traer a alguien que desenrede y refuerce el codebase. FixMyMess (fixmymess.ai) ofrece una auditoría de código gratuita para identificar las causas reales, luego repara y prepara apps generadas por IA para producción con verificación experta para que las soluciones no desaparezcan tras el siguiente deploy.