# Vibe Engineering: как управлять AI вместо написания кода

Источник: https://www.youtube.com/watch?v=tz-CPq3WgeA
Канал: JavaScript Mastery
Опубликовано: 17.07.2026

---

Разработка программного обеспечения окончательно перестала быть процессом написания кода, превратившись в дисциплину по управлению AI-планированием и архитектурным проектированием. Вместо того чтобы самому печатать функции, эффективный инженер сегодня создает «вибрации» проекта — систему инструкций, где искусственный интеллект берет на себя тяжелую работу от дизайна до сбора данных, оставляя человеку роль стратега.

## 🚀 Эволюция AI-разработки: Концепция Vibe Engineering

[[JUMP:00:00]]

Современная разработка с использованием искусственного интеллекта часто превращается в бесконечный цикл правок, когда разработчик по многу раз переписывает один и тот же промпт, пытаясь добиться от модели нужного результата [0:26]. Эдриан из JavaScript Mastery утверждает, что главная проблема большинства неудачных AI-проектов заключается в недопонимании: разработчик знает, что ему нужно, но не может донести это до AI на его языке [0:39]. Чтобы решить эту проблему, предлагается методология **Vibe Engineering** — подход, при котором человек задаёт направление, а AI сам пишет детальные инструкции для реализации функций [2:38].

В основе Vibe Engineering лежит идея, что если современные модели (такие как Claude 3.5 Sonnet или GPT-4o) достаточно умны, чтобы писать код, то они достаточно умны и для того, чтобы планировать этот код [5:15]. Вместо того чтобы тратить по 20 минут на составление огромного промпта, разработчик указывает на файл со спецификациями или документацию и говорит, что должно произойти [5:29]. AI анализирует задачу, определяет необходимые изменения в файлах и сам составляет «промпт на реализацию» [5:43]. Таким образом, разработчик переходит от роли исполнителя к роли архитектора и ревьюера, который одобряет план действий до того, как будет написана первая строка кода [6:08].

### Стратегический центр: Файл agents.md и его роль
[[JUMP:06:22]]

Для управления сложными проектами недостаточно простого общения с чатом. В методологии Vibe Engineering центральное место занимает файл `agents.md` [6:22]. Это не просто список технологий, а документ, описывающий мыслительный процесс и правила игры для AI-агента [6:36]. Вместо того чтобы хранить ответы на вопросы «что построить», этот файл содержит инструкции о том, «как думать» перед тем, как приступать к задаче [6:50].

В `agents.md` фиксируются критически важные аспекты проекта:

*   **Список Out-of-Scope (Вне рамок проекта):** AI-агенты часто стремятся добавить лишние функции (комментарии, уведомления), которые кажутся полезными, но не входят в текущий план [7:31]. Чёткое перечисление того, что делать НЕ нужно, экономит время и ресурсы [7:46].
*   **Data Model (Модель данных):** Жесткие правила для структур данных (например, обязательное наличие URL изображения или даты публикации статьи), которые AI будет принудительно соблюдать во всех частях системы: от скрапера до валидации в UI [7:59].
*   **Правила отката (Fallback Rules):** Список действий для ситуаций, не описанных в файле. Главное правило — создавать минимально жизнеспособный код и задавать уточняющие вопросы вместо того, чтобы принимать важные решения самостоятельно [8:13].

Такой подход позволяет AI действовать автономно, но в строгих рамках архитектуры проекта [8:38]. Ранее в разговоре упоминалось, что для более глубокого погружения в тему агентной инженерии существует отдельный курс, где эти концепции раскрываются на корпоративном уровне [3:32].

### Модульность знаний через использование Skills
[[JUMP:08:50]]

Если `agents.md` отвечает за контекст конкретного проекта, то за знания об инструментах отвечают так называемые **Skills (Навыки)** [8:50]. Скилл — это выделенный файл (обычно в формате Markdown), содержащий лучшие практики и паттерны работы с конкретной библиотекой или сервисом [9:04]. 

Например, скилл для Clerk может содержать правила правильной реализации аутентификации, а скилл для Supabase — паттерны запросов и настройки безопасности (RLS) [9:04]. Такое разделение ответственности даёт два огромных преимущества:

1.  **Обновляемость:** Если библиотека выпускает обновление, разработчику нужно обновить всего один файл навыка, а не переписывать промпты во всём проекте [9:17].
2.  **Переиспользование:** При запуске нового проекта со знакомым стеком достаточно перенести файлы скиллов и написать свежий `agents.md` [9:17].

В рабочем процессе это выглядит максимально просто: разработчик пишет короткий промпт «Реализуй Clerk-аутентификацию, используя скилл Clerk» [9:32]. AI берет контекст проекта из `agents.md`, технические знания из файла навыка и самостоятельно готовит план внедрения [9:45].

### Рабочий процесс (Workflow): От промпта к утверждению
[[JUMP:10:12]]

Ключевое отличие Vibe Engineering от обычной разработки с AI — это наличие промежуточного шага планирования. Перед тем как прикоснуться к любому файлу кода, AI обязан создать «промпт на реализацию» и сохранить его в папке `prompts` в формате Markdown [10:25]. Этот документ не является просто кратким пересказом — это детальная спецификация [10:38].

Типовой план реализации от AI включает в себя:

*   **Цель:** Одно четкое предложение о том, что будет сделано [10:38].
*   **Контекст:** Какие файлы будут прочитаны и какие скиллы использованы [10:50].
*   **Список изменений:** Точный перечень файлов, которые будут созданы или модифицированы [10:50].
*   **Критерии приемки:** Технические проверки (тайпчек, линтинг) и пошаговая инструкция для разработчика по проверке функционала (например, конкретные curl-команды или действия в интерфейсе) [11:04].

Разработчик читает этот план и задает себе вопрос: «Достаточно ли он хорош для исполнения?» [11:31]. Если план содержит ошибки, они исправляются на этапе текста, а не на этапе уже написанного кода [11:45]. Это позволяет ловить архитектурные проблемы до того, как они станут «фичами», которые придется переделывать [11:57].

### Подготовка инфраструктуры и первый запуск
[[JUMP:16:21]]

Для демонстрации эффективности Vibe Engineering выбран проект Skew — новостная платформа на базе AI [1:05]. Перед началом кодинга необходимо подготовить четыре ключевых сервиса, каждый из которых имеет бесплатный уровень для старта: Clerk для управления пользователями [16:34], Supabase в качестве базы данных и backend-платформы [17:13], OxyLabs для надежного скрапинга новостей [18:07] и PostHog для продуктовой аналитики [19:12]. 

Настройка проекта начинается с классической команды `npx create-next-app@latest` [20:44]. При инициализации выбираются стандартные настройки: TypeScript, ESLint и React Compiler [20:57]. Эдриан подчеркивает, что лучший способ познакомиться с новой структурой проекта — попросить об этом AI [22:46]. В качестве основного инструмента в видео используется расширение Claude Code в VS Code [23:24]. Первый тест агента — просьба объяснить структуру сгенерированного Next.js приложения в дружелюбном, но техническом стиле [24:16]. Агент успешно анализирует файлы, объясняет роль папки `app`, работу серверных компонентов и стилизацию через Tailwind [24:43]. С этого момента проект готов к превращению в полноценную систему через методологию Vibe Engineering.

## 🎨 Создание дизайн-системы и интерфейса приложения
[[JUMP:37:38]]

### Фундамент проекта: Настройка дизайн-системы и токенов Tailwind CSS
[[JUMP:37:38]]

Прежде чем приступать к разработке функциональных модулей, необходимо заложить консистентную визуальную основу. В современной AI-разработке это начинается не с написания кода, а с предоставления модели качественного UI-референса [37:38]. Для проекта Skew — новостного агрегатора, фокусирующегося на балансе мнений, — визуальный язык критически важен, так как он должен наглядно отображать политический уклон (bias) статей [43:47].

Процесс настройки дизайн-системы включает несколько ключевых этапов:

1.  **Анализ визуального референса**: Агенту передается изображение-спецификация, созданное с помощью модели GPT Image 2.0 [39:24], на котором зафиксированы основные цвета, типографика, сетка и примеры карточек [38:18].
2.  **Генерация дизайн-токенов**: Вместо того чтобы стилизовать каждую страницу отдельно, AI создает глобальный файл `app.globals.css`, куда прописываются переменные для Tailwind CSS [40:42]. Сюда входят основные цвета бренда, шкала отступов, радиусы скруглений и специфические цвета для индикации медиа-предвзятости (left/right bias colors) [40:55].
3.  **Создание примитивов**: На базе токенов агент генерирует библиотеку базовых компонентов: кнопки, чипы (badges) для категорий, измерители предвзятости (bias meters) и скелетоны карточек [41:00].
4.  **Визуальная валидация**: Важным шагом является создание страницы-витрины (`/design-system`), где рендерятся все созданные компоненты [41:08]. Это позволяет разработчику убедиться, что ховер-эффекты, тени и шрифты соответствуют задумке, прежде чем они разойдутся по всему приложению [41:36].

Ранее в разговоре упоминалось, что агент всегда следует правилам из файла конфигурации проекта, поэтому он не приступает к кодингу сразу, а сначала формирует промпт на реализацию и ждёт одобрения пользователя [38:45]. Такой подход гарантирует, что UI останется целостным даже при добавлении множества новых экранов [41:49].

### Реализация главной страницы (Homepage) на базе mock-данных
[[JUMP:43:21]]

После фиксации дизайн-системы разработка переходит к созданию первой полноценной фичи — главной страницы [43:21]. Методология «Vibe Engineering» предполагает итеративный подход: сначала строится презентационный слой (UI), а уже потом подключается логика данных [45:04].

Для реализации главной страницы агент анализирует структуру макета, которая включает:

*   Верхнюю утилитарную панель (top bar) и липкий боковой хедер с логотипом [44:50].
*   Горизонтально скроллируемую строку с категориями новостей (chips) [45:04].
*   Трехколоночную адаптивную сетку вертикальных карточек новостей [45:04].

Критически важно на этом этапе использовать типизированные mock-данные (заглушки) вместо реальных запросов к базе данных Superbase [45:17]. Это позволяет отладить верстку до пикселя и убедиться в корректности адаптивности, не отвлекаясь на ошибки API или задержки сети [45:17]. В результате генерируются современные React-компоненты (sidebar, category bar, site footer), соответствующие высоким стандартам кодинга [45:42]. 

В процессе тестирования на мобильных устройствах (например, в режиме симуляции iPhone 14 Pro Max) могут возникать баги, такие как «выскакивание» элементов за пределы вьюпорта [46:35]. Такие проблемы легко решаются с помощью уточняющих голосовых промптов: достаточно указать AI на проблему, и он автоматически скорректирует стили [46:49].

### Детальная страница статьи и визуализация AI-анализа
[[JUMP:47:41]]

Третьим этапом визуальной сборки становится страница деталей новости (`news details page`), где пользователь знакомится с полным содержанием и AI-аналитикой [47:41]. На этой странице реализуется двухколоночная разметка, включающая основной текст статьи, блок связанных историй и призыв к подписке на рассылку [49:02].

Особенности реализации этого интерфейса:

*   **Динамический роутинг**: Используются возможности Next.js для обработки параметров страниц и вывода 404 ошибки для несуществующих ID [49:28].
*   **Сложные компоненты**: Создаются специализированные UI-элементы для отображения результатов анализа тональности контента (sentiment analysis), хотя на данном этапе они также заполнены тестовыми данными [49:28].
*   **Автоматизированная проверка**: После генерации кода агент самостоятельно запускает проверки, имитируя переходы по разным URL, чтобы подтвердить работоспособность навигации [49:42].

В итоге, имея на руках готовую дизайн-систему, главную страницу и экран деталей, разработчик получает полностью функционирующий визуальный прототип [50:08]. Хотя расчеты предвзятости и тексты статей на этом этапе являются фиктивными [50:21], такая база позволяет бесшовно интегрировать реальные данные из Superbase и результаты скрапинга на следующих этапах разработки.

## 🔐 Аутентификация и данные: Развертывание Clerk и Supabase

[[JUMP:52:06]]

