Прогнозируемый vibe-coding: пайплайн из агентов, который доводит фичи до прода без сюрпризов

Про vibe-coding сейчас не пишет только ленивый, и в массовом восприятии это выглядит так: накидал промпт в чат, получил стену кода, скопировал в редактор, не компилируется, попросил пофиксить, получил новую стену, и так по кругу, пока не кончатся токены или терпение. Для разовых скриптов это работает. Для продукта с живыми пользователями — нет.

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

В этой статье разберу архитектуру целиком: из чего она собрана, почему именно так, и где проходят границы, за которые я агентам выходить не даю. В качестве подопытного — мой pet-проект, обычный Telegram-бот на Go (MongoDB, Kubernetes). Что именно он делает — выходит за рамки статьи; важно, что это работающий продакшен с реальными пользователями, а не песочница.

TL;DR

• Связка «команда + саб-агенты» индивидуальна для каждого проекта. Универсальных агентов не бывает — под каждый проект своя команда-точка входа и свои саб-агенты с коротким контекстом под этот проект. Именно индивидуальность связки даёт скорость и качество.

• MCP — это руки и глаза агента. Через них он управляет базой (MongoDB), инфраструктурой (Kubernetes, DigitalOcean), статусом деплоя и созданием задач в GitHub — по максимуму, без ручных операций.

• Этап планирования обязателен. Product-агент не бросается кодить — сначала задаёт уточняющие вопросы и проектирует фичу, как живой коллега.

• Декомпозиция контекста ради качества. Контекст идёт «водопадом»: каждому саб-агенту уходит не вся переписка, а только его задача. Контекст не засоряется — агенты остаются вменяемыми даже на сложных фичах.

• Прозрачный контроль через код-ревью. Каждый PR ревьюит человек: агент открывает PR в dev и останавливается, не мержит. Без ревью это не AI-команда, а лотерея.

• Claude Code крутится на VPS, а не локально. Длинные задачи идут в фоне, не зависят от ноутбука и интернета; довести фичу до прода можно хоть с телефона по SSH.

Моделируем человеческую команду

Ключевая разница между рабочим сетапом и бездумным vibe-coding’ом — не в модели и не в количестве MCP-серверов. Она в том, что система повторяет процессы реальной IT-команды.

Есть продуктовая постановка задачи, есть декомпозиция на тикеты, есть pull request, ревью, деплой через dev в prod. Это тот самый нормальный человеческий пайплайн который мы будем воспроизводить.

В центре — Claude Code, запущенный на сервере. Он держит основной контекст и дирижирует. Вокруг — слой саб-агентов с чёткими ролями. И слой MCP-серверов — адаптеров, через которые агенты ходят во внешние системы.

Универсальных агентов не существует — связка делается под каждый проект

Это, пожалуй, самый важный тезис всей статьи, и именно на нём большинство людей спотыкается. Универсальных агентов и универсальных скиллов не существует. Попытка сделать одного «умного агента на всё» заканчивается раздутым контекстом, размазанными инструкциями и посредственным результатом на любом конкретном проекте.

Правильный подход — под каждый проект собирать отдельную связку «команда + саб-агенты». Под «командой» я имею в виду команду в терминах Claude Code — ту самую /-команду (у меня это /f), которая инжектит в системный промпт список саб-агентов и контекст конкретного проекта: имя базы, namespace, структуру репозиториев, правила. И под этот же проект — свои саб-агенты, у которых контекст короткий, эффективный и не засорён общими фразами — только то, что относится к этому проекту.

Вся эта связка (команда-точка входа плюс набор саб-агентов) должна быть индивидуальной для каждого проекта. Не «один набор на всё», а своя под каждый репозиторий/продукт. Именно поэтому оно работает быстро, эффективно и качественно: агент не тратит контекст на разбор «а к какому из пяти моих проектов это относится» — он сразу в нужном контексте.

Саб-агенты: три роли, не лезущие в чужую зону

У меня три саб-агента, и каждый знает только свою область:

• product — превращает мою формулировку в продуктовые требования, задаёт уточняющие вопросы, режет фичу на подзадачи и создаёт тикеты в GitHub. Кода не пишет.

• backend — пишет Go-код. Telegram webhook, бизнес-логика, MongoDB. Работает только в одном репозитории приложения.

