Supabase — ловушка вайб-кодинга Image: AI generated

Магия тридцати секунд

«Сделай мне бэкенд.» ИИ рекомендует Supabase. Один URL — и вы получаете PostgreSQL, аутентификацию, хранилище и подписки в реальном времени. За 30 секунд логин уже работает. За 2 минуты CRUD готов.

Три месяца спустя никто не знает, кто написал эту политику RLS (Row Level Security).

Почему ИИ рекомендует его

Supabase стал выбором по умолчанию для вайб-кодинга не из-за технического превосходства. А потому что в обучающих данных слишком много туториалов о нём.

Cursor, Bolt, v0, Lovable — какой бы инструмент AI-кодинга вы ни использовали, напишите «сделай мне бэкенд» — и получите Supabase. ИИ рекомендует паттерн, который видел чаще всего. Не лучший паттерн.

Zhang et al. (ACL 2025) показали, что 7 LLM систематически отдают предпочтение определённым провайдерам без явных инструкций и автономно модифицируют код, вставляя предпочтительного провайдера. Пользователь верит, что рекомендованное ИИ — это лучшее. ИИ рекомендует то, что чаще всего встречается в обучающих данных. Это инфраструктурная версия предвзятости угодничества.

Когда логика прячется в чёрном ящике

Настоящая проблема Supabase — не сам Supabase. Проблема в том, что бизнес-логика уходит внутрь чёрного ящика.

1. Политики RLS = скрытая бизнес-логика

Row Level Security — мощный инструмент. Проблема в том: когда ИИ создаёт политики RLS, где они живут?

  • Не в коде. В панели управления Supabase.
  • Не в git. Нет версионирования.
  • Не в тестах. Нельзя проверить в CI.

Ответа на вопрос «кто может обращаться к этой таблице?» нет в кодовой базе. Нужно войти в консоль Supabase, чтобы проверить. Агент не может это прочитать.

Если ИИ изменит политики RLS ради «наведения порядка»? Аутентификация сломается. Тестов нет — никто не знает. Обнаружится только после того, как данные клиентов утекут на продакшене.

Это не гипотеза. В 2025 году CVE-2025-48757 показал, что более 170 приложений, созданных Lovable, полностью раскрыли базы данных Supabase из-за отсутствующих политик RLS. 303 уязвимые конечные точки, утечка email-адресов, ключей API и платёжных данных. В январе 2026 года ИИ-социальная сеть Moltbook была запущена с отключённым RLS, что привело к раскрытию 1,5 млн API-токенов и 35 000 email-адресов.

2. Edge Functions = второй чёрный ящик

Бизнес-логика живёт в двух местах: в коде фронтенда и в Supabase Edge Functions. ИИ должен решать, какая логика где находится. И ИИ ошибается в этом решении.

Расчёт скидки при оплате — в Edge Function. ИИ рефакторит фронтенд и заново создаёт тот же расчёт там. Теперь скидка применяется дважды. Обнаруживается через 3 недели в отчёте о продажах.

3. Миграция = стоимость выхода

Чтобы уйти из Supabase, нужно одновременно демонтировать четыре вещи:

  1. Auth — структура JWT, привязанная к Supabase Auth, колбэки OAuth, управление сессиями
  2. Storage — структура бакетов, политики доступа, подпись URL
  3. Realtime — подписки WebSocket, каналы Presence
  4. Политики RLS — все незадокументированные бизнес-правила

Каждая из них кажется работой на один день, но все четыре переплетены между собой. Изменение Auth ломает RLS, поломка RLS открывает доступ к Storage, изменение URL Storage ломает фронтенд.

Это и есть vendor lock-in. Войти — 30 секунд. Выйти — 3 месяца.

Облачная версия ада портов

Ад портов, который вайб-кодер переживает локально — ИИ запускает сервер, не останавливает его, порты путаются, никто не знает, что работает — в Supabase это поднимается на уровень инфраструктуры.

Локальный ад портов: процессы невидимы. Ад Supabase: бизнес-логика невидима.

Оба имеют одну структуру. То, что создал агент, агент не может отследить.

Какова альтернатива?

Речь не о том, чтобы не использовать Supabase. Речь о том, чтобы не класть бизнес-логику в чёрный ящик.

Принцип: каждое решение должно жить в кодовой базе.

  • Правила аутентификации → объявлены в коде, проверены тестами
  • Политики доступа → объявлены с DDL + Rego, проверены в CI
  • Бизнес-логика → существует в одном месте, без дублирования
  • Конфигурация инфраструктуры → объявлена с Terraform/IaC, версионирована в git

Использовать Supabase для прототипирования — разумно. Но в тот момент, когда прототип переходит на продакшен, нужно вытащить логику из чёрного ящика и перенести её в декларативный слой.

Чтобы магия 30 секунд не превратилась в 3 месяца боли.

Ваши политики RLS есть в git?

Ваши Edge Functions покрыты тестами?

Вы уверены, что «cleanup» от ИИ не сломает аутентификацию?

Supabase не проблема. Проблема — прятать решения в невидимых местах.

Похожие статьи

Источники

  • 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