Por que agentes de IA erram na migração do Bubble
Agentes de IA erram na migração do Bubble quando leem o export do app como se fosse a planta. O arquivo .bubble lista cada página, workflow e campo do editor, mas não diz quais o negócio ainda usa, quais credenciais importam nem quem chama o app de fora. Esses fatos precisam estar fechados antes de qualquer código novo.
O que o export do Bubble realmente contém?
Tudo o que o editor guarda, e nada que rode. O Bubble permite exportar o app em JSON, e o artigo de suporte descreve esse arquivo como otimizado para importar em outro aplicativo Bubble. Código não sai: a página sobre propriedade diz que apps do Bubble só rodam na plataforma do Bubble, e os registros saem à parte, em CSV ou pela API.
Dentro do arquivo estão as páginas, os elementos reutilizáveis, os workflows de backend, os tipos de dado, os option sets, os plugins, os estilos e as chamadas do API Connector. Eles se apontam por ids gerados, e não pelos nomes que você vê no editor, então o sentido de um botão pode estar espalhado entre uma página, um elemento reutilizável e um workflow em outro canto do arquivo.
Isso faz do export um ótimo inventário e uma planta ruim. O inventário diz o que está nas prateleiras. A planta diz o que o prédio precisa, e anos de edição deixam muita coisa na prateleira que o prédio deixou de usar.
Por que um agente que lê o export cru acaba chutando?
Porque o arquivo nunca diz o que importa. O modelo precisa deduzir isso a partir de referências espalhadas por uma entrada grande, e esse tipo de dedução é justamente onde os modelos de contexto longo testados em 2025 foram mais fracos.
O benchmark NoLiMa, publicado na ICML 2025, avaliou 13 modelos de linguagem que dizem suportar pelo menos 128 mil tokens de contexto. Em 32 mil tokens, 11 deles caíram para menos da metade da nota que tinham com entradas curtas. A tarefa pedia para ligar fatos com pouca palavra em comum, o que se parece com o que um export pede: o gatilho de um workflow e o elemento que ele afeta costumam compartilhar só um id.
Quem programa sente isso no dia a dia. Na pesquisa de desenvolvedores do Stack Overflow de 2025, a frustração com ferramentas de IA mais citada, por 66% dos desenvolvedores que responderam, foi a de soluções "quase certas, mas não exatamente". Numa migração, quase certo é um workflow reconstruído que ninguém usava, ou uma regra de negócio que ficou para trás sem ninguém perceber.
Uma janela de contexto maior não resolve?
Não. Os modelos daquele benchmark anunciam 128 mil tokens ou mais, e a maioria perdeu mais da metade da nota de entrada curta já em 32 mil. Modelos incluídos no benchmark mais tarde em 2025 se saíram melhor, com o GPT-4.1 marcando 79,8 em 32 mil contra 97,0 com entradas curtas, mas uma janela maior só deixa o agente ler mais do arquivo de uma vez. Não faz o arquivo dizer quais partes estão vivas.
A informação que falta não está no export em tamanho nenhum. Se uma página ainda recebe tráfego de um e-mail, se um meio de pagamento ainda chama um webhook, se um plugin pago ainda faz alguma coisa: são fatos sobre o uso do app, e um arquivo de definição não tem como carregá-los.
O que o export não conta?
Três fatos, e cada um muda o escopo ou o risco da reconstrução.
O que está morto. Páginas para as quais nada navega, workflows que nada dispara, plugins ainda cobrados num plano pago. Reconstruir isso é desperdício. Mas sem referência não quer dizer sem uso: toda página do Bubble tem URL pública, então uma página sem link interno pode ser justamente a que um e-mail ou um login externo abre.
De quais credenciais o app depende. Chaves de API e configurações de integração digitadas no editor muitas vezes não existem em nenhum outro lugar. Uma reconstrução que as descobre no meio do caminho trava num acesso que ninguém lembra de ter concedido.
Quem chama o app de fora. Workflows de backend expostos como endpoint, webhooks e consumidores da Data API continuam chamando o app antigo. O export mostra o que está exposto. Não mostra quem depende disso, e uma virada que nunca listou esses chamadores os quebra no dia da troca.
O que precisa acontecer antes de alguém escrever código?
Os fatos vêm primeiro, apurados por código que lê o export sempre do mesmo jeito, e pessoas decidem o que fica. A geração vem depois, a partir de documentos que dá para conferir.
A ordem que seguimos começa por uma auditoria que lista o que não é usado em cada área do app, com um nível de confiança por item. O app é limpo no Bubble e exportado de novo. A documentação as-is descreve então o banco, as APIs, os workflows e as regras de negócio numa forma verificável, e guarda cada credencial que o export traz num arquivo .env local. A arquitetura alvo, o novo modelo de dados e o plano de migração saem dessa documentação, não do arquivo cru.
A construção parte de um backlog atômico com dois gates: todo requisito tem uma história, e toda coluna migrada é lida ou escrita pelo código novo. Nos nossos projetos, agentes escrevem código a partir desses documentos e um engenheiro decide o que passa em cada gate, então o código nasce de fatos em vez de preencher lacunas. Publicamos esse método, o que usamos nas nossas migrações, como UnBubble, com licença open source. O UnBubble é um projeto independente, sem afiliação nem endosso da Bubble.
Como isso aparece num export?
Pense numa locadora de equipamentos com o sistema no Bubble. É o app fictício que criamos para o repositório do UnBubble, porque export de cliente não pode ser mostrado. O export tem sete páginas. Fora a página inicial e a de erro 404, que o Bubble serve por conta própria, três não recebem nenhuma navegação interna. Uma leitura que só segue referências internas marcaria as três como mortas.
Uma dessas três é a página para onde o usuário volta depois de autorizar a agenda externa, alcançada por um link com a URL completa, e não por navegação interna. Apagá-la quebra a conexão da agenda, então a auditoria a mantém e aponta só as outras duas. O mesmo export tem seis workflows de backend: um que nada dispara, um chamado apenas por esse workflow morto, e um exposto como endpoint público que outro sistema pode estar chamando agora mesmo. Há ainda um plugin pago na lista de instalados que nenhum elemento usa.
Nada disso aparece marcado no arquivo, e tudo isso muda o escopo.
Projetos de cliente esbarram na mesma lacuna. Quando a plataforma da Colo Saúde chegou à Yowpi, construída por um fornecedor anterior, estava sem dono técnico, e ninguém sabia dizer o real estado de segurança de um sistema que guardava dados de pacientes. O primeiro projeto respondeu a essa pergunta: nossa auditoria de segurança deu nota 7 de 10 à plataforma, e as correções a levaram a 10. A migração para Next.js, React Native e Supabase só começou depois disso e está em andamento.
Perguntas frequentes
Um agente de código não consegue simplesmente ler o export inteiro?
Consegue ler, e vai produzir algo plausível. O arquivo não traz nenhum sinal de uso, então o agente decide o que importa por dedução, e entrada longa piora a dedução. Com documentação verificada e um backlog de escopo fechado, o mesmo agente trabalha sobre fatos em vez de palpites.
Isso quer dizer que IA é a ferramenta errada para sair do Bubble?
Não. Agentes ajudam a escrever o código novo quando o escopo está certo. O erro é deixar um agente decidir o escopo a partir de um arquivo que nunca foi feito para descrevê-lo.
E os dados, como ficam?
Os registros não viajam no export. Eles saem por CSV ou pela API do Bubble, tabela por tabela, seguindo o plano de migração. Cada tabela é reconciliada antes da troca, para o dono do app assinar os números.
O próximo passo
Se o seu app no Bubble sustenta uma operação que não pode parar enquanto muda, o Diagnóstico de Arquitetura Operacional é onde mapeamos o que transfere, o que se redesenha e por onde a migração começa.
Leia também
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico