🎯 О чём этот конспект: Пошаговое руководство по созданию масштабируемого production-ready SaaS-продукта (Marshall Desk — аналог Intercom с чат-виджетом, RAG-пайплайном, real-time обменом сообщениями через WebSockets и мультиагентной маршрутизацией). Разбирается инженерный подход к вайбкодингу: от составления PRD и выбора моделей до трехуровневого код-ревью и деплоя через MCP-серверы.

👤 Кому будет полезно: Вайбкодерам, AI-инженерам и соло-фаундерам, создающим сложные full-stack веб-сервисы с помощью Cursor, Claude Code, Next.js, Neon Postgres и PartyKit.

✨ Что получите: Готовую методологию создания сложных приложений с ИИ без спагетти-кода: двухсессионный рабочий процесс, конфигурации MCP-серверов, оптимизированные системные промпты, архитектуру real-time RAG на serverless-функциях и стратегию валидации кода.

1. Декомпозиция сложных SaaS: почему наивный вайбкодинг терпит крах

Контекст: Наивный промпт вроде «Создай клон Intercom» генерирует красивую, но неработоспособную визуальную обертку. За видимой простотой чат-виджета скрывается многоуровневая инфраструктура: real-time доставка сообщений с синхронизацией стейта, многоарендная архитектура (multi-tenancy) с изоляцией данных компаний, RAG-пайплайн для парсинга, чанкинга и векторного поиска по документам бизнеса, а также фоновые задачи и надежная аутентификация. Стартовать проект нужно не с генерации случайных файлов, а с декомпозиции и строгой фиксации скоупа V1.

Тайминг: ▶ 00:08, ▶ 01:25, ▶ 14:00

Выгода: Предотвращает бесконечный цикл правок и генерацию тысяч строк мусорного кода; экономит недели разработки и сотни долларов на бесполезных вызовах LLM.

Как применить:

• Шаг 1: Фиксация жесткого скоупа V1 — Отсеките функционал второго эшелона (биллинг, мобильные клиенты, туры по продукту, тикет-системы email). Оставьте только ядро: встраиваемый iframe-виджет, дашборд оператора, real-time чат, AI-ответы по загруженным базам знаний и передачу диалога человеку (human handoff).
• Шаг 2: Формирование списка анти-фич — Прямо зафиксируйте для агента список того, что строить запрещено, чтобы исключить самовольное усложнение кодовой базы.

### Скоуп V1:
- Встраиваемый изолированный виджет (iframe) для любого сайта
- Real-time обмен сообщениями между клиентом и оператором
- База знаний (загрузка PDF, Markdown, TXT)
- Векторный RAG-пайплайн с классификацией интентов
- Автоматическая и ручная передача диалога человеку
- Мультиарендный дашборд оператора (Multi-tenancy)
 
### НЕ строим в V1:
- Email-рассылки и тикетинг
- Мобильные приложения (React Native/Flutter)
- Биллинг и тарифные сетки (Stripe)
- Справочный центр (Help Center)

Результат: Четко очерченные границы проекта, исключающие дрейф требований (scope creep) при генерации кода агентом.

2. Настройка среды разработки (ADE) и оптимизация контекста через навыки (Skills)

Контекст: Выбор инструмента (Cursor, Codex, Claude Code) вторичен по сравнению с удобством работы, но среда обязательно должна иметь доступ к встроенному браузеру или инструменту типа browser-use для автономной верификации интерфейса. Критическая ошибка разработчиков — установка сотен навыков (skills), что перегружает контекстное окно, сжигает токены и сбивает планировщик агента. Оптимальный лимит — не более 100 профильных навыков в проекте.

Тайминг: ▶ 06:21, ▶ 08:11, ▶ 12:20

Выгода: Экономия до 40% токенов контекстного окна, исключение ложных срабатываний инструментов и повышение точности генерации кода.

Как применить:

