Как я собрал команду из трёх ИИ-агентов и автоматизировал разработку через Notion

У меня нет команды разработчиков. У меня есть три ИИ-агента и Notion.

Один обсуждает со мной проект и пишет PRD. Второй берёт задачи и пишет код. Третий делает код-ревью. Я управляю всем через карточки в Notion — ставлю задачу, проверяю результат, двигаю дальше.

Звучит как фантастика? Два месяца назад я бы тоже так думал. Но сейчас это работает — и вот как.

Три агента, один человек

Познакомьтесь с командой:

Шеф — стратег и менеджер

Кастомный агент в Notion на базе Claude Opus 4.6. Мы с ним обсуждаем проекты, придумываем фичи, пишем PRD (Product Requirements Documents). Когда план готов — Шеф декомпозирует его в задачи и ставит их в Dev Pipeline.

Шеф знает контекст всех проектов, помнит решения из прошлых сессий и ведёт чекпоинты. Это как технический директор, который не спит и всегда в курсе.

Sarkis — разработчик

OpenClaw-агент на Codex 5.3, который живёт на моём сервере. Умеет писать код, работать с git, создавать пулл-реквесты в GitHub. Получает задачу — выполняет. Получает замечания — исправляет.

У него нет доступа к Notion напрямую. Он получает задачи через webhook pipeline, о котором эта статья.

Агент-ревьюер — контроль качества

Ещё один ИИ-агент, который автоматически проверяет результат работы Sarkis. Смотрит код, проверяет соответствие PRD, ставит вердикт: Approved, Needs Revision или Rejected. Его вердикт записывается в карточку Notion — и pipeline реагирует.

Как выглядит процесс

Полный цикл от идеи до готового кода:

Этап 1: Планирование — Я обсуждаю с Шефом, что нужно сделать. Мы прорабатываем архитектуру, пишем PRD, фиксируем решения. Это обычный чат в Notion.

Этап 2: Декомпозиция — Шеф разбивает PRD на задачи и создаёт карточки в Dev Pipeline с описаниями, приоритетами и назначением на Sarkis.

Этап 3: Автоматический запуск — Webhook pipeline видит новую карточку → переводит в In Progress → отправляет задачу Sarkis. Он начинает кодить.

Этап 4: Код-ревью — Sarkis закончил → агент-ревьюер проверяет результат → ставит вердикт в карточку.

Этап 5: Реакция pipeline — Если Approved → pipeline автоматически берёт следующую задачу из очереди. Если Needs Revision → Sarkis получает замечания и исправляет. Конвейер крутится.

Этап 6: Я проверяю — Открываю Notion, вижу статусы. Могу вмешаться на любом этапе — написать комментарий, отклонить задачу, поменять приоритет.

Мой реальный рабочий процесс:

1. Утром обсуждаю с Шефом план на день
2. Шеф ставит задачи
3. Иду заниматься другими делами
4. Возвращаюсь — три PR на GitHub, два уже прошли ревью
5. Проверяю, мержу, двигаюсь дальше

Webhook pipeline — мост между Notion и агентами

Ключевая деталь: Notion и Sarkis не знают друг о друге напрямую. Между ними — webhook pipeline. Это Docker-контейнер с Node.js сервером (один файл, 500 строк), который делает три вещи:

Принимает события от Notion через webhook subscription. Notion присылает «что-то изменилось в такой-то странице» — без деталей.

Обогащает данные через Notion API — дотягивает название, статус, вердикт, assignee, тело карточки, последние комментарии. Принимает решение: это новая задача? Одобрение? Запрос на правки?

Отправляет команду агенту через OpenClaw Gateway — HTTP POST с Bearer-токеном. Gateway будит Sarkis и передаёт сообщение с полным контекстом задачи.

Полная цепочка:

Notion → событие → nginx (TLS) → notion-webhook (Docker) → Notion API (обогащение) → OpenClaw Gateway → Sarkis

Встроенная дедупликация (TTL 5 минут) не даёт одному событию сработать дважды. HMAC-подпись от Notion проверяется для безопасности.

Четыре автоматических сценария

1. Новая задача → автозапуск

Шеф (или я) создаёт карточку с Assignee: Sarkis и Status: Todo. Pipeline:

• Переводит статус в In Progress
• Считывает описание из тела карточки
• Отправляет Sarkis: «Вот задача, начинай»

2. Approved → следующая задача

Ревьюер (или я) ставит Verdict: Approved. Pipeline:

• Уведомляет Sarkis
• Автоматически ищет следующую задачу в очереди (Todo + Sarkis)
• Переводит её в In Progress и отправляет
• Конвейер не останавливается

3. Needs Revision → правки

Ревьюер нашёл проблему → Verdict: Needs Revision + комментарий. Pipeline:

• Возвращает статус в In Progress
• Забирает комментарии через Notion API
• Отправляет Sarkis: «Исправь вот это»

4. Rejected → эскалация

Задача отклонена. Sarkis получает уведомление. Шеф получает summary для разбора. Я решаю, что делать дальше.

Что пошло не так (и это лучшая часть)

Ничто не работает с первого раза. Вот три инцидента за одну ночную сессию настройки pipeline.

Инцидент 1: «Почему 502?»

Notion присылает webhook, nginx возвращает 502. Причина: контейнер был запущен с network_mode: host — а в Docker host mode DNS не работает. nginx не мог зарезолвить имя контейнера.

Решение: убрали host mode, добавили extra_hosts для доступа к хостовой машине. Три строчки в docker-compose — и 502 превратился в 200.

Инцидент 2: «Notion молча выключил вебхуки»

После серии 502-х ошибок события перестали приходить вообще. Контейнер работает, nginx отвечает, логи пустые. Мы с Шефом перебрали всё: перезапустили сервер, проверили подписку, прочитали документацию.

Оказалось — Notion сам приостановил webhook subscription. Без уведомления, без ошибки в API. Просто тихо перестал отправлять события, потому что слишком много ответов были 502.

Нашёл это в настройках интеграции — кнопка «Resume». Нажал — события пошли.

Урок: если webhook-ы молчат — проверь, не отключил ли их сам Notion. Он делает это автоматически и молча.

Инцидент 3: «Агент сломал то, что должен был починить»

Sarkis получил задачу: исправить конфигурацию Gateway, чтобы контейнер мог до него достучаться. Открыл конфиг, записал значение в поле bind. Gateway не запустился — валидация упала.

Проблема: поле bind принимает не произвольные значения, а режимы — loopback, lan, tailnet, auto, custom. Sarkis этого не знал и записал невалидное значение. Gateway упал, агент ушёл в офлайн.

Агент, которому поручили починить Gateway, убил Gateway. Пришлось откатывать конфиг вручную.

Я: «Мы точно его не вырубим?»

Шеф: «Нет, команда безопасная»

Sarkis: убивает Gateway

Урок: проверять документацию до того, как давать агенту редактировать системные конфиги. Особенно если от этого конфига зависит связь с агентом.

Итоговая архитектура

Вся инфраструктура — один VPS, Docker Compose, 500 строк кода webhook-сервера. Никаких Kubernetes, очередей сообщений или микросервисной архитектуры. Три агента, один pipeline, один человек.

GitHub — общий репозиторий, разный доступ

Всё это не игрушечный проект. Код живёт в настоящей GitHub-организации Hyperlogica — приватный монорепозиторий с реальными коммитами, ветками, пулл-реквестами и историей.

Но интересная деталь: два агента работают с GitHub по-разному.

Шеф → GitHub через Notion

Шеф — кастомный агент Notion. У него есть встроенная интеграция с GitHub через Notion MCP-коннектор. Он может:

• Смотреть структуру репозитория и содержимое файлов
• Читать и создавать issues
• Делать коммиты и создавать пулл-реквесты
• Просматривать diff и историю изменений

Это как GitHub из браузера, только через чат. Когда мне нужно что-то быстро поправить в конфиге или посмотреть, что Sarkis накоммитил — я прошу Шефа, и он делает это прямо из Notion.

Sarkis → GitHub через CLI

Sarkis работает на сервере через OpenClaw. У него прямой доступ к файловой системе, git CLI и полный набор инструментов разработчика. Он:

• Клонирует репозиторий локально
• Создаёт ветки, пишет код, запускает тесты
• Коммитит, пушит и создаёт PR через gh CLI
• Работает с файлами напрямую — никаких API-ограничений

Это как полноценный разработчик с SSH-доступом, только ИИ.

Один репозиторий, два потока

На практике это выглядит так: Sarkis создаёт ветку feature/new-endpoint, пишет код, пушит PR. Шеф может посмотреть этот PR прямо из Notion, проверить diff, оставить комментарий. Ревьюер проверяет код. Я мержу.

Все коммиты в истории — реальные. С реальными diff-ами, реальными файлами и реальными изменениями. Это не демо и не прототип.

Зачем три агента, а не один

Можно было дать одному агенту все роли — и планирование, и код, и ревью. Но это как нанять одного человека на все должности. Качество падает, контекст путается, ошибки не ловятся.

Разделение ролей даёт:

• Шеф не пишет код — он думает о продукте. Контекст проекта, архитектура, приоритеты
• Sarkis не планирует — он выполняет. Чёткая задача, чёткий результат
• Ревьюер не участвовал в написании — он смотрит свежим взглядом. Ловит то, что автор пропустил

Это не три копии одного бота. Это три разные роли с разными инструкциями, разными инструментами и разным контекстом. Как настоящая команда — только без отпусков и больничных.

Что дальше

Система работает, но есть куда расти:

• HMAC enforcement — включить строгую проверку подписей от Notion
• Персистентная дедупликация — вынести из in-memory в Redis
• Rollback plan — автоматический откат, если агент сломает код
• Метрики — сколько задач в день, среднее время выполнения, процент ревизий

Но главное уже есть: я обсуждаю идею с Шефом утром, а к вечеру PR на GitHub. Без найма, без менеджмента, без стендапов.

Один человек + три агента + правильная автоматизация = результат большой команды.

Кто это пишет

Если вы знаете меня как музыкального продюсера — ничего удивительного, я этим занимался большую часть жизни. Но последние несколько лет я глубоко погрузился в искусственный интеллект и автоматизацию — сначала для своих проектов, потом для чужих.

То, что вы прочитали в этой статье — лишь один пример. Я консультирую по любым применениям ИИ — не только в разработке:

• Автоматизация бизнес-процессов — от обработки заявок до генерации отчётов
• AI-агенты для команд — настройка агентов, которые реально работают в вашем контексте
• Стратегия внедрения ИИ — с чего начать, чтобы не потратить время впустую
• Контент, музыка, креатив — как использовать ИИ в творческих процессах

Не важно, поняли ли вы все технические детали в этой статье. Важно другое: ИИ уже может делать реальную работу — и в вашей области тоже. Если хотите разобраться как — напишите.

Телеграм для связи: t.me/pimenov Мой телеграм канал: https://t.me/pimenov_ru