Ролевой пайплайн для ИИ-разработки это несколько ИИ-ролей с разными зонами ответственности, которые ведут один проект вокруг общего файла-плана. В разобранном кейсе ролей пять: архитектор, планировщик, кодер, ревьюер и менеджер. Архитектор и планировщик раскладывают задачу, кодер пишет код, ревьюер проверяет результат против плана, менеджер запускает цепочку по очереди.
Появилась эта конструкция не от хорошей жизни. Разработчик, который её собрал, пришёл из области баз данных и фронтенд не писал. Осенью 2025 года он взялся сделать с помощью ИИ практический сайт: CRM для знакомых, занимающихся прокатом машин и обучением вождению. Позже у той же CRM появилось второе направление, для аэроклубов. Хронологию и детали автор описывает в исходной публикации.
Стек выбирался между TypeScript с нагрузкой на фронтенд и Python Django, который собирает страницы на сервере. Django показался проще, на нём и остановились. Работа с моделями поначалу шла в чатах: сначала бизнес-требования (BRD) и описание архитектуры, потом код по этим документам.
Главная проблема оказалась в понимании задачи. Договаривались об одном, модель по ходу дела трактовала иначе и делала другое. Роли и общий план стали ответом именно на это: удержать одинаковое прочтение задачи и не потерять его при сжатии контекста.
Волшебного ускорения ждать не стоит. Пайплайн замедляет работу на документации и требует ручного контроля, когда модель уходит в сторону. Дальше конкретика: даты, примеры и цена подхода.
Суть пайплайна: зачем роли, если есть один хороший промпт
Один хороший промпт решает одну задачу. Пайплайн нужен там, где задач много, они связаны и решение придётся поддерживать месяцами. Роли в такой схеме делят ответственность примерно как небольшая команда, только вместо людей оболочки консольных агентов с разными инструкциями.
Что именно ломалось в работе с одним чатом
Первый формат был обычным: чат, в нём BRD и описание архитектуры, по ним код. Документы писались в Gemini, и он плохо справлялся с правками: делал изменения неправильно, что-то перезатирал. Каждый шаг приходилось перепроверять.
Второй сбой связан с памятью. Знания между чатами переносились вручную. Сжатие контекста работало хуже, чем нужно, поэтому автор делал выжимки, куда-то их записывал и переносил в новый тред. Каждый новый чат начинался с восстановления договорённостей, а не с работы.
Третий сбой проявился на рефакторинге общих ресурсов. Он разобран ниже, в разделе про статусы и самопроверку, и там же видно, почему одного промпта не хватило.
Кому этот разбор полезен, а кому нет
Полезен тем, кто уже гоняет консольные агенты на реальном проекте и упирается в потолок: контекст теряется, модель забывает договорённости, код обрастает случайными решениями. Полезен и тем, кто думает, как передать проект другому человеку или самому себе через месяц.
Не полезен тем, кто ищет обзор моделей или готовый фреймворк с установкой в две команды. Это разбор самодельной системы одного разработчика, с его стеком, его ограничениями и его ошибками. Копировать роли один в один смысла мало, забирать стоит принципы.
От чатов к консольным агентам: как появились роли
После первых неудач автор месяц смотрел по сторонам и пробовал топовые консольные агенты. Codex CLI понравился сразу: делал задачи без долгих уговоров и попутно учил командам. Ripgrep автор узнал именно от него. О переходе от чатов к CLI рассказано в самом кейсе.
Роли оформлялись как врапперы вокруг консольных агентов: оболочка задаёт роль, отдаёт ей инструкции и доступ к файлам проекта. В том же классе инструментов работают Claude Code и GLM, выбор оболочки определяет, какие команды и какой доступ к файловой системе получает роль. Похожий путь прошёл другой разработчик: пет-проект на Java превратился в оркестратор задач с CLI-сессиями Claude Code, tmux и веб-дашбордом, и там же видны метрики, которые пришлось пересматривать.
В декабре 2025 года появилась первая версия пайплайна: четыре роли, архитектор, планировщик, кодер и ревьюер, запуск ручной. Каждый переход между ролями разработчик инициировал сам.
Почему ручной запуск ролей быстро стал автоматическим
Ручной запуск означает много переключений: закончил архитектор, надо это заметить, запустить планировщика, потом кодера, потом ревьюера, и так на каждом шаге. На длинной задаче человек становится узким местом и заодно источником пропущенных шагов.
В январе добавилась роль менеджера, и запуск стал автоматическим. Менеджер ведёт роли по очереди вокруг плана: смотрит, какой шаг следующий, поднимает нужную роль, принимает её результат. С тех пор, по словам автора, пайплайн развивается.
Автоматизация не отменяет человека. Она снимает рутину переключений, но при отклонении от плана всё равно нужен ручной разбор.
Координирующий артефакт: план, который читают и дописывают все
Центр системы - файл в репозитории. План лежит рядом с кодом, каждая роль читает его перед стартом и дописывает после работы: что сделано, какие решения приняты, что осталось, какие появились вопросы.
Это и есть практическое управление контекстом LLM в разработке. Договорённости хранятся не в истории треда, а в файле, который модель перечитывает. Тред можно потерять, сжать, открыть заново в другом инструменте. План остаётся.
Как план переживает сжатие контекста
Сжатие контекста вымывает детали первым делом: почему выбрали такую структуру, что решили не делать, какие ограничения обсуждали. В обычном чате это значит, что через десять сообщений модель снова предлагает отвергнутый вариант.
С планом механика другая. Роль стартует, читает файл и получает актуальную картину, включая явные запреты и уже принятые решения. Раньше автор делал такие выжимки руками и переносил между тредами, теперь это часть процесса, и делает её сама роль.
План не гарантирует, что модель не ошибётся. Он гарантирует, что ошибку видно: если результат расходится с записанным в плане, это заметно при сверке.
Статусы и самопроверка: как роли понимают, что работа сделана
У задач в плане есть статусы. Роль перед передачей дальше сверяет результат с записанным: шаг закрыт или нет, все ли пункты выполнены. Самопроверка нужна потому, что отчёт модели и реальный результат расходятся регулярно.
Самый показательный пример случился в ноябре. Автор рефакторил общие ресурсы для машин, инструкторов и площадок: формы Django у них похожие, механики одинаковые, хотелось максимального переиспользования кода. Codex отчитался, что всё сделал. При проверке оказалось, что поменялись имена и местами что-то схлопнулось, а кардинальной переделки не было. Ревью ничего не изменило, повторный запуск в других чатах со второго раза тоже почти ничего не дал. Четыре круга закончились отказом от подхода. Как это происходило, автор разбирает отдельно.
Вывод простой: отчёт модели не результат. Результат это проверенный код и обновлённый статус в плане, а разделение генерации и проверки на разные роли нужно как раз для того, чтобы эту разницу замечать.
Роли по отдельности: кто за что отвечает
Роли не изолированы, их связывает общий артефакт. Переписка в чате вторична, важно, что попало в план.
Архитектор и планировщик: от требований к шагам
Архитектор отвечает за структуру решения: какие сущности, какие связи, какие ограничения. На входе у него BRD и описание архитектуры, на выходе раздел плана с решениями и явными запретами.
Планировщик берёт этот раздел и режет работу на шаги с понятными критериями готовности. Критерий готовности важнее формулировки шага: если не написано, что считать результатом, кодер додумает трактовку по-своему и уедет в сторону. Именно так и появлялась проблема с «поняла не так».
Кодер и ревьюер: сделать и проверить
Кодер реализует один шаг из плана и обновляет статус. Ревьюер сверяет результат с планом и возвращает на доработку, если расходится. На этом стыке ловится ситуация из кейса, когда задача формально закрыта, а по сути не сделана.
Разнос обязанностей совпадает с общей идеей разделения предложения и утверждения: ИИ предлагает изменение, человек утверждает, исполнитель применяет только допущенное. Похожую логику фиксирует методология Agent-Ops, публичный нормативный кандидат с восемью шагами процесса и ролью Guardian. В самодельном пайплайне эту функцию частично берёт на себя ревьюер, частично человек при приёмке.
Менеджер: оркестрация и автоматический запуск
Менеджер появился в январе и сделал запуск автоматическим. Его работа это очередь: определить следующий шаг по плану, поднять нужную роль, проверить, что статус обновился, двинуться дальше. Пока всё идёт по плану, человек может заниматься другим.
Как только результат расходится с планом или шаг упирается в архитектурный вопрос, автоматический цикл останавливается и нужен человек. Автор описывает это как штатную ситуацию, а не сбой.
Golden paths и doc gardening: как пайплайн не зарастает мусором
Golden paths это эталонные пути решения типовых задач. Вместо того чтобы каждый раз изобретать подход к новой форме или новому разделу, роль получает описанный образец: как в этом проекте принято делать такие вещи. Модель меньше импровизирует, ревьюеру есть с чем сравнивать.
Doc gardening это регулярная работа с документацией: чистить, обновлять, убирать устаревшее. Документация в пайплайне не побочный продукт, а входные данные для ролей. Если она отстала от кода, роли работают по устаревшей карте.
Структурировать работу через директории и markdown-файлы вместо оркестратора можно и без пяти ролей: разбор Interpretable Context Methodology показывает, как заменить фреймворки структурой папок и промптами, что такой подход ускоряет и где ломается.
Журнал изменений как часть управления контекстом
Журнал фиксирует существенные изменения логики и решений, а не каждый дифф. Дата, автор, что изменилось, почему, как проверялось. Для вайбкодинг-решений это критично: ИИ меняет логику быстро, и без фиксации через месяц никто не скажет, почему приложение ведёт себя иначе и какая версия сейчас работает. Практику ведения такого паспорта решения разбирают отдельно.
Для ролей журнал это ещё один источник правды рядом с планом: из него видно, какие решения уже приняты и какие отменены.
Триаж предложений по улучшению процесса
Идеи по улучшению пайплайна появляются постоянно, в том числе от самих моделей. Если принимать всё, система за пару недель обрастёт ритуалами и станет медленнее задачи, которую решает. Поэтому предложения проходят триаж: отсеиваются, откладываются, принимаются.
Отсеиваются те, что усложняют процесс без измеримой выгоды. Откладываются полезные, но не сейчас. Принимаются те, что снимают конкретную повторяющуюся боль. Так пайплайн развивается, но управляемо.
Когда пайплайн оправдан, а когда достаточно промпта или скилла
Критерий у автора кейса прямой: промпта достаточно, пока решение не нужно развивать, поддерживать или делать командным. Как только появляется хотя бы одно из трёх, одного промпта мало.
Разовая задача, скрипт на вечер, проверка гипотезы: хватит одного промпта или скилла, то есть сохранённой инструкции под повторяющийся тип задач. Городить роли и план здесь дороже, чем сделать и выбросить.
Чек-лист: нужен ли вам пайплайн
- Проект проживёт дольше месяца? Если нет, роли не окупятся.
- Над кодом будет работать кто-то ещё или вы сами через полгода? Общий план и журнал изменений становятся обязательными.
- Цена ошибки модели высока? Чем дороже откат, тем полезнее отдельный ревьюер.
- Готовы тратить время на документацию? Пайплайн живёт на ней, без этого он превращается в набор ритуалов.
- Задачи повторяются? Тогда есть смысл в golden paths.
- Нужна предсказуемость изменений? Роли дают её за счёт скорости.
Границы применимости ИИ в разработке вообще стоит проверять на своих задачах: разбор сценария с магазином за два вечера показывает, как после добавления скидки ломается самовывоз и почему границы надо очерчивать заранее.
Реальные ограничения: время, деньги и ручной контроль
Ограничения стоит назвать прямо, потому что пайплайн продают как ускорение, а на деле это обмен скорости на предсказуемость.
- Замедление на документации. План, golden paths, журнал изменений и doc gardening требуют времени, которое не превращается в строки кода.
- Лимит итераций. Цикл «роль запустил, роль проверила» не бесконечный: после нескольких кругов без результата дешевле остановиться и разобраться руками.
- Стоимость подписок. Несколько консольных агентов и моделей это регулярные платежи, и на разовых задачах они не окупаются.
- Ручной контроль при отклонении от плана. Чем дальше результат от записанного, тем меньше пользы от автоматики.
Где пайплайн всё равно требует человека
Отклонение от плана, спорные архитектурные решения, приёмка результата. В кейсе с рефакторингом именно человек открыл код и увидел, что изменились только имена. Пайплайн сам по себе этого не поймал, поймала проверка.
То же правило работает и за пределами самодельных конструкций: даже удачные эксперименты с длительными задачами ИИ требуют проверки результата, а сложные реальные проекты по-прежнему нуждаются в человеческом контроле. Об этом же говорят разборы возможностей новых моделей.
Что забрать из кейса в свой проект
- Выносить договорённости в файл, а не в историю треда. План в репозитории переживает сжатие контекста, новый чат и смену инструмента.
- Разделять генерацию и проверку. Роль, которая пишет код, не должна сама закрывать задачу.
- Фиксировать существенные изменения логики, а не каждый дифф. Через месяц это единственный способ понять, почему приложение ведёт себя иначе.
- Не строить пайплайн под разовую задачу. Порог входа в роли и план оправдан на длинном проекте.
- Закладывать время на документацию. Golden paths и doc gardening экономят итерации, но не бесплатны.
- Останавливаться после нескольких кругов без результата. Если два подхода подряд не сдвинули задачу, проблема в постановке, а не в количестве попыток.
Кейс собран на Django и CRM для проката машин, обучения вождению и аэроклубов. Стек тут вторичен, принципы переносятся: общий артефакт вместо памяти чата, отдельная проверка вместо доверия отчёту, управляемое развитие процесса вместо бесконечных улучшений.