Vibe Coding: Como Ligar a Tua App de IA a uma Base de Dados Real Sem Deixar Dados de Clientes Expostos (2026)

A maior parte dos tutoriais de “vibe coding” para no mesmo sítio: o prompt que gera a app. Mostram o ecrã bonito a nascer em trinta segundos e ficam por aí.

O que quase nenhum mostra é o que acontece a seguir com vibe coding: quando essa app precisa de guardar dados reais, de utilizadores a sério, e a IA que a construiu começa a “corrigir” um erro criando três novos. É aí que a maioria dos projetos feitos em Lovable, Bolt.new ou ferramentas semelhantes se perde. Não é falta de talento de quem escreveu o prompt; é um passo que ninguém avisou que existia. Este artigo mostra precisamente como ligar Lovable ou Bolt.new a uma base de dados real sem cometer esse erro.

Este artigo assume que já tens uma app publicada. Se ainda não, o tutorial passo a passo para criar e publicar a tua primeira app cobre isso do zero. Também não é mais uma comparação entre ferramentas: já temos essa conversa nos artigos v0 vs Bolt.new e Cursor vs GitHub Copilot vs Devin Desktop. Este chega à parte que ninguém documenta bem: pôr a app a funcionar com dados reais, em produção, sem abrir uma porta que não devia estar aberta.

Nota de transparência: os números abaixo foram cruzados com a documentação oficial da Supabase e da Lovable e com uma segunda auditoria independente, para não depender de uma única fonte. Onde não encontrámos confirmação independente, dizemos isso claramente em vez de apresentar como facto.

Resposta rápida sobre vibe coding

• O erro mais caro não é visual, é de segurança: quando uma tabela do Supabase é criada por migração SQL (o método que ferramentas de IA usam por defeito) em vez de pelo painel visual, a proteção de acesso aos dados (RLS) fica desligada até alguém a ativar à mão. Isto está confirmado na própria documentação da Supabase.
• Isto já foi medido em apps reais, não é só teoria: duas análises independentes, com métodos diferentes, chegaram ao mesmo número: 89% das apps Lovable auditadas tinham RLS desativado em pelo menos uma tabela com dados de utilizador.
• O loop “Tenta Corrigir” é real e está por resolver: é um problema reportado pelos próprios utilizadores no canal oficial de feedback da Lovable, sem confirmação pública de correção. A própria documentação da Lovable recomenda reverter para uma versão anterior em vez de insistir.

O erro mais caro do “vibe coding”: a base de dados sem proteção

Lovable e Bolt.new resolvem o backend por ti ligando o projeto a um Supabase (ou Firebase) criado automaticamente. É rápido e é também onde a maior parte dos problemas sérios nasce. Uma base de dados do Supabase tem uma proteção chamada Row Level Security (RLS): sem ela ativada e configurada, qualquer pessoa com a URL da API consegue ler ou escrever nos dados de qualquer utilizador, não só nos seus.

Há uma nuance importante que a maior parte dos tutoriais ignora: segundo a própria documentação da Supabase, o RLS só fica ativado por defeito quando a tabela é criada através do painel visual (Table Editor). Tabelas criadas por SQL (que é exatamente como a IA cria tabelas quando gera uma app) ficam sem RLS até alguém o ativar manualmente. Não é um bug da IA; é o comportamento normal do Postgres, só que ninguém avisa quem nunca configurou uma base de dados antes.

Isto deixou de ser só uma afirmação de um blog: cruzámos a fonte original (AppStuck) com uma auditoria independente publicada na DEV Community, feita por outra pessoa, com outro método (análise direta de 50 repositórios de apps Lovable reais, já publicadas), e o número de apps sem RLS bate certo nas duas: 89%.

A mesma auditoria encontrou ainda a chave service_role exposta no código do lado do cliente em 34% dos casos: uma chave que, segundo a documentação da própria Supabase, “nunca deve aparecer num browser” porque ignora todas as regras de RLS por definição (tem o atributo BYPASSRLS).

O que não conseguimos confirmar de forma independente: a afirmação específica de que o ambiente de pré-visualização da Lovable usa essa chave service_role internamente (o que explicaria porque tudo “parece funcionar” antes de publicares). Encontrámos essa afirmação numa única fonte e não numa segunda fonte independente, por isso preferimos não repeti-la como facto confirmado.

O que está confirmado, e chega para o mesmo aviso prático: testar só na pré-visualização não garante nada sobre o estado real do RLS, porque a tabela pode simplesmente nunca ter tido RLS ativado desde que foi criada por SQL.

Checklist vibe coding: ligar Lovable ou Bolt.new a uma base de dados real, sem deixar a porta aberta