• Шаг 1: Установка базового набора навыков — Добавьте в среду только проверенные навыки для генерации PRD, работы с Shadcn UI, дизайн-инжиниринга и оркестрации фич.
• Шаг 2: Подключение голосового ввода — Используйте Willow, SuperWhisper, Whisper Flow или встроенный в Cursor/Claude Code голосовой ввод для составления развернутых контекстных промптов без трения клавиатуры.

# Ключевые репозитории и навыки для установки:
# 1. Навыки от Matt (grill-with-docs и др.)
# 2. Emil Design Engineering (дизайн-система, анимации без AI-шлака)
# 3. Shadcn UI Skill (актуальная документация по компонентам)
# 4. Writing PRDs by Lenny Skills (генерация продуктовой спецификации)
# 5. Feature Orchestrator (управление двухсессионным пайплайном)

Результат: Сбалансированная среда разработки, понимающая дизайн-паттерны, архитектурные ограничения и принципы работы с компонентами.

3. Проектирование системной архитектуры и выбор стека для AI-агентов

Контекст: Стек технологий для вайбкодинга выбирается исходя из того, на каких данных обучались LLM. Даже если SvelteKit или Rust объективно производительнее, агент напишет более качественный и стабильный код на Next.js (App Router), TypeScript, Prisma/Drizzle и Tailwind CSS из-за огромного объема качественных примеров в обучающей выборке. Вся инфраструктура бэкенда объединяется в рамках одного BaaS (Neon), чтобы избежать склеивания разрозненных сервисов.

Тайминг: ▶ 18:40, ▶ 22:52, ▶ 30:35

Выгода: Минимум синтаксических галлюцинаций LLM, готовая типобезопасность по всей цепочке и нулевая стоимость инфраструктуры на старте благодаря Free Tier.

Как применить:

• Шаг 1: Выбор компонентов инфраструктуры —
  • Фронтенд и Сервер: Next.js 16 (App Router), TypeScript (Strict Mode), Tailwind CSS, Shadcn UI.
  • API-слой: oRPC v2 + TanStack Query (контрактная разработка, типобезопасность, совместимость с OpenAPI).
  • Real-time слой: PartyKit / PartyServer (Durable Objects от Cloudflare) для WebSockets без сторонних SaaS.
  • База данных и BaaS: Neon (Serverless Postgres с расширением pgvector, managed Better Auth, Serverless Functions, S3-совместимое Object Storage и AI Gateway).
  • LLM/Embeddings: Qwen 3 Embedding / OpenAI Embeddings, GPT-4o-mini / GPT-4o через Neon AI Gateway.
• Шаг 2: Создание архитектурной диаграммы — Зафиксируйте схему взаимодействия между виджетом (iframe), сервером Next.js, хранилищем объектов, PartyKit и фоновыми функциями перед составлением PRD.

Результат: Согласованная архитектура, готовая к передаче в контекст Frontier-модели.

4. Генерация PRD и этап жесткого стресс-тестирования (Grilling Session)

Контекст: Файл AGENTS.md задает лишь операционные правила репозитория, но не описывает бизнес-логику и граничные случаи. Попытка писать код по первому сгенерированному черновику спецификации ведет к фатальным предположениям со стороны ИИ. Спецификацию (PRD) необходимо создавать на самой мощной Frontier-модели (Claude 3.5 Sonnet / Opus 3.5 / GPT-4o) с последующим прогоном через навык grill-with-docs (пакетный опрос разработчика агентом до полного устранения неопределенностей).

Тайминг: ▶ 34:42, ▶ 39:20, ▶ 47:20

Выгода: Устранение более 60 скрытых архитектурных и продуктовых несостыковок до написания первой строчки кода.

Как применить:

• Шаг 1: Первичная генерация PRD — Загрузите в чат текстовое описание идеи, скриншот архитектурной схемы и скриншот пользовательских флоу (Flow A: загрузка знаний, Flow B: диалог клиента, Flow C: human handoff).

Я работаю над проектом Marshall Desk — клиентской поддержкой в стиле Intercom с чат-виджетом и AI-агентом.
Ниже прикреплено описание логики, технологический стек и скриншоты системной архитектуры и пользовательских сценариев.
Используй навык writing-prds для создания исчерпывающего PRD.

• Шаг 2: Запуск сессии уточняющих вопросов — Активируйте опрос разработчика пакетами по 10 вопросов для фиксации крайних случаев (таймауты ожидания оператора, форматы файлов, поведение анонимных пользователей, мультиязычность).

Отличный черновик. Теперь используй навык grill-with-docs.
Задавай мне вопросы пакетами, чтобы устранить любые допущения. Задавай столько вопросов, сколько потребуется для 100% ясности.

• Шаг 3: Фиксация глоссария и стека — Убедитесь, что агент сформировал файлы PRD.md, context.md (глоссарий терминов: Workspace, Member, Visitor, Session) и tech-stack.md.

Результат: Детализированный PRD объемом более 600 строк, где определены все контракты данных, модели и поведение системы в нештатных ситуациях.

5. Двухсессионный Multi-Model AI Workflow с субагентами

Контекст: Использование одного чата и одной модели для планирования, кодинга, ресерча и ревью моментально забивает контекстное окно и приводит к деградации логики. Эффективный инженерный воркфлоу разделяет задачи на две изолированные сессии и распределяет роли между специализированными моделями через субагентов.

Тайминг: ▶ 65:20, ▶ 69:10, ▶ 76:10

Выгода: Сохранение чистоты контекста, отсутствие превышения лимитов (rate limits) и снижение затрат на API на 50–70% за счет делегирования рутины быстрым моделям.

Как применить:

• Сессия 1 (Thinking & Scoping):
  • Модель: Claude 3.5 Sonnet / Opus 3.5 (Medium Reasoning).
  • Задача: Игра в «пинг-понг» с агентом, обсуждение фичи, исследование документации быстрыми субагентами-исследователями, декомпозиция крупной фичи на подзадачи (A, B, C, D) и составление финального промпта для реализации.
• Сессия 2 (Execution & Delegation):
  • Lead Orchestrator: Принимает комплексный промпт из Сессии 1, создает субагентов.
  • Implementer (Субагент-исполнитель): Пишет код конкретных модулей параллельно или последовательно.
  • Researcher (Субагент-исследователь): Read-only агент для быстрого поиска по локальной кодовой базе и сети.
  • Reviewer (Субагент-ревьюер): Автономно инспектирует код исполнителей перед финальной сдачей.

# Ролевая матрица моделей:
- Orchestrator (Ведущий): Claude 3.5 Sonnet / Opus 3.5 (Medium reasoning)
- Implementer (Исполнитель): Claude 3.5 Sonnet / Opus 3.5 (Medium reasoning)
- Researcher (Исследователь): Sonnet 3.5 / Fast LLM (Read-only, без права записи)
- Reviewer (Ревьюер): Claude 3.5 Sonnet / Opus 3.5 (Read-only аудит)

Результат: Автономный конвейер разработки, способный реализовывать сквозные фичи из сотен файлов без потери контекста.

6. Принцип «Landing & Design System First»: генерация визуального фундамента

Контекст: Классический подход «сначала бэкенд и логика, потом дизайн» при вайбкодинге приводит к двойной работе: агент создает разрозненные формы авторизации и страницы дашборда с конфликтующими стилями, которые позже приходится переписывать. Создание лендинга на первом шаге формирует файл design.md, цветовую палитру и набор базовых компонентов Shadcn UI, которые затем автоматически наследуются всеми внутренними экранами.

Тайминг: ▶ 82:40, ▶ 85:12, ▶ 103:00

Выгода: Устранение дублирования стилей, сокращение времени сборки последующих UI-экранов в 3 раза, исключение визуального «AI-шлака».

Как применить:

• Шаг 1: Выбор готового промпта для Hero-секции — Возьмите структурированный дизайн-промпт (например, с Motion Sites) и адаптируйте его под стек Next.js + Tailwind + Shadcn UI.
• Шаг 2: Генерация лендинга и фиксация дизайн-системы — Передайте промпт в Claude Code или Cursor с открытым встроенным браузером.
• Шаг 3: Формирование design.md — Зафиксируйте правила оформления (шрифты Geist / Geist Pixel, анимации появления, микро-скейлинг кнопок до 97% при клике, монохромная тема с акцентными индикаторами статуса).