Переход от визуального прототипирования к созданию полноценного приложения начинается с внедрения логики идентификации и настройки надежного хранилища [51:51]. На этом этапе проект перестает быть набором статических макетов, созданных в рамках «vibe engineering» (о котором шла речь в первой главе), и обретает архитектурный скелет. Основная стратегия здесь заключается в четком разделении ответственности: Clerk берет на себя управление личностью пользователя, в то время как Supabase становится единым источником истины для всех данных приложения [53:00].

### Управление пользователями: Интеграция Clerk и защита маршрутов
[[JUMP:52:06]]

Выбор Clerk в качестве системы аутентификации обусловлен его способностью предоставить готовые UI-компоненты «из коробки», что избавляет разработчика от написания сложного кода для обработки сессий и интеграции OAuth-провайдеров [52:46]. В отличие от встроенных решений баз данных, Clerk предлагает полноценную платформу управления пользователями, которая легко масштабируется до уровня организаций и систем монетизации [52:34].

Процесс внедрения системы в приложение Skew News проходил через следующие этапы:

*   **Настройка провайдеров:** В панели управления Clerk были выбраны Google и авторизация по Email как основные способы входа [53:27].
*   **Конфигурация окружения:** Публичный и секретный ключи API были интегрированы в файл `.env.local` для обеспечения связи между SDK и сервером [53:57].
*   **Агентское внедрение:** Вместо ручного написания кода использовался специализированный агент, которому была поставлена задача внедрить аутентификацию, используя предварительно установленные «навыки» (skills) для Clerk [54:11].

Важным архитектурным решением стало разграничение прав доступа: главная страница с лентой новостей остается публичной, но для просмотра детального анализа статьи и полных данных пользователю необходимо авторизоваться [54:49]. Использование актуальной версии Clerk SDK (V7) позволило агенту автоматически применить новые методы защиты маршрутов и заменить устаревшие компоненты `SignedIn`/`SignedOut` на современные API-проверки [55:59]. В итоге, после успешного входа через Google, пользователь перенаправляется обратно к контенту, а в интерфейсе появляется компонент управления профилем и безопасностью [56:42].

### Архитектура данных: Supabase как источник истины
[[JUMP:58:29]]

Если Clerk отвечает за то, *кто* зашел в приложение, то Supabase определяет, *что* пользователь видит. Согласно правилам архитектуры, зафиксированным в файле `agents.md`, пользовательский интерфейс должен отображать только те данные, которые уже сохранены в базе [58:55]. Это означает, что слои скрапинга и анализа (которые будут подробно разобраны в следующей главе) работают независимо, а UI лишь обращается к таблицам Postgres [59:09].

Для реализации этого слоя в Supabase был создан проект `JSM_SKU_news` [59:22]. Интеграция потребовала настройки трех типов ключей: публичного URL, анонимного ключа (anon key) для базовых запросов и секретного ключа роли сервиса (service role key) для выполнения административных операций на стороне сервера [1:00:14].

### Автоматизация БД и создание типизированного доступа
[[JUMP:1:00:57]]

Процесс настройки базы данных был полностью делегирован AI-агенту Claude, который проанализировал существующие паттерны кода и структуру `agents.md` для формирования детального плана реализации [1:01:24]. Ключевой особенностью стало создание «рукописных» (handwritten) типов данных, что обеспечило строгую типизацию в TypeScript с самого первого запроса [1:02:44].

Схема базы данных была спроектирована таким образом, чтобы охватить все аспекты работы новостного агрегатора:

1.  **Sources (Источники):** Таблица для хранения данных об изданиях, таких как BBC или Reuters [1:02:30].
2.  **Articles (Статьи):** Основное хранилище метаданных и текстов новостей [1:02:30].
3.  **Article Analyses:** Результаты работы нейросетей по анализу контента [1:02:30].
4.  **Logs и Schedules:** Системные таблицы для отслеживания работы скраперов и расписаний запусков [1:02:30].