1. Confirma manualmente que RLS está ativo em todas as tabelas, tabela a tabela. No painel do Supabase, cada tabela tem um interruptor de “Row Level Security”. Não presumas que está ativo só porque a app funciona: confirma no painel, não no comportamento aparente.
2. Escreve pelo menos uma policy mínima por tabela (ex.: “o utilizador só vê linhas onde user_id é igual ao seu ID”) antes de a app sair da fase de testes.
3. Nunca coloques a chave service_role em variáveis com prefixo VITE_ ou NEXT_PUBLIC_. Esse prefixo diz ao Vite/Next para incluir o valor no código enviado ao browser. Essa chave ignora RLS por completo. Fica sempre do lado do servidor (Edge Functions, por exemplo).
4. Copia as variáveis de ambiente para o ambiente de produção, não só para o de testes. Chaves de API, URLs de callback e segredos configurados durante o desenvolvimento raramente passam automaticamente para o deploy final.
5. Atualiza URLs de OAuth e de webhooks para o domínio definitivo. Um login que entra em loop (autentica e volta logo para o ecrã de login) é quase sempre um provider OAuth ou o Supabase Auth ainda a apontar para o domínio de desenvolvimento.
6. Usa um projeto Supabase separado para produção. Misturar dados de teste com dados reais no mesmo projeto é como deixares as chaves de casa dentro da fechadura: funciona até não funcionar.

O loop “Tenta Corrigir”: porque pedir à IA para arranjar o erro cria três novos

Há um padrão que quem já usou Lovable ou Bolt.new durante mais de uma tarde conhece bem: um erro aparece, pedes à IA para corrigir, ela “corrige”, e o erro seguinte é diferente, mas pior. Este não é um problema inventado por um blog: há um pedido de feedback público no canal oficial da Lovable exatamente sobre isto, de um utilizador que descreve ter gasto num dia créditos equivalentes a um mês, com o agente a resolver só um problema de cada vez e a não conseguir sair do ciclo sozinho. Até à data desta verificação, não há resposta oficial a confirmar uma correção, só uma resposta genérica sobre “melhorar o prompting”, que o próprio utilizador considerou insuficiente.

A parte boa: a documentação oficial de troubleshooting da Lovable já recomenda, por escrito, exatamente o que costuma funcionar melhor do que insistir:

• Investiga antes de pedires outra correção. A documentação sugere pedir à Lovable para “investigar” (inspecionar erros, logs e consola) em vez de simplesmente carregar outra vez em “Tenta Corrigir”.
• Reverte para a versão anterior à falha. É a própria Lovable que recomenda “voltar à versão imediatamente antes do problema aparecer, através do histórico de versões”, em vez de corrigir por cima de correções.
• Usa o modo Plano para pedidos complexos. Pedir à IA para esboçar a abordagem antes de construir, rever esse plano, e só depois avançar passo a passo.
• Sabe que só tens correções gratuitas limitadas. A conta inclui 10 correções gratuitas partilhadas entre “Tenta Corrigir” e a vista de Segurança; depois disso, cada tentativa consome créditos como qualquer mensagem normal, mais uma razão para reverter cedo em vez de insistir.
• Descreve o erro real, não o sintoma. Copia a mensagem de erro exata da consola, não “não está a funcionar”. É o mesmo princípio que já explicámos no artigo sobre prompts de ancoragem.

Isto substitui um programador para vibe coding?

Para um protótipo, um MVP para validar uma ideia ou uma ferramenta interna sem dados sensíveis, não. É exatamente para isso que Lovable e Bolt.new foram pensados. Mas assim que a app passa a guardar dados de clientes reais, pagamentos ou informação que não podes dar-te ao luxo de expor, vale a pena teres alguém que saiba o que é uma policy de RLS a rever o projeto antes de ele ir ao ar, não depois de um incidente. Se sentires que precisas de mais controlo sobre a arquitetura do que estas ferramentas dão, o passo seguinte natural é um editor como o Cursor, onde tens o código todo à vista e a decisão final é sempre tua.

Perguntas Frequentes sobre vibe coding

O Lovable e o Bolt.new são seguros para dados de clientes?

Podem ser, mas não por definição. Tabelas criadas por SQL (o método que a IA usa) não ficam com RLS ativo automaticamente. Confirma sempre manualmente no painel do Supabase, tabela a tabela, antes de publicares.

Preciso de saber programar para corrigir estes erros?

Não para os passos básicos (ativar RLS num interruptor, copiar variáveis de ambiente, atualizar uma URL). Mas perceberes minimamente o que é uma policy de base de dados ajuda a reconhecer quando algo está mal configurado antes de se tornar um problema real.

É verdade que a pré-visualização da Lovable ignora as regras de segurança?

Não conseguimos confirmar essa afirmação específica em mais do que uma fonte, por isso não a apresentamos como facto. O que está confirmado é que testar só na pré-visualização não garante nada sobre o RLS. A única forma fiável é confirmares o estado de cada tabela diretamente no painel do Supabase.

Quando devo passar de uma ferramenta de vibe coding para um editor como o Cursor?

Quando o projeto cresce ao ponto de precisares de controlar a arquitetura, otimizar performance ou lidar com lógica de negócio complexa que um prompt já não descreve bem. Para muitos projetos pequenos e médios, isso nunca chega a acontecer.

Se ainda não escolheste ferramenta, os artigos v0 vs Bolt.new e as reviews completas de Lovable e Bolt.new ajudam a decidir por onde começar. Guarda este artigo sempre que precisares de confirmar os passos para ligar Lovable ou Bolt.new a uma base de dados real antes de publicares. Este artigo fica para quando chegares à parte que ninguém mostra no vídeo de trinta segundos.