Supabase é a armadilha do vibe coding Image: AI generated

A mágica dos 30 segundos

“Cria um backend pra mim.” A IA recomenda Supabase. Com uma URL você tem PostgreSQL, autenticação, armazenamento e assinaturas em tempo real. Em 30 segundos o login já funciona. Em 2 minutos o CRUD está completo.

Três meses depois, ninguém sabe quem escreveu aquela política de RLS (Row Level Security).

Por que a IA recomenda

Supabase não se tornou a escolha padrão do vibe coding por superioridade técnica. É porque os dados de treinamento têm muitos tutoriais sobre ele.

Cursor, Bolt, v0, Lovable — qualquer ferramenta de programação com IA que você usar, ao digitar “cria um backend pra mim”, o resultado é Supabase. A IA recomenda o padrão que mais viu. Não o melhor padrão.

Zhang et al. (ACL 2025) demonstraram que 7 LLMs favorecem sistematicamente certos provedores sem instruções explícitas e modificam o código de forma autônoma para inserir o provedor preferido. O usuário acredita que o que a IA recomendou é o melhor. A IA recomenda o que aparece com mais frequência nos dados de treinamento. Esta é a versão de infraestrutura do viés de adulação.

Quando a lógica se esconde na caixa-preta

O verdadeiro problema do Supabase não é o Supabase em si. O problema é que a lógica de negócio entra dentro da caixa-preta.

1. Políticas RLS = lógica de negócio escondida

Row Level Security é uma funcionalidade poderosa. O problema é: quando a IA cria políticas RLS, onde elas ficam?

  • Não estão no código. Estão no painel do Supabase.
  • Não estão no git. Sem controle de versão.
  • Não estão nos testes. Sem validação no CI.

A resposta para “quem pode acessar esta tabela?” não existe na base de código. É preciso fazer login no console do Supabase para verificar. O agente não consegue ler isso.

Se a IA modificar políticas RLS para “organizar”? A autenticação quebra. Sem testes, ninguém sabe. Só se descobre depois que dados de clientes são expostos em produção.

Isso não é hipótese. Em 2025, o CVE-2025-48757 revelou que mais de 170 aplicativos gerados pelo Lovable tiveram todo o banco de dados Supabase exposto por falta de RLS. 303 endpoints vulneráveis, vazamento de e-mails, chaves de API e informações de pagamento. Em janeiro de 2026, a rede social de IA Moltbook foi publicada com RLS desativado, expondo 1,5 milhão de tokens de API e 35.000 e-mails.

2. Edge Functions = segunda caixa-preta

A lógica de negócio vive em dois lugares: no código do frontend e nas Supabase Edge Functions. A IA precisa decidir qual lógica vai onde. E a IA erra nessa decisão.

O cálculo de desconto de pagamento está na Edge Function. A IA refatora o frontend e recria o mesmo cálculo nele. Agora o desconto é aplicado duas vezes. Descoberto três semanas depois no relatório de vendas.

3. Migração = custo de saída

Para sair do Supabase, você precisa desmontar quatro coisas ao mesmo tempo:

  1. Auth — estrutura JWT presa ao Supabase Auth, callbacks OAuth, gerenciamento de sessão
  2. Storage — estrutura de buckets, políticas de acesso, assinatura de URLs
  3. Realtime — assinaturas WebSocket, canais Presence
  4. Políticas RLS — todas as regras de negócio não documentadas

Cada uma parece ser um trabalho de um dia, mas as quatro estão entrelaçadas. Mudar o Auth quebra o RLS, quebrar o RLS abre o acesso ao Storage, mudar a URL do Storage quebra o frontend.

Isso é vendor lock-in. Entrar leva 30 segundos. Sair leva 3 meses.

A versão cloud do inferno de portas

O inferno de portas que o vibe coder enfrenta localmente — a IA sobe um servidor, não o derruba, as portas se confundem, ninguém sabe o que está rodando — isso escala no Supabase para o nível de infraestrutura.

Inferno de portas local: os processos são invisíveis. Inferno do Supabase: a lógica de negócio é invisível.

As duas têm a mesma estrutura. O que o agente criou, o agente não consegue rastrear.

Qual é a alternativa?

Não se está dizendo para não usar Supabase. Está se dizendo para não colocar a lógica de negócio em uma caixa-preta.

Princípio: toda decisão precisa viver na base de código.

  • Regras de autenticação → declaradas em código, validadas por testes
  • Políticas de acesso → declaradas com DDL + Rego, validadas no CI
  • Lógica de negócio → existe em um único lugar, sem duplicação
  • Configuração de infraestrutura → declarada com Terraform/IaC, versionada no git

Usar Supabase para prototipagem é razoável. Mas no momento em que o protótipo vai para produção, é preciso tirar a lógica de dentro da caixa-preta e movê-la para uma camada declarativa.

Para não transformar a mágica de 30 segundos em 3 meses de sofrimento.

Suas políticas RLS estão no git?

Suas Edge Functions têm testes?

Você tem certeza de que o “cleanup” da IA não vai quebrar a autenticação?

Supabase não é o problema. O problema é esconder decisões em lugares invisíveis.

Artigos relacionados

Fontes

  • Zhang, Y. et al. (2025). “The Invisible Hand: Unveiling Provider Bias in Large Language Models for Code Generation.” ACL 2025. arxiv.org/abs/2501.07849
  • CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
  • OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 + 35K 이메일 노출. blog.ogwilliam.com
  • Willison, S. (2025). “Supabase MCP can leak your entire SQL database.” simonwillison.net
  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106
  • Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev