O vibe coding é magia na demo. E a sua app, aguenta mesmo em produção?

O vibe coding está pronto para produção? Para protótipos e ferramentas internas, sim — e de forma brilhante. Para uma app publicada nas lojas, com utilizadores reais e dados reais, não por si só. As verdadeiras limitações do vibe coding não estão no código que ele escreve; estão em tudo o que a produção exige à volta desse código.

A própria indústria no-code começou a dar nome à divisão. O State of No-Code 2026 da Caspio descreve uma IA a puxar o mercado em duas direções ao mesmo tempo e termina numa fórmula sem rodeios: «A divisão não é "IA boa vs. IA má". É descartável vs. duradouro (disposable vs. durable).»

Então, o que torna descartável um protótipo feito em vibe coding? Não é a demo — é tudo o que está à volta dela. Sete muros, todos invisíveis no ecrã do portátil, todos bem reais no dia em que tenta publicar. Três deles — o código nativo, a submissão às lojas e o ciclo de vida da app — são tão específicos do móvel que lhes dedicámos uma análise completa; aqui, ocupam o seu lugar no quadro geral.

Muro 1 — Alojamento e propriedade

Para sermos justos com as ferramentas: em geral, o código é seu. A documentação do Lovable di-lo explicitamente, e pode exportar para o GitHub. O que não é seu é tudo aquilo de que o código precisa para correr. Por omissão, a sua app vive na cloud gerida do fornecedor — Lovable Cloud, alojamento do Bolt, Vercel — com o backend, a base de dados e o pipeline de build operados por eles, aos preços deles, nos termos deles. Ser dono do código-fonte de uma app cuja infraestrutura pertence a outra pessoa é como ser dono da planta de uma casa construída em terreno arrendado. Produção significa que alguém responde por essa infraestrutura durante anos: disponibilidade, backups, renovações, faturas. Na demo, ninguém responde.

Mutualização. Uma plataforma SaaS opera uma única infraestrutura para todas as suas apps, mantida por uma equipa cujo trabalho a tempo inteiro é mantê-la de pé — e o custo está incluído na subscrição, em vez de ser descoberto mais tarde. Todas as apps que já publicámos correram nesse modelo desde o primeiro dia.

Muro 2 — Backend e dados

A camada de dados de um protótipo está otimizada para a demo: existe, responde, parece bem. Os dados de produção têm exigências mais duras — migrações, backups, ambientes que separam os testes da realidade. Em julho de 2025, essa lição fez manchetes quando o agente do Replit apagou uma base de dados de produção durante um congelamento de código explícito, eliminando os registos de mais de 1200 executivos. O Replit reagiu anunciando a separação automática entre bases de dados de desenvolvimento e de produção — fechando uma lacuna que os sistemas de produção tratam como requisito de base.

E para lá da base de dados, a produção é onde vivem os problemas operacionais sem glamour. O email transacional é o clássico: um fundador de SaaS relatou no r/SaaS «frequentemente menos de 50% de taxa de entrega» em infraestrutura de email partilhada. Não há prompt que resolva a entregabilidade.

Um backend que já existia antes da sua app. Numa plataforma gerida, a camada de dados — migrações, backups, a separação entre testes e produção — foi construída uma vez, por profissionais, e é posta à prova todos os dias por todas as apps que nela correm; só o nosso módulo de e-commerce corre em produção para milhares de comerciantes. A canalização sem glamour é o trabalho diário de uma equipa de plataforma, não a descoberta que faz à terceira semana.

Muro 3 — Autenticação e segurança

Este é o muro mais bem documentado, porque os investigadores não param de o medir. O estudo de 2025 da Veracode, com mais de 100 modelos, concluiu que o código gerado por IA introduzia vulnerabilidades do OWASP Top 10 em 45% das tarefas testadas. Um benchmark académico publicado em dezembro de 2025 mediu o fosso na sua forma mais crua: o melhor agente produzia soluções funcionalmente corretas 61% das vezes, mas apenas 10,5% dessas soluções eram seguras. E em 2025 foi registado um CVE a documentar a ausência de Row-Level Security em apps geradas pelo Lovable — o investigador de segurança Matt Palmer analisou 1645 dessas apps e encontrou 170 a expor dados, incluindo chaves de API e detalhes financeiros. Quando a Escape.tech analisou mais de 5600 apps ativas criadas por vibe coding em outubro de 2025, encontrou mais de 2000 vulnerabilidades e mais de 400 segredos expostos.

Nada disto significa que os modelos sejam maus. Significa que a revisão de segurança é uma exigência de produção pela qual um protótipo, por definição, nunca passou.

Segurança escrita uma vez, herdada por todos. A autenticação de uma plataforma é um único código, endurecido por anos de tráfego real; quando algo precisa de correção, essa correção escreve-se uma vez — entra imediatamente em produção do lado do servidor e segue para a próxima build de todas as apps. É essa a diferença estrutural entre um login mantido por engenheiros e milhares de logins gerados, cada um a reinventar sozinho as suas próprias regras de acesso.

Muro 4 — Submissão às lojas

Eis o facto que a maioria dos tutoriais de vibe coding salta: a maior parte das ferramentas prompt-to-app constrói aplicações web, não apps móveis. O próprio FAQ do Lovable di-lo sem rodeios: «Não, o Lovable está focado em aplicações web.» O v0 gera código web publicado na Vercel. O Bolt é a exceção parcial — a sua integração com o Expo gera código React Native verdadeiro —, mas as builds dos binários, as contas de programador e a revisão da Apple continuam a ser inteiramente problema seu.

A solução alternativa habitualmente sugerida — embrulhar a app web num invólucro nativo — esbarra na Guideline 4.2 da Apple: «A sua app deve incluir funcionalidades, conteúdo e uma interface que a elevem para lá de um site reempacotado.» Na experiência da nossa equipa de publicação, os revisores testam por hábito as apps offline; um wrapper que mostra um ecrã em branco diz-lhes tudo. E a revisão é implacável mesmo para apps a sério: a Apple rejeita cerca de 42% das primeiras submissões (linha de base da Apple, medida nas apps que a nossa equipa de publicação submeteu nos últimos 12 meses). Escrevemos um guia sobre as razões pelas quais a Apple rejeita apps e como recuperar.

A submissão como processo industrial. Uma plataforma compila binários desenhados para passar a revisão, e quando a Apple ou a Google sobem a fasquia — novas etiquetas de privacidade, novos prazos de SDK, novas verificações de completude — atualiza uma vez, e todas as apps que publica herdam a correção. Quinze anos de submissões às lojas são uma forma de capital que nenhum prompt consegue gerar.

Muro 5 — Funcionalidades nativas do dispositivo

As funcionalidades que fazem uma app móvel valer mais do que um site são precisamente aquelas com que uma app web embrulhada se atrapalha. As notificações push são o exemplo mais flagrante: no iOS, o push web só funciona em apps web instaladas manualmente no ecrã principal — nunca no navegador. Câmara, modo offline, biometria: cada uma exige plugins nativos adicionados, configurados e mantidos à mão, fora de tudo o que a IA gerou. Uma demo web "otimizada para móvel" e uma app nativa são espécies diferentes com a mesma cara.

Nativo por construção. Numa plataforma que compila Swift e Kotlin verdadeiros, push, câmara, offline e haptics são componentes pré-construídos, mantidos a cada versão do iOS e do Android — a camada que faz uma app parecer profissional é o ponto de partida, não um acrescento tardio.

Muro 6 — Regeneration drift: o código que se reescreve sozinho

Chamemos-lhe regeneration drift — a deriva da regeneração: cada novo prompt regenera o código contra um contexto ligeiramente diferente, e a correção de ontem pode desaparecer discretamente na geração de hoje. Addy Osmani, engineering lead do Google Chrome, deu nome ao padrão — «dois passos atrás»: «Tentamos corrigir um pequeno bug… A IA sugere uma alteração que parece razoável… Essa correção parte outra coisa.» Os dados confirmam: a análise de 211 milhões de linhas de código alteradas da GitClear encontrou blocos de cinco ou mais linhas duplicadas multiplicados por 8 em 2024, e a fatia de código revista nas duas semanas a seguir a ser escrita quase duplicou desde 2020. Um código que não fica quieto é um código sobre o qual não se pode prometer nada — muito menos a um utilizador que encontrou um bug.

Alicerces que não se mexem. Numa plataforma, a IA gera apenas a fina camada personalizada por cima de um substrato versionado e testado — autenticação, checkout, CMS e sistema de design fazem parte do substrato que nenhum prompt regenera. A deriva fica confinada a essa camada fina em vez de tomar a app inteira: o checkout de que depende não pode reescrever-se sozinho, em silêncio.

Muro 7 — Privacidade e conformidade

Uma app publicada carrega obrigações legais que uma demo nunca cumpre. As etiquetas de privacidade da Apple e o formulário de segurança dos dados do Google Play exigem que declare que dados recolhe, para onde vão e quem os trata — perguntas a que uma stack feita em vibe coding muitas vezes não sabe responder, porque algures um valor por omissão colocou os dados dos seus utilizadores numa infraestrutura que nunca escolheu. O RGPD sobe ainda mais a fasquia: consentimento específico e não agregado, residência de dados que consiga realmente indicar, uma lista de subcontratantes que realmente conheça. Nada disto aparece numa demo. Tudo isto aparece numa revisão de loja — ou, pior, numa queixa.

Conformidade tratada uma vez, a montante. Um único esforço jurídico e de engenharia ao nível da plataforma — no nosso caso, todos os dados alojados na Europa, gestão de consentimento integrada, deteção automática das permissões que cada funcionalidade exige — serve todas as apps e mantém-se atual à medida que as regras evoluem. Os nossos motores de compilação vão um passo mais longe: uma biblioteca só entra no binário se a funcionalidade que a usa estiver ativada, por isso as apps não se limitam a declarar menos — contêm menos.

Os sete muros do vibe coding — resumo

Sete muros, sete perguntas. As respostas de plataforma acima são as nossas; estas perguntas são as suas. Responda-lhes a propósito do seu protótipo:

1. Quem opera a infraestrutura em que ela corre — e continuará a operá-la daqui a dois anos?
2. Onde vivem os dados, e o que acontece quando o esquema tiver de mudar?
3. Alguém que saiba ler código reviu a autenticação e as regras de acesso?
4. Consegue produzir um binário iOS e Android assinado que passe a revisão das lojas?
5. Consegue enviar uma notificação push para um telemóvel bloqueado?
6. Consegue corrigir um bug daqui a seis meses sem regenerar — e voltar a partir — tudo o resto?
7. O fluxo de consentimento e o tratamento de dados sobreviveriam a uma queixa ao abrigo do RGPD?

Três ou mais respostas «não» (ou «não sei»), e o que tem em mãos é um protótipo. Isso não é um fracasso — um protótipo é uma coisa genuinamente útil. Valida uma ideia numa tarde, por quase nada. O fracasso está apenas na confusão: planear um lançamento, uma base de utilizadores e um negócio sobre algo construído para ser descartável.

A conclusão não é «evite a IA». Usamos geração de código por IA todos os dias nas nossas próprias equipas de engenharia — o nosso CMO já o dizia em abril de 2025, com a ressalva que a indústria entretanto confirmou: «Sem conhecimentos de programação, é fácil ficar rapidamente sobrecarregado ou bloqueado, porque a IA pode criar incoerências significativas se for usada sem supervisão humana especializada.»

A conclusão é apontar a velocidade da IA a uma fundação que chega às lojas. É essa toda a lógica do AI Extension Builder (atualmente em Beta, disponível para todos os clientes), a resposta da GoodBarber à pergunta prompt-to-app: descreve uma funcionalidade em linguagem corrente, um agente de IA constrói-a — mas constrói-a dentro de uma plataforma, sobre APIs documentadas, e o resultado herda tudo aquilo que falta a um protótipo. O design segue automaticamente o sistema de design da sua app. A secção é publicada sob a forma de binários Swift e Kotlin genuínos, através do mesmo pipeline de lojas que operamos desde 2011 — com uma equipa de publicação que recupera 91% das primeiras rejeições da Apple quando elas acontecem (últimos 12 meses).

Os muros 2 e 3 — backend e segurança — recebem o mesmo tratamento. Quando uma secção construída pela IA precisa de guardar dados, a integração com o Supabase cria a estrutura da base de dados por si, no seu próprio projeto Supabase, em infraestrutura que controla — e cada tabela sai com políticas de Row-Level Security ativadas por omissão. É exatamente o modo de falha documentado no CVE do Lovable, resolvido antes sequer de saber que devia perguntar por ele. E o núcleo da plataforma — alojamento, base de dados, notificações push, analytics e pagamentos — está incluído numa única subscrição, pelo que não há uma pilha de serviços de terceiros para montar, proteger e pagar em separado. Custo total de propriedade: cerca de um décimo do desenvolvimento à medida.

