Supabase Es una Trampa del Vibe Coding Image: AI generated

La Magia de los 30 Segundos

“Hazme un backend.” La IA recomienda Supabase. Con una sola URL obtienes PostgreSQL, autenticación, almacenamiento y suscripciones en tiempo real. El login funciona en 30 segundos. El CRUD está listo en 2 minutos.

Tres meses después, nadie sabe quién escribió esas políticas de RLS (Row Level Security).

Por Qué la IA Lo Recomienda

Supabase se convirtió en la opción predeterminada del vibe coding no por superioridad técnica. Es porque los tutoriales dominan los datos de entrenamiento.

Cursor, Bolt, v0, Lovable — escribe “hazme un backend” en cualquier herramienta de programación con IA y aparece Supabase. La IA recomienda el patrón que ha visto con mayor frecuencia. No el mejor patrón.

Zhang et al. (ACL 2025) demostraron que 7 LLMs favorecen sistemáticamente a proveedores específicos sin instrucción explícita, y modifican de forma autónoma el código de entrada para insertar a los proveedores preferidos. Los usuarios creen que lo que recomienda la IA es lo mejor. La IA recomienda lo que aparece con más frecuencia en los datos de entrenamiento. Esta es la versión de infraestructura del sesgo de adulación.

Cuando Ocultas Lógica en una Caja Negra

El verdadero problema de Supabase no es Supabase en sí. El problema es que la lógica de negocio entra en una caja negra.

1. Políticas RLS = Lógica de Negocio Oculta

Row Level Security es una función poderosa. El problema es: cuando la IA genera políticas RLS, ¿dónde viven?

  • No en el código. Están en el panel de Supabase.
  • No en git. Sin control de versiones.
  • No en los tests. Sin validación en CI.

La respuesta a “¿quién puede acceder a esta tabla?” no existe en el codebase. Tienes que iniciar sesión en la consola de Supabase para averiguarlo. Los agentes no pueden leer esto.

¿Si la IA modifica políticas RLS durante una “limpieza”? La autenticación se rompe. Sin tests, nadie lo nota. Se descubre después de que los datos de clientes quedan expuestos en producción.

Esto no es una hipótesis. En CVE-2025-48757, más de 170 aplicaciones generadas por Lovable tuvieron sus bases de datos de Supabase completamente expuestas por falta de RLS. 303 endpoints vulnerables filtraron correos electrónicos, claves API e información de pago. En enero de 2026, la red social de IA Moltbook se desplegó con RLS desactivado, exponiendo 1,5 millones de tokens API y 35.000 correos electrónicos.

2. Edge Functions = La Segunda Caja Negra

La lógica de negocio vive en dos lugares: el código del frontend y las Supabase Edge Functions. La IA tiene que decidir qué lógica va dónde. La IA se equivoca en ese juicio.

Un cálculo de descuento de pagos vive en una Edge Function. La IA refactoriza el frontend y recrea el mismo cálculo allí. Ahora el descuento se aplica dos veces. Se descubre en el informe de ingresos 3 semanas después.

3. Migración = El Coste de Salida

Abandonar Supabase requiere desmantelar cuatro cosas simultáneamente:

  1. Auth — estructura JWT atada a Supabase Auth, callbacks de OAuth, gestión de sesiones
  2. Storage — estructura de buckets, políticas de acceso, firma de URLs
  3. Realtime — suscripciones WebSocket, canales Presence
  4. Políticas RLS — todas las reglas de negocio no documentadas

Cada una parece un trabajo de un día, pero las cuatro están entrelazadas. Cambia Auth y RLS se rompe. RLS se rompe y el acceso a Storage queda abierto. Las URLs de Storage cambian y el frontend se rompe.

Esto es vendor lock-in. Entrar toma 30 segundos. Salir toma 3 meses.

La Versión Cloud del Infierno de los Puertos

El infierno de puertos que sufren los vibe coders en local — la IA levanta servidores, no los mata, los puertos se lían, nadie sabe qué está corriendo — esto sube al nivel de infraestructura con Supabase.

Infierno local de puertos: los procesos son invisibles. Infierno de Supabase: la lógica de negocio es invisible.

Ambos tienen la misma estructura. Lo que los agentes crean, los agentes no pueden rastrear.

¿Cuál Es la Alternativa?

No se trata de dejar de usar Supabase. Se trata de no poner la lógica de negocio en una caja negra.

Principio: cada decisión debe vivir en el codebase.

  • Reglas de autenticación → declaradas en código, validadas con tests
  • Políticas de acceso → declaradas con DDL + Rego, validadas en CI
  • Lógica de negocio → existe en un único lugar, sin duplicación
  • Configuración de infraestructura → declarada con Terraform/IaC, versionada en git

Usar Supabase para prototipar es razonable. Pero en el momento en que llevas un prototipo a producción, debes extraer la lógica de la caja negra y moverla a una capa declarativa.

Para que los 30 segundos de magia no se conviertan en 3 meses de dolor.

¿Está tu política RLS en git?

¿Tus Edge Functions tienen tests?

¿Estás seguro de que una “limpieza” de la IA no romperá la autenticación?

Supabase no es el problema. Ocultar decisiones donde no se pueden ver es el problema.

Artículos Relacionados

Fuentes

  • 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-generated 170+ apps exposed entire Supabase DBs due to missing RLS. ameeba.com
  • OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API tokens + 35K emails exposed. 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