• devops — Kubernetes, конфиги, секреты. В бизнес-логику не лезет.

Технически и команды (вроде моей точки входа /f), и саб-агенты — это обычные markdown-файлы. Разница в том, что в них попадает.

Команда /f подмешивает перед моим запросом большой системный промпт: «ты работаешь над таким-то проектом, вот доступные саб-агенты, вот имя базы, вот namespace в Kubernetes, вот контекст». Это основной контекст выполнения. А саб-агенты — отдельные markdown-файлы, и им на вход уходит не вся переписка, а только конкретная задача.

Это и есть главный приём против деградации на длинных задачах. Контекст идёт «водопадом»: в product заходит полный системный промпт, на выходе он создаёт GitHub-issue с самодостаточной постановкой, и уже эта issue (а не вся история чата) уезжает в backend или devops. Контекст не засоряется, не нужно дёргать /compact, чтобы его сжать, и агенты остаются вменяемыми даже на сложных фичах.

MCP: руки и глаза агентов в реальной инфраструктуре

Без MCP-серверов LLM — это просто умный собеседник. Чтобы он мог что-то делать в реальном мире, под каждую внешнюю систему нужен адаптер. У меня их семь:

• GitHub — агент сам открывает и закрывает issue, создаёт pull request’ы, управляет доской.

• Kubernetes — смотрит поды, читает логи, может рестартнуть деплоймент и проверить, что выкат докатился.

• MongoDB — заглядывает в базу напрямую запросом, а не глазами через mongo-shell: есть ли запись, корректны ли данные.

• DigitalOcean — инфраструктура, DNS и прочее.

• Serena — навигация по коду через синтаксическое дерево, а не grep. «Найди все вызовы такой-то функции» — точный список за секунду.

• Sequential Thinking — заставляет агента «подумать вслух» перед действием: он прогоняет промпт через несколько итераций рассуждения, расширяет его на edge-кейсы. Меньше галлюцинаций, осмысленнее решения.

• Context7 — свежая документация по библиотекам и API. Я не даю агенту угадывать сигнатуры — заставляю свериться с актуальными доками.

Без MCP это умный чат. С MCP — это руки и глаза AI в твоей инфраструктуре.

Pipeline по этапам

Пройдёмся по живому циклу на примере добавления простой фичи.

1. Планирование

Я формулирую задачу и кидаю промпт через /f. General-purpose агент понимает, что это новая фича, и зовёт product-агента. И вот тут важная деталь, которую обычно пропускают: product не бросается кодить. Он ведёт себя как нормальный коллега — задаёт уточняющие вопросы по объёму и поведению.

Я отвечаю, он итерируется. Это и отличает AI-команду от просто LLM — продуктовая проработка до того, как тронут код.

2. Постановка задач

Когда требования ясны, product создаёт эпик в отдельном репозитории с продуктовыми требованиями (без кода) и режет его на подзадачи. У каждой подзадачи:

• ссылка на родительский эпик через GitHub Sub-issues;

• метка исполнителя — [backend] или [devops];

• готовый ready-to-run промпт прямо в теле задачи: что делать, где файлы, как тестировать, по какому маршруту PR;

• статус Backlog на доске GitHub Projects.

Зачем класть промпт прямо в issue? Чтобы саб-агент брал задачу и работал по ней, не таща за собой основной контекст. Дирижёр остаётся чистым, вся специфика — в тикете.

И вообще — зачем создавать таски в GitHub, если можно просто кинуть промпт в чат? Во-первых, так агент может продолжить работу, даже если прервался или застрял на середине. Во-вторых, появляется хранилище: можно строить отчёты, что и за какой срок было сделано. По сути мы моделируем рабочий процесс живой команды, только в автоматическом режиме.

3. Выполнение

Когда план готов, я пишу «да, начинай». Дальше руками ничего не запускаю — основной контекст сам разбирает план, видит порядок подзадач и метки исполнителей и спавнит нужного саб-агента. Сначала backend, потом, если надо, devops.

Про многозадачность одна оговорка: в рамках одной продуктовой задачи всё происходит в одном окне контекста — там и product, и backend, и devops. Я не открываю их руками по вкладкам. Несколько окон (через Claude Squad) я держу только когда веду параллельно разные продуктовые таски. Внутри одной фичи — один контекст.

4. Код ревью

Каждый PR ревьюит человек. Не AI-ревьюер, не автоматика — я лично. Агент пишет код, гоняет сборку и тесты, открывает PR в ветку dev и останавливается. Не мержит. Ждёт меня.

PR можно глянуть хоть с телефона. Если что-то странное — оставляю комментарий, агент перепишет. Если ок — апрув, агент мержит.

Смысл ревью не в синтаксисе — современная модель почти не делает синтаксических ошибок. Смысл в бизнес-логике. Чем больше у агента самостоятельности, тем дороже его ошибка, и ручное ревью — это страховка, которая делает весь pipeline предсказуемым. Без ревью это уже не AI-команда, а лотерея. Особенно для проектов с чувствительным продакшеном.

5. Деплой

Flow двухступенчатый:

1. merge в dev → автоматический деплой через GitHub Actions в отдельный namespace dev (свой тестовый бот, своя база);

2. я проверяю фичу руками через UI на dev-окружении;

3. PR из той же ветки в main → снова ревью → merge → деплой на прод.

Почему Kubernetes — не потому что «лучший выбор», а потому что у меня уже есть Kubernetes кластер, и в моей конфигурации это дешевле, чем managed-платформы. Если аппетита к k8s нет — тот же pipeline собирается на managed-решениях, MCP под них тоже есть. На деплое Kubernetes MCP даёт агенту возможность самому проверить статус выката и логи, а MongoDB MCP — данные в базе.

Если бы задача была сложной и что-то не заработало с первого раза — мы бы поймали это на dev, проитерировались (агент посмотрел бы логи, я сказал бы, что исправить), и всё это не задевая продакшен-пользователей. В этом вся ценность dev-ступени.

Три детали, без которых схема не заводится

1. User-аккаунт на GitHub, а не GitHub App / бот. Я завёл отдельный аккаунт-пользователя на GitHub и дал ему админ-права в организации проекта. Именно полноценный user, не GitHub App и не bot-token. Причина прагматичная: у ботов и App урезанный API — часть операций (например, корректное обновление статуса на доске GitHub Projects) у них работает криво или недоступна. User-аккаунт же может управлять секретами, организацией, создавать репозитории, мержить — всё, что нужно для по-настоящему автономной работы.

2. Claude Code на VPS, а не на ноутбуке. Claude Code работает на сервере с Claude Squad. Длинные задачи на 30–60 минут идут в фоне и не зависят от моего ноутбука, мигающего Wi-Fi или VPN. Поставил задачу, закрыл крышку макбука, уехал пить кофе — выполнение продолжится. Неочевидный бонус: с телефона через Termux (или похожее приложение) я подключаюсь по SSH к серверу, кидаю простой промпт, а ревью делаю прямо в мобильном приложении GitHub. То есть могу довести задачу до прода буквально с iPhone. И все MCP-серверы с доступом к базам — оттуда же, по приватной сети, без проброса портов с домашнего компа.

3. Одна GitHub-организация на проект. Под каждый проект — отдельная организация, куда заинвайчен тот самый агентский user с админ-правами. Это даёт чистую изоляцию: код, секреты, доска — в своих границах. А саб-агенты знают только свою организацию, так что «случайно закоммитил не туда» физически не случается.

Итог

AI-команда из трёх агентов закрывает полный цикл: от продуктовой идеи до прод-деплоя. Я остаюсь продактом и тех-лидом — формулирую задачи и ревьюю код. Планирование, разбивку на тикеты, имплементацию, тесты, деплой и мониторинг делает AI через MCP.

Это не волшебная палочка. Чтобы оно завелось, нужно: настроить MCP-стек, прописать саб-агентов с чёткими ролями и правилами, выстроить pipeline dev → main с обязательным человеческим ревью, запустить Claude Code на сервере и использовать user-аккаунт на GitHub.

Но когда это собрано — оно работает каждый день, а не в демо. Конфиги саб-агентов и команды-точки входа я выложил в gist, можно адаптировать, заменить плейсхолдеры на свои ID и использовать у себя:

https://gist.github.com/ne-robot/f0ac647f7182d7ce996434a32bde5be9

Если интересно — задавайте вопросы в комментариях, отвечу по конкретике сетапа.

Бонус: видеоверсия