Инструкция для агента:
1. Создай лендинг для Marshall Desk на Next.js 16, Tailwind CSS и Shadcn UI на основе переданного дизайн-промпта.
2. Используй шрифты Geist и Geist Pixel для акцентных заголовков.
3. Проверь результат в реальном браузере на десктопе и мобильном разрешении.
4. Создай файл `design.md`, где опиши правила дизайн-системы, используемые переменные цветов, отступы и правила интерактивных анимаций.

Результат: Готовая продающая посадочная страница и задокументированная дизайн-система design.md, готовая для масштабирования на дашборд и виджет.

7. Инфраструктура бэкенда через Neon BaaS и MCP-сервер

Контекст: Вместо настройки пяти независимых сервисов (БД, Auth, S3, Lambdas, AI Gateway) используется единая платформа Neon. Подключение официального Neon MCP-сервера и набора навыков (Neon Plugin) позволяет агенту напрямую выполнять миграции, управлять ветками базы данных, запрашивать креденшелы и конфигурировать хранилища без ручного входа в веб-консоль.

Тайминг: ▶ 107:15, ▶ 111:40, ▶ 116:20

Выгода: Изоляция окружений через мгновенное ветвление (Branching), нулевая стоимость простоя (Scale-to-zero) и сокращение времени настройки бэкенда до пары минут.

Как применить:

• Шаг 1: Создание проекта в Neon — Активируйте Postgres 18 с pgvector, Object Storage (приватный бакет uploads, публичный бакет profile-images), Serverless Functions, AI Gateway и Managed Better Auth.
• Шаг 2: Подключение Neon MCP в Cursor / Claude Code — Установите плагин Neon из маркетплейса расширений и авторизуйте доступ к проекту.

# Установка и авторизация Neon CLI
npm install -g neonctl
neonctl auth login
 
# В ветке development агент использует dev-базу данных и dev-секреты.
# Ветка production настраивается изолированно при релизе.

• Шаг 3: Настройка мультиарендной схемы данных через Prisma — Создайте общие пакеты @marshall-desk/db для шаринга типов между сервером Next.js и serverless-функциями Neon.

Результат: Полностью автоматизированное управление базой данных и облачной инфраструктурой прямо из IDE через агентские вызовы инструментов.

8. Реализация авторизации, шелла дашборда и защита от дублирования рендеров

Контекст: При верстке страниц входа (/auth/sign-in) и регистрации (/auth/sign-up) агенты часто создают две изолированные страницы с дублированием тяжелых компонентов (фоновые видео, логотипы, карточки). Использование общих Layout-маршрутов (layout.tsx) в Next.js предотвращает лишние ререндеры при клиентских переходах. Вся аутентификация строится на базе managed Better Auth от Neon с поддержкой Google OAuth, Magic Links и классического Email/Password.

Тайминг: ▶ 124:40, ▶ 135:20, ▶ 153:10

Выгода: Бесшовный UX без мигания интерфейса (FOUC), типобезопасная валидация форм через Zod и полная изоляция сессий тенантов.

Как применить:

• Шаг 1: Создание общего Auth Layout — Вынесите статичные элементы (видео-панель, логотип) в app/(auth)/layout.tsx, чтобы при переключении между Sign In и Sign Up перерисовывалась только форма.
• Шаг 2: Установка готовых блоков Shadcn UI — Используйте CLI Shadcn для добавления шаблонов форм авторизации и OTP-ввода.

# Добавление готовых блоков Shadcn UI
npx shadcn@latest add "https://shadcn.com/blocks/login-02"
npx shadcn@latest add input-otp

• Шаг 3: Настройка сессий в навигации — Получайте сессию на клиенте через хук authClient.useSession(), чтобы лендинг оставался статически генерируемым (SSG), а кнопка Sign In автоматически менялась на Dashboard при наличии активной сессии.

Результат: Отказоустойчивая система входа с подтверждением email через OTP, автоматическим созданием Workspace и мгновенным редиректом в рабочий дашборд.