Há limites, claro. A GoodBarber foi construída para apps de conteúdo e comércio móvel; um jogo ou um marketplace fortemente personalizado caem fora desse âmbito, e para esses projetos o caminho mais natural é entregar o protótipo feito em vibe coding a uma equipa de desenvolvimento. Dentro desse âmbito, porém, a abordagem de plataforma é o que transforma a velocidade da IA numa app que consegue publicar — e manter a funcionar ao longo do tempo.

O próximo passo, em concreto:comece um teste gratuito, abra uma secção "Create with AI" e descreva a funcionalidade que fez em vibe coding no fim de semana passado. Os mesmos cinco minutos. Desta vez, o resultado tem um pipeline de lojas por trás.

É possível publicar uma app feita em vibe coding na App Store?

Não diretamente, na maioria dos casos. O Lovable e o v0 produzem aplicações web — não há binário iOS ou Android para submeter. Embrulhar a app web num invólucro nativo é possível, mas a Guideline 4.2 da Apple rejeita apps que se resumem a «um site reempacotado». O Bolt consegue gerar código React Native via Expo, mas as builds, as contas de programador e a revisão das lojas ficam por sua conta. Os caminhos fiáveis são: contratar programadores para levar o código até produção, ou reconstruir numa plataforma que compila binários nativos e trata da submissão. Para a análise completa do lado móvel, veja o que as ferramentas de vibe coding se esquecem de lhe contar sobre apps móveis.

O vibe coding está pronto para produção?

Para protótipos, ferramentas internas e projetos de fim de semana — sim, e é excelente nisso. Para apps de produção com utilizadores reais, a resposta ponderada é: não sem revisão de engenharia. O código gerado por IA introduz vulnerabilidades de segurança em 45% das tarefas testadas (Veracode, 2025), e um benchmark académico concluiu que as soluções do seu melhor agente eram funcionalmente corretas 61% das vezes, mas seguras apenas 10,5% das vezes (arXiv, dezembro de 2025). Estar pronto para produção não é uma questão de o código correr — é alojamento, dados, revisão de segurança, submissão às lojas, funcionalidades nativas, estabilidade do código e conformidade: os sete muros do vibe coding.

O que é o regeneration drift no vibe coding?

O regeneration drift — a deriva da regeneração — é o que acontece quando cada novo prompt regenera o código contra um contexto ligeiramente diferente, e a correção de ontem pode desaparecer discretamente na geração de hoje. Addy Osmani chama ao ciclo resultante o padrão dos «dois passos atrás»; a análise da GitClear a 211 milhões de linhas de código alteradas mediu a sua pegada — blocos de código duplicado multiplicados por 8 em 2024. É a principal razão pela qual uma app feita em vibe coding se torna mais difícil de manter quanto mais prompts recebe.

A Apple baniu as apps de vibe coding?

Não — e a distinção importa. Em março de 2026, a Apple bloqueou atualizações às apps das plataformas de vibe coding como o Replit e o Vibecode, ao abrigo da Guideline 2.5.2, que proíbe apps que descarregam e executam código. Isso visa as ferramentas enquanto apps iOS, não as apps construídas com IA. A Apple disse ao MacRumors que não tem regras específicas contra apps de vibe coding. Uma app individual construída com IA enfrenta a fasquia habitual: funcionalidade mínima (4.2), spam (4.3) e completude — a mesma revisão que todas as apps enfrentam.

Quando é que se deve trocar um protótipo de vibe coding por um app builder?

No momento em que o protótipo tem de se tornar a ferramenta diária de alguém: utilizadores reais, presença nas lojas, atualizações, um backend que persiste. É um limiar de responsabilidade, não de competência — no dia em que outras pessoas dependem da app, alguém tem de responder pelos seus sete muros. Guarde o protótipo; ele cumpriu a missão de validar a ideia. Depois reconstrua-o onde esses muros já são o trabalho de outra pessoa — binários nativos, submissão às lojas, alojamento e manutenção incluídos. Como disse o nosso CMO, o vibe coding serve um público especializado; um app builder é feito para toda a gente.

Quanto custa, afinal, publicar nas lojas?

Uma conta Apple Developer custa $99/ano; uma conta de programador do Google Play é um pagamento único de $25. Depois vem o custo real: preparar as builds, as capturas de ecrã e as declarações de privacidade — e sobreviver à revisão: a Apple rejeita cerca de 42% das primeiras submissões (linha de base da Apple, medida nas apps que a nossa equipa de publicação submeteu nos últimos 12 meses). O nosso guia de publicação passo a passo cobre o processo, e o nosso serviço de publicação trata dele por si.