Для проверки работоспособности системы агент сгенерировал SQL-скрипты для создания таблиц и наполнения их начальными данными (seed) [1:04:18]. После выполнения этих скриптов в SQL-редакторе Supabase в базе появилось пять активных источников [1:05:23]. Чтобы убедиться в корректности отображения, агент также создал «дамми-статью» — самодостаточный объект данных, который был вставлен вручную через консоль [1:06:19]. Это позволило мгновенно увидеть результат на локальном хосте: реальная запись из базы данных успешно отрендерилась на главной странице приложения [1:06:44]. Это заложило фундамент для следующего этапа — автоматизации наполнения этих таблиц через конвейер скрапинга.

## 🚀 От скрапинга к смыслам: создание автономного новостного пайплайна
[[JUMP:1:15:41]]

Настоящая ценность современного AI-приложения заключается не в простом отображении данных, а в их глубокой интерпретации. Когда скелет интерфейса уже готов, наступает критический момент — наполнение системы «живой» информацией. В Skew News этот процесс полностью автоматизирован: от обхода защиты новостных гигантов до вынесения вердикта о политической предвзятости каждой статьи. Благодаря связке прокси-инфраструктуры и больших языковых моделей, приложение превращается из пустой оболочки в мощный аналитический инструмент.

### Автоматизированный сбор данных через OxyLabs
[[JUMP:1:15:41]]

Процесс начинается с запуска пайплайна скрапинга, который обращается к списку авторитетных ресурсов, таких как BBC, NPR и Reuters [1:15:41]. На этом этапе критически важна стабильность соединения: использование инфраструктуры OxyLabs позволяет системе беспрепятственно собирать данные через сеть надежных прокси, избегая блокировок со стороны новостных сайтов [1:18:09]. В реальном времени можно наблюдать, как агент обрабатывает ссылки: например, из 48 ссылок на главной странице BBC может не найтись подходящих кандидатов, в то время как NPR сразу выдает 57 потенциальных статей для анализа [1:15:56].

Этот пайплайн — не просто скрипт для копирования текста, а сложная система с несколькими уровнями проверки:

*   **Очистка и дедупликация:** Система автоматически сверяет найденные URL с базой данных, чтобы исключить повторы [1:18:15].
*   **Фильтрация контента:** Используется «reject list» для отсеивания страниц, не являющихся новостными статьями [1:18:09].
*   **Валидация:** Каждая страница проходит проверку на корректность структуры перед сохранением в базу данных [1:18:15].

Результатом работы становится список из десятков детально проработанных страниц, сохраненных в Supabase (интеграция которой обсуждалась в предыдущих главах) [1:16:22]. Всего за один проход агент может собрать около 25 полных текстов статей с метаданными, такими как канонические URL и заголовки о важных событиях — например, о законопроектах по доступному жилью [1:17:04]. Самое впечатляющее, что вся эта производственная система была создана на основе одного короткого промпта, который агент развернул в детальные инструкции и реализовал программно [1:18:36].

### AI-анализ: определение тональности и политического вектора
[[JUMP:1:19:26]]

После того как сырые данные попадают в базу, они остаются скрытыми для пользователя до тех пор, пока поле `analyzed_at` имеет значение null [1:17:44]. Именно на этапе анализа приложение Skew News оправдывает свое название (от англ. *skew* — перекос, предвзятость), выявляя, в какую сторону склоняется автор статьи [1:19:26]. Для реализации этой логики используется API OpenAI, ключи от которого интегрируются в окружение проекта [1:20:45].

Согласно спецификациям в файле `agents.md` (о котором говорилось в начале курса), AI-агент должен генерировать комплексный отчет по каждой статье [1:19:54]. Этот отчет включает в себя:

1.  **Нейтральное резюме:** Краткое изложение сути событий без эмоциональной окраски [1:21:37].
2.  **Оценка тональности (Sentiment):** Определение общего настроя материала (позитивный, негативный или нейтральный) [1:19:39].
3.  **Политический фрейминг:** Оценка распределения предвзятости в процентах — насколько текст тяготеет к левому, центристскому или правому спектру [1:20:07].
4.  **Коэффициент уверенности:** Показатель того, насколько модель уверена в своем выводе (Confidence score) [1:23:50].