9. Трехуровневая методология код-ревью в эпоху генеративного кода

Контекст: Слияние кода без проверки — главная причина скрытых уязвимостей, утечек памяти и спагетти-архитектуры. Даже продвинутые модели склонны писать избыточные хелперы, злоупотреблять кастами типов (as any), переусложнять обработку ошибок и нарушать DRY. Надежный процесс требует трехуровневого сита валидации.

Тайминг: ▶ 162:40, ▶ 165:30, ▶ 170:00

Выгода: Выявление критических багов безопасности (например, возможность подделки сообщений оператора через prompt injection) до попадания в ветку main.

Как применить:

• Уровень 1: Автономные субагенты-ревьюеры (Внутри сессии) — Модели в режиме read-only построчно инспектируют дифф перед завершением работы оркестратора.
• Уровень 2: Экспресс-аудит инженера — Просмотр списка изменений глазами на предмет семантической чистоты, удаления дублирующихся хелперов и корректного использования Next.js App Router.
• Уровень 3: CI/CD AI-боты на GitHub Actions — Подключение Cursor BugBot, CodeRabbit или PullFrog к Pull Request для автоматического поиска race conditions, утечек состояния и ошибок в CSS.

# Промпт для субагента-ревьюера (Уровень 1):
Проведи аудит сгенерированного кода в режиме read-only.
Проверь:
1. Отсутствие избыточных хелперов и функций-оберток, дублирующих существующие утилиты.
2. Корректность обработки ошибок через типизированные исключения oRPC (без any/unknown).
3. Соблюдение принципа DRY и отсутствие утечек состояния в TanStack Query.
4. Безопасность входных данных в серверных процедурах.

Результат: Чистая кодовая база, соответствующая стандартам Senior-разработки, с автоматическим исправлением замечаний через GitHub CI.

10. Real-time инфраструктура: WebSockets на базе PartyKit и PartyServer

Контекст: Polling базы данных каждые несколько секунд не подходит для чата поддержки из-за задержек и высокой нагрузки на Postgres. Использование сторонних провайдеров (Pusher, Ably) увеличивает расходы. Оптимальное решение — PartyKit / PartyServer (Cloudflare Durable Objects). Архитектура строится на двух изолированных классах комнат: комната конкретного диалога (Conversation) для чата и комната рабочего пространства (Workspace) для обновления счетчиков и списка тикетов в дашборде.

Тайминг: ▶ 212:40, ▶ 218:20, ▶ 227:00

Выгода: Мгновенная доставка сообщений (<50 мс), отображение статуса набора текста (typing indicator) и звуковые уведомления при нулевой стоимости инфраструктуры в рамках Free Tier.

Как применить:

• Шаг 1: Разделение Durable Objects на два класса —
  • ConversationRoom: Управляет сообщениями между конкретным посетителем и оператором/AI.
  • WorkspaceRoom: Рассылает события создания новых диалогов всем открытым вкладкам операторов компании.
• Шаг 2: Реализация Heartbeat и Typing Indicators — Настройте отправку события печати с интервалом в 5 секунд для автоматического сброса индикатора набора текста при бездействии.
• Шаг 3: Генерация встраиваемого скрипта (embed.js) — Соберите легковесный бандл с помощью esbuild, создающий адаптивный iframe на стороне клиентского сайта с автоматической подстройкой размеров и поддержкой мобильного полноэкранного режима.

// Пример публикации события из Next.js сервера в PartyKit комнату
export async function publishToPartyKit(roomId: string, event: RealtimeEvent) {
  const partyUrl = process.env.REALTIME_SERVER_URL;
  const secret = process.env.REALTIME_PUBLISH_SECRET;
 
  await fetch(`${partyUrl}/parties/conversation/${roomId}`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-publish-secret": secret!,
    },
    body: JSON.stringify(event),
  });
}

Результат: Масштабируемый real-time транспорт, мгновенно синхронизирующий виджет и дашборд без нагрузки на основную базу данных.

11. Высокопроизводительный RAG-пайплайн на Neon Serverless Functions и pgvector

Контекст: Обработка документов в основном процессе Next.js приводит к таймаутам Lambda-функций на Vercel (лимит 30-60 секунд) и зависанию UI. Вынос парсинга, чанкинга и векторизации в фоновые Neon Serverless Functions позволяет обрабатывать документы любого размера в параллельном режиме (время выполнения до 15 минут) прямо в том регионе, где расположена база данных.

Тайминг: ▶ 263:40, ▶ 271:20, ▶ 304:00

Выгода: Параллельная обработка неограниченного числа файлов, время ответа AI-агента до первого токена менее 1.5 секунд.

Как применить:

• Шаг 1: Архитектура загрузки через Pre-signed URLs — Клиент запрашивает URL на сервере Next.js, загружает файл напрямую в S3-совместимое хранилище Neon, минуя body-size лимиты Vercel.
• Шаг 2: Триггер фоновой функции Ingest — При появлении файла в бакете срабатывает Neon Function:
  • Извлечение текста (PDF, Markdown, TXT).
  • Чанкинг на фрагменты с перекрытием.
  • Генерация эмбеддингов через модель Qwen 3 Embedding на Neon AI Gateway.
  • Сохранение векторов и метаданных в таблицу Postgres с расширением pgvector.
• Шаг 3: Классификация и генерация ответа —
  • Сообщение посетителя классифицируется быстрой моделью (GPT-4o-mini / GPT-5.4-nano) на 4 категории: Support, Smalltalk, Off-topic, Human-request.
  • При Support: Векторный поиск релевантных чанков через косинусное сходство в pgvector.
  • Генерация ответа через стриминг в PartyKit-комнату. Если релевантных чанков нет — автоматический вызов функции передачи человеку (human handoff).

-- Векторный поиск релевантных фрагментов базы знаний в pgvector
SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM knowledge_chunks
WHERE workspace_id = $2 AND 1 - (embedding <=> $1) > 0.75
ORDER BY similarity DESC
LIMIT 5;

Результат: Отказоустойчивый RAG-пайплайн, защищенный от prompt injection, который отвечает строго по документам компании и мгновенно переводит нерешаемые вопросы на живого оператора.

12. Развертывание в продакшен через MCP: Vercel, Cloudflare и Neon

Контекст: Финальный этап деплоя часто сопровождается ошибками конфигурации переменных окружения и несовпадением схем. Использование специализированных MCP-серверов позволяет оркестратору выполнить деплой полностью автономно: применить миграции к продакшен-ветке Neon, запустить воркер PartyKit на Cloudflare и создать проект на Vercel со всеми связанными переменными.

Тайминг: ▶ 329:40, ▶ 334:20, ▶ 352:00

Выгода: Безошибочный релиз сложной распределенной системы менее чем за 5 минут без ручной настройки конфигурационных файлов.

Как применить:

• Шаг 1: Подготовка Neon Production Branch — Агент выполняет Prisma-миграции на ветку production, генерирует прод-ключи для Storage и AI Gateway, настраивает CORS и доверенные домены.
• Шаг 2: Деплой PartyServer на Cloudflare — Публикация продакшен-воркера real-time чата с установкой production-секретов для верификации сокетов.
• Шаг 3: Деплой Next.js на Vercel через MCP — Создание проекта, автоматическая привязка переменных окружения из прод-ветки Neon и запуск продакшен-сборки в том же географическом регионе (Frankfurt).

# Проверка работоспособности продакшен-сборки:
1. Регистрация нового Workspace через интерфейс на проде
2. Загрузка базы знаний в форматах Markdown/PDF
3. Встраивание сгенерированного <script> на внешний тестовый сайт
4. Проверка AI-ответов виджета и real-time перехвата чата из дашборда

Результат: Полностью рабочий production-ready клон Intercom (Marshall Desk), готовый к масштабированию и приему реальных пользователей.

FAQ

В: Почему для RAG-пайплайна была выбрана модель эмбеддингов Qwen 3 на Neon AI Gateway вместо OpenAI text-embedding-3-small?

О: Использование Qwen 3 Embedding через Neon AI Gateway устраняет необходимость подключения отдельного стороннего аккаунта OpenAI и шаринга дополнительных API-ключей. Модель работает в едином регионе с базой данных, имеет сопоставимое или более высокое качество для мультиязычных текстов и доступна с нулевой наценкой по себестоимости токенов провайдера.

В: Зачем разделять комнаты PartyKit на Conversation и Workspace?

О: Это необходимо для разделения нагрузки и правильной доставки событий. Комната Conversation обслуживает только сообщения конкретного диалога между клиентом и оператором. Комната Workspace предназначена исключительно для дашборда операторов: в нее приходят глобальные оповещения о создании новых диалогов, обновлении счетчиков очереди и изменении онлайн-статусов, о которых дашборд не мог бы узнать, не будучи подписанным на еще не созданную комнату диалога.

В: В чем главное преимущество Neon Serverless Functions перед стандартными API Routes на Vercel?

О: Серверные функции Vercel имеют жесткий лимит времени выполнения (10–60 секунд на стандартных планах), что приводит к обрыву задач при обработке больших документов. Serverless-функции Neon могут выполняться до 15 минут, работают в том же дата-центре рядом с Postgres-хранилищем и позволяют обрабатывать десятки файлов в параллельном потоке без блокировки основного сервера.

В: Почему важно создавать лендинг и файл design.md до разработки дашборда и логики авторизации?

О: Лендинг формирует визуальный фундамент приложения (шрифты, скругления, палитру, анимации). Зафиксировав правила в design.md, разработчик исключает генерацию визуального AI-шлака на последующих этапах: все внутренние страницы дашборда и формы авторизации автоматически переиспользуют готовую дизайн-систему без необходимости последующего рефакторинга.

В: Как защитить чат-виджет от злоупотреблений и prompt injection (например, выманивания скидок)?

О: В архитектуре реализован двухэтапный барьер. Сначала классификатор (GPT-4o-mini) фильтрует офтоп и попытки взлома. Затем агент генерации ответа получает строгий системный промпт, требующий отвечать исключительно на основе переданных фрагментов контекста (pgvector). Если релевантных данных в базе знаний нет, модель вызывает инструмент cannot_answer, и диалог бесшовно переводится на оператора-человека без генерации галлюцинаций.

В: Почему не стоит использовать plan-mode во всех промптах без разбора?

О: Plan-mode полезен в больших корпоративных командах для согласования архитектурных изменений перед коммитом. Однако при быстром вайбкодинге сольных SaaS он создает избыточное трение, замедляет разработку и заставляет тратить лишние токены на подтверждение очевидных шагов. Гораздо эффективнее использовать двухсессионный подход: тщательно спланировать задачу в первой сессии, а во второй дать агенту свободу исполнения.

Ресурсы и ссылки

• Neon — Serverless Postgres платформа с pgvector, Auth, Object Storage, Functions и AI Gateway — https://neon.tech
• PartyKit / PartyServer — Real-time WebSockets инфраструктура на Cloudflare Durable Objects — https://partykit.io
• Shadcn UI — Библиотека открытых UI-компонентов на базе Radix и Tailwind CSS — https://ui.shadcn.com
• oRPC — Типобезопасная контрактная библиотека для создания масштабируемых API — https://orpc.unnoq.com
• Motion Sites — Коллекция готовых качественных дизайн-промптов для лендингов — https://motionsites.com
• Cursor BugBot / PullFrog / CodeRabbit — Инструменты автоматизированного AI-код-ревью для GitHub Pull Requests — упомянуты в видео
• Matt's Skills Repository — Набор навыков для AI-агентов (grill-with-docs) — упомянут в видео
• Emil Kowalski Design Engineering — Навык по проектированию интерфейсов и микроанимаций — упомянут в видео

Конспект создан на основе видео «How to Build a $1B SaaS with AI (Intercom Clone)» канала Syntax / Jan. Все права на оригинальный материал принадлежат авторам. Источник: https://www.youtube.com/watch?v=H84vfy96m_k