Remix + Supabase: ИИ-fullstack 2026

Вайб-кодинг в 2026 году — это уже не про «поиграться с ChatGPT», а про осознанную fullstack-архитектуру, где ИИ встроен в инженерный процесс. В этой статье разберу конкретный кейс: как мы строим Remix + Supabase архитектуру с ИИ-планированием через GitHub, Cursor и preview-ветки. Без теории ради теории — только паттерны, которые реально работают на проде. Это тот самый вайб, когда ты контролируешь систему, а не она тебя. 🚀

Почему Remix + Supabase — дефолт fullstack стека 2026

Remix за последние два года сильно изменился. После фактического слияния с React Router v7 он стал не «альтернативой Next.js», а архитектурной базой для data-first приложений. Рекомендую пролистать Remix Blog за 2025 год — там хорошо видно, как фреймворк движется к RSC, middleware и чёткому серверному контролю.

Supabase в этой связке важен по другой причине: это Postgres-first платформа. Никакого NoSQL магического мышления — ядро это Postgres с полным доступом и RLS. Официально это подтверждено в документации Supabase: вся архитектура строится вокруг SQL, JWT и изоляции сервисов.

Архитектура проекта: один репозиторий, много сред

Базовый паттерн, который мы используем:

• Monorepo или один репозиторий с Remix-приложением
• Директория supabase/, созданная через supabase init
• Все изменения БД — только через SQL-миграции

Ключевой момент: GitHub интеграция Supabase. Она позволяет синхронизировать каждую ветку репозитория с отдельным Supabase preview-проектом. Это описано в официальном гайде, но на практике ощущается как магия: создал feature-ветку — получил чистую БД с миграциями и seed-данными.

ИИ-планирование: как Cursor становится инженерным агентом

Теперь самое интересное. Мы используем Cursor не как «автодополнение», а как агента планирования. Паттерн такой:

1. Я пишу issue в GitHub с чётким описанием фичи
2. Скармливаю issue Cursor и прошу разбить на миграции, loader/action в Remix и Edge Functions
3. Cursor генерирует план из коммитов

Важно: ИИ не пишет всё сам. Он предлагает скелет, а я проверяю RLS, границы ответственности и data-flow. Это и есть вайб-кодинг: ты в режиме архитектора, а не машинистки.

Supabase миграции как контракт

Все изменения БД — через миграции формата YYYYMMDDHHmmss_description.sql. Мы сразу включаем RLS и пишем политики гранулярно: select, insert, update, delete для anon и authenticated. Это прямо рекомендуется Supabase и экономит часы отладки.

 alter table profiles enable row level security;
 create policy "users read own profile"
 on profiles for select
 using (auth.uid() = user_id);

Каждая PR-ветка получает свою preview БД, seed.sql заливает тестовые данные, и мы не боимся экспериментировать. Это идеально ложится на ИИ-подход: можно смело пробовать, зная, что прод изолирован.

Edge Functions и AI-фичи

Для AI-функций мы используем Supabase Edge Functions на Deno. Тут есть чёткие правила: использовать Web APIs, fetch вместо axios, никаких лишних зависимостей. Официальные рекомендации есть в гайде Supabase.

Для semantic search и RAG используем pgvector. Supabase уже даёт готовый toolkit для AI-приложений, и кейсы типа Firecrawl и Markprompt показывают, что Postgres спокойно заменяет Pinecone.

Remix data-flow поверх Supabase

В Remix мы держим жёсткий паттерн: loader — только чтение, action — мутации. Supabase клиент инициализируется на сервере, JWT прилетает из cookies, RLS делает всю работу. Никаких лишних API-слоёв.

Выводы

Remix + Supabase в 2026 году — это не просто стек, а инженерная система. GitHub-ветки как среды, миграции как контракт, RLS как безопасность по умолчанию и ИИ как планировщик, а не волшебная палочка. Если ты middle+ разработчик и хочешь масштабироваться без выгорания, этот подход стоит попробовать. Он даёт редкое ощущение контроля и спокойствия в fullstack-разработке. И да, это очень приятный вайб. 😌