Важно понимать, что этот анализ — не истина в последней инстанции, а «оценка по мнению AI», о чем приложение честно предупреждает пользователя специальным дисклеймером [1:20:20]. Алгоритм анализирует исключительно текст статьи, не опираясь на репутацию самого издания [1:20:33]. Для обеспечения надежности данных на выходе используется валидация через библиотеку Zod [1:21:50].

### Интеграция результатов в интерфейс
[[JUMP:1:22:31]]

Запуск процесса анализа происходит через защищенный API-запрос с использованием секретного ключа администратора [1:22:57]. Система обрабатывает статьи батчами — например, по 5 штук за один проход [1:23:11]. Как только анализ завершается, в базе данных обновляются временные метки, и статьи мгновенно появляются на главной странице приложения [1:23:25]. Теперь каждая карточка новости содержит не только заголовок, но и визуальную шкалу политического фрейминга.

На практике это выглядит так: статья о происшествии на борту Ryanair (где пассажира частично засосало в иллюминатор) определяется как центристская, так как она не имеет политического подтекста [1:25:09]. В то же время материал о деятельности националистических группировок может быть классифицирован как значительно отклоняющийся влево или вправо в зависимости от риторики автора [1:25:09]. 

В процессе отображения могут возникнуть технические нюансы, такие как блокировка внешних изображений. Это решается настройкой `remotePatterns` в файле конфигурации Next.js, что позволяет корректно рендерить фотографии с любых новостных доменов [1:24:28]. В итоге пользователь получает полностью работоспособный продукт, который не просто агрегирует заголовки, а предоставляет глубокий контекст и инсайты о медиа-ландшафте [1:26:03]. В следующей главе будет рассмотрено, как использовать эти данные для поиска похожих материалов через векторные базы данных.

## 🚀 Автоматизация, аналитика и деплой: превращаем прототип в продукт
[[JUMP:1:40:43]]

### Продуктовая аналитика с PostHog и Slack-агентом
[[JUMP:1:40:43]]

На финальном этапе разработки Skew News фокус смещается с написания кода на понимание того, как пользователи взаимодействуют с приложением. Интеграция PostHog начинается с решения технических нюансов: например, блокировщики рекламы вроде uBlock или Brave Shield могут блокировать скрипты автозахвата событий [1:41:21]. Однако при деплое в реальный браузер эта проблема минимизируется, а серверный прокси обеспечивает стабильный трекинг [1:41:35]. Система не просто собирает анонимные клики — благодаря интеграции с Clerk, PostHog идентифицирует пользователей по их email, связывая поведение конкретного человека с его профилем [1:42:14].

Настоящая мощь современной аналитики раскрывается через «self-driving» подход. Вместо того чтобы часами настраивать дашборды, разработчик может взаимодействовать с данными напрямую через Slack [1:42:27].

*   Интеграция позволяет вызвать PostHog в любом канале и задать вопрос на естественном языке, например: «Какие статьи открывали чаще всего?» [1:42:39].
*   Агент использует MCP (Model Context Protocol) для извлечения данных из проекта и выдает ответ за несколько секунд: например, указывая, что лидер просмотров имеет 13 кликов [1:43:31].
*   Система способна анализировать воронки (drop-off) между главной страницей и чтением статьи без написания SQL-запросов [1:43:56].

Более того, PostHog может самостоятельно предлагать улучшения. Если вы хотите отслеживать клики по кнопке «Как мы анализируем предвзятость», агент проверит, работает ли автозахват, и сообщит, что кнопка уже отслеживается (например, 16 кликов от тестового пользователя) [1:45:30]. Если метрики нет, агент может сам создать «Insight» для дашборда или даже подготовить PR [1:45:43]. Это меняет статус-кво: аналитика перестает быть набором графиков и становится активным участником процесса разработки [1:46:34].

### Автоматизация через Vercel Cron и OxyLabs Scheduler
[[JUMP:1:46:50]]

Чтобы Skew News работал автономно, необходимо автоматизировать сбор и анализ новостей. Ранее в разговоре упоминался процесс скрапинга, но теперь он переводится на рельсы расписаний. Система автоматизации состоит из двух независимых компонентов, которые должны быть настроены одновременно [1:47:39]. 

Первый компонент — **OxyLabs Scheduler**. Он отвечает за то, что серверы OxyLabs каждый час заходят на главные страницы выбранных СМИ и сохраняют их HTML-код [1:48:09]. Важно понимать: OxyLabs не отправляет данные в приложение через вебхук, он просто хранит результат на своей стороне [1:48:36].

Второй компонент — **Vercel Cron**. Он настраивается через файл `vercel.json` и дает команду платформе вызвать API-роут приложения ровно через 15 минут после начала каждого часа [1:47:53]. Эта задержка в 15 минут критически важна по двум причинам:

1.  Скрапинг не происходит мгновенно, и приложению нужно дождаться готовности данных на стороне OxyLabs [1:49:02].
2.  Разделение задач позволяет избежать таймаутов серверных функций (Serverless Functions) [1:49:16]. Если бы мы пытались скрапить, парсить и анализировать десятки статей в рамках одного HTTP-запроса, функция бы просто аварийно завершилась [1:49:16].

Реализация этого пайплайна через агентов включает создание клиента для Data API OxyLabs, который умеет создавать расписания, деактивировать устаревшие задачи («orphans») и забирать результаты HTML [1:51:00]. В базе данных Supabase (которую настраивали в предыдущих главах) создаются таблицы `oxyilab_schedules` и `run_tables` для контроля статуса задач [1:49:55]. После запуска синхронизации через терминал, система создает расписания для всех активных источников (например, 5 крупных газет) [1:52:09].

### Деплой и работа с ограничениями платформы
[[JUMP:1:55:02]]

Публикация проекта на Vercel — это не только способ сделать его доступным миру, но и единственная возможность запустить Cron-задачи, так как локально они не срабатывают [1:55:27]. Процесс начинается с пуша кода в репозиторий GitHub [1:55:40]. При импорте проекта в Vercel критически важно правильно перенести переменные окружения из локального файла `.env`, а также добавить специальный `CRON_SECRET` — строку минимум из 16 символов для защиты эндпоинтов автоматизации [1:56:44].

После деплоя необходимо перенастроить Clerk (систему аутентификации) с тестовых ключей на продакшн-домен [1:57:38]. Одной из главных сложностей для новичков становятся лимиты тарифных планов Vercel:

*   **Hobby Plan:** позволяет запускать Cron-задачи не чаще одного раза в сутки [1:59:12]. Если ваше расписание в коде настроено на ежечасный запуск, деплой может завершиться ошибкой [1:59:25].
*   **Pro Plan:** поддерживает ежечасное выполнение [1:59:37].

Для проверки работоспособности нужно перейти в раздел Settings -> Cron Jobs в панели управления Vercel [2:00:02]. Если регистрация прошла успешно, там появится соответствующий API-путь. Теперь приложение полностью автономно: оно само собирает новости, проводит AI-анализ и обновляет ленту, пока разработчик может просто наблюдать за результатами [2:00:27].

### Масштабирование: PG Vector и будущее Skew News
[[JUMP:2:01:17]]

Построенная архитектура — это лишь фундамент. Для превращения Skew News в полноценный продукт можно внедрить функцию «связанных статей». Это реализуется с помощью расширения **PG Vector** в базе данных Postgres [2:01:17]. Использование векторных эмбеддингов позволяет выполнять семантический поиск: система находит статьи не по ключевым словам, а по смысловому сходству векторов контента [2:01:17].

Кроме того, проект готов к монетизации. Благодаря связке Clerk и системы биллинга, в приложение легко добавить тарифные планы [2:01:29]. Учитывая высокую стоимость и сложность качественного скрапинга через OxyLabs, такой сервис анализа медиа-предвзятости вполне может быть платным продуктом [2:01:29].

Главный вывод курса: в 2026 году навык написания кода уступает место навыку «проектирования» (architecting) [2:02:09]. AI не заменяет инженера, а многократно усиливает его возможности, превращая решения в работающее ПО с невероятной скоростью [2:01:57]. Теперь основной цикл разработки — это определение фичи в `agents.md`, постановка задачи агенту и контроль результата [2:01:43].