Por qué los agentes de IA fallan al migrar de Bubble
Los agentes de IA fallan al migrar de Bubble cuando leen el export de la aplicación como si fuera el plano. El archivo .bubble lista cada página, workflow y campo del editor, pero no dice cuáles usa todavía el negocio, qué credenciales importan ni quién llama a la aplicación desde fuera. Esos hechos se cierran antes de escribir código.
¿Qué contiene de verdad un export de Bubble?
Todo lo que guarda el editor, y nada que se ejecute. Bubble permite exportar la aplicación en JSON, y su artículo de soporte describe ese archivo como optimizado para importarlo en otra aplicación de Bubble. El código no sale: la página sobre propiedad dice que las aplicaciones de Bubble solo corren en la plataforma de Bubble, y los registros salen aparte, en CSV o por la API.
Dentro del archivo están las páginas, los elementos reutilizables, los workflows de backend, los tipos de dato, los option sets, los plugins, los estilos y las llamadas del API Connector. Se apuntan entre sí con ids generados, no con los nombres que ves en el editor, así que el sentido de un botón puede estar repartido entre una página, un elemento reutilizable y un workflow en otra parte del archivo.
Eso hace del export un excelente inventario y un mal plano. El inventario dice qué hay en los estantes. El plano dice qué necesita el edificio, y años de edición dejan en los estantes mucho que el edificio dejó de usar.
¿Por qué un agente que lee el export en crudo termina adivinando?
Porque el archivo nunca dice qué importa. El modelo tiene que deducirlo a partir de referencias repartidas en una entrada grande, y ese tipo de deducción es justo donde los modelos de contexto largo evaluados en 2025 fueron más débiles.
El benchmark NoLiMa, publicado en ICML 2025, evaluó 13 modelos de lenguaje que dicen soportar al menos 128 mil tokens de contexto. A 32 mil tokens, 11 de ellos cayeron por debajo de la mitad del puntaje que obtenían con entradas cortas. La tarea pedía conectar hechos con pocas palabras en común, algo parecido a lo que pide un export: a menudo, el disparador de un workflow y el elemento que afecta solo comparten un id.
Quien programa lo nota en el día a día. En la encuesta de desarrolladores de Stack Overflow de 2025, la frustración con herramientas de IA más citada, por el 66% de los desarrolladores que respondieron, fue la de soluciones "casi correctas, pero no del todo". En una migración, casi correcto es un workflow reconstruido que nadie usaba, o una regla de negocio que se quedó en el camino sin que nadie lo notara.
¿Una ventana de contexto más grande no lo resuelve?
No. Los modelos de ese benchmark anuncian 128 mil tokens o más, y la mayoría perdió más de la mitad de su puntaje con entradas cortas ya a 32 mil. Los modelos que se sumaron al benchmark más tarde en 2025 rindieron mejor, con GPT-4.1 marcando 79,8 a 32 mil frente a 97,0 con entradas cortas, pero una ventana más grande solo deja que el agente lea más del archivo a la vez. No hace que el archivo diga qué partes siguen vivas.
La información que falta no está en el export en ningún tamaño. Si una página todavía recibe tráfico de un correo, si una pasarela de pago todavía llama a un webhook, si un plugin de pago todavía hace algo: son hechos sobre el uso de la aplicación, y un archivo de definición no puede cargarlos.
¿Qué no te dice el export?
Tres hechos, y cada uno cambia el alcance o el riesgo de la reconstrucción.
Qué está muerto. Páginas a las que nada navega, workflows que nada dispara, plugins que siguen cobrándose en un plan de pago. Reconstruirlos es desperdicio. Pero sin referencias no es lo mismo que sin uso: toda página de Bubble tiene su propia URL pública, así que una página sin enlaces internos puede ser justo la que abre un correo o un inicio de sesión externo.
De qué credenciales depende la aplicación. Las claves de API y la configuración de las integraciones escritas en el editor muchas veces no existen en ningún otro lugar. Una reconstrucción que las descubre a mitad de camino se frena en un acceso que nadie recuerda haber dado.
Quién llama a la aplicación desde fuera. Los workflows de backend expuestos como endpoint, los webhooks y los consumidores de la Data API siguen llamando a la aplicación antigua. El export muestra qué está expuesto. No muestra quién depende de eso, y un corte que nunca listó a esos consumidores los rompe el día del cambio.
¿Qué tiene que pasar antes de que alguien escriba código?
Primero se cierran los hechos, con código que lee el export siempre de la misma forma, y las personas deciden qué se queda. La generación viene después, a partir de documentos que se pueden verificar.
El orden que seguimos empieza con una auditoría que lista lo que no se usa en cada área de la aplicación, con un nivel de confianza por elemento. La aplicación se limpia en Bubble y se exporta de nuevo. Después, la documentación as-is describe la base de datos, las APIs, los workflows y las reglas de negocio de forma verificable, y guarda cada credencial que trae el export en un archivo .env local. La arquitectura objetivo, el nuevo modelo de datos y el plan de migración salen de esa documentación, no del archivo en crudo.
La construcción parte de un backlog atómico con dos gates: cada requisito tiene una historia, y cada columna migrada la lee o la escribe el código nuevo. En nuestros proyectos, los agentes escriben código a partir de esos documentos y un ingeniero decide qué supera cada gate, así que el código nace de hechos en lugar de rellenar huecos. Publicamos este método, el que usamos en nuestras migraciones, como UnBubble, con licencia open source. UnBubble es un proyecto independiente, sin afiliación ni respaldo de Bubble.
¿Cómo se ve eso en un export?
Piensa en una empresa de alquiler de equipos con su sistema en Bubble. Es la aplicación ficticia que creamos para el repositorio de UnBubble, porque el export de un cliente no se puede mostrar. Su export tiene siete páginas. Dejando fuera la página de inicio y la de error 404, que Bubble sirve por su cuenta, tres no reciben ninguna navegación interna. Una lectura que solo sigue las referencias internas marcaría las tres como muertas.
Una de esas tres es la página a la que vuelve el usuario después de autorizar el calendario externo, a la que se llega por un enlace con su URL completa y no por navegación interna. Borrarla rompe la conexión del calendario, así que la auditoría la conserva y señala solo las otras dos. El mismo export tiene seis workflows de backend: uno que nada dispara, uno que solo llama ese workflow muerto, y uno expuesto como endpoint público que otro sistema puede estar llamando ahora mismo. Hay además un plugin de pago en la lista de instalados que ningún elemento usa.
Nada de esto aparece marcado en el archivo, y todo eso cambia el alcance.
Los proyectos de clientes chocan con el mismo vacío. Cuando la plataforma de Colo Saúde llegó a Yowpi, construida por un proveedor anterior, estaba sin dueño técnico, y nadie podía decir cuál era el estado real de seguridad de un sistema que guardaba datos de pacientes. El primer proyecto respondió esa pregunta: nuestra auditoría de seguridad le dio a la plataforma una nota de 7 sobre 10, y las correcciones la llevaron a 10. La migración a Next.js, React Native y Supabase empezó solo después y sigue en curso.
Preguntas frecuentes
¿Un agente de código no puede simplemente leer el export entero?
Puede leerlo, y va a producir algo plausible. El archivo no trae ninguna señal de uso, así que el agente decide qué importa por deducción, y una entrada larga empeora la deducción. Con documentación verificada y un backlog de alcance cerrado, el mismo agente trabaja sobre hechos en lugar de suposiciones.
¿Quiere decir que la IA es la herramienta equivocada para salir de Bubble?
No. Los agentes ayudan a escribir el código nuevo cuando el alcance está bien definido. El error es dejar que un agente decida el alcance a partir de un archivo que nunca se hizo para describirlo.
¿Y qué pasa con los datos?
Los registros no viajan en el export. Salen por CSV o por la API de Bubble, tabla por tabla, según el plan de migración. Cada tabla se concilia antes del corte, para que el dueño de la aplicación firme los números.
El siguiente paso
Si tu aplicación en Bubble sostiene una operación que no puede detenerse mientras cambia, el Diagnóstico de Arquitectura Operacional es donde mapeamos qué se transfiere, qué se rediseña y por dónde empieza la migración.
Lee también
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico