ИИ-продакт — следующий уровень автономности или избыточная бюрократия?

Я построил автономную систему с ИИ-продактом и командой агентов-исполнителей, которая круглосуточно в несколько потоков закрывает задачи продуктового бэклога. Делюсь опытом, как я пришёл к такой схеме, и что из этого получилось.

Агентизацию разработки я начал с мультиагентного конвейера, где каждому агенту назначается роль аналитика, архитектора, разработчика и т.п. Такой конвейер позволял решать разовые задачи от и до и сводить разработку к работающему результату. Мой подход описан в статье "Мультиагентная разработка...", а актуальная доработанная версия пайплайна для Codex / Claude / Cursor доступна в git.

Затем я построил вокруг этого конвейера систему задач как средство для долговременного хранения контекста — предыдущих наработок, путей принятия решений, направлений развития продуктов и сервисов. Это позволило агентам опираться не только на код, но и на свой опыт решения предыдущих задач, что сильно повысило качество принимаемых решений и скорость восстановления контекста. Я смог параллельно и независимо запускать разные задачи и отслеживать прогресс работы по этим тредам. Такой task-ориентированный подход описан в статье "Task-first агентная разработка...", а шаблон окружения можно взять в git.

Однако через какое-то время направлений работы стало так много, что когнитивно стало тяжело оставаться в контексте. Я стал забывать, над какими задачами мы работаем, где остановились, что хотели брать в следующую очередь. Частично проблему решил наглядный каталог (индекс) задач, но всё равно в голове нужно было держать очень много информации. Я пришёл к тому, что в понедельник с большим трудом восстанавливал контекст с прошлой недели и начинал терять нить работы. К тому же агенты часто сталкивались с препятствиями — как инфраструктурными проблемами, так и с продуктовыми вопросами. Работа блокировалась, они приходили ко мне с уточнениями, большинство из которых были достаточно простыми. Мне стало это напоминать игру «Весёлый фермер» — квинтэссенцию микроменеджмента, где нужно одобрять простейшие действия и так и хочется поверх всего этого беспредела поставить нормального «управляющего», который бы принимал простые решения, а за мной остались бы стратегические вопросы.

Почему исполнители заходили в тупик? Проблема в том, что, как и у большинства людей-разработчиков, контекст исполнителя ограничен задачей, которую он выполняет. Ему либо недоступна широкая информация, либо просто нет ресурсов (и иногда желания) погрузиться в предметную область. В итоге, даже если получается реализовать ТЗ, задача конечного пользователя может быть не решена.

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

Выход модели Claude Opus 5, которую позиционировали как ещё более сильную, чем GPT 5.6 sol, прибавил мне уверенности, и я решил поставить такой эксперимент — запустить ИИ-продакта на Opus 5, а разработку вести двумя провайдерами сразу: Codex на GPT 5.6 sol и Claude на Opus 5. Ключевое правило — жёсткое кросс-ревью: что написал Codex, проверяет Claude, и наоборот. Автор себя не проверяет никогда: если положенный проверяющий недоступен, например, по исчерпании лимита подписки, работа останавливается. Фокус ИИ-продакта направлен именно на верхнеуровневое продуктовое видение и поддержку ИИ-исполнителей по их частным вопросам. Я предполагал, что ИИ-продакт сможет независимо разгребать бэклог задач, обращаясь ко мне только по тем вопросам, где ответ не очевиден. В остальном вся эта схема должна работать круглосуточно в несколько параллельных потоков.

Спойлер: эксперимент я считаю частично успешным. ИИ-продакт самостоятельно закрыл много задач из бэклога: получил работающий функционал, выполнил приёмку доработок именно с учётом задачи конечного пользователя, по новым вопросам и найденным проблемам добавлял задачи в бэклог и планировал их работу. Масштаб для ориентира: за неделю в четырёх направлениях было выполнено около 350 задач, примерно поровну на Codex и Claude.

За 1600 сеансов работы моделей потрачено около 14 млрд токенов. Основной вопрос — в эффективности, но об этом ниже. Сначала опишу чуть подробнее, как построена работа.

Схема работы

Основная часть работы с ИИ-агентами у меня проводится на VPS через CLI (ssh). Также есть канал через Telegram и почту.

Агенты имеют полный доступ к операциям на сервере, но подчиняются жёстким правилам, что можно делать, а что нельзя. Такая схема работает почти полгода и ни разу не давала сбой.

До запуска продакта я в основном держал несколько открытых терминалов, где вёл работу по параллельным задачам. Чтобы не требовалось постоянно смотреть в терминалы, уведомления о статусах задач, в том числе блокировки, приходили мне пушами в мессенджере. Также через мессенджер можно поставить задачу или дописать комментарий к имеющейся.

Но продакт — это, по сути, одна точка входа. И тут важнее оперативный доступ к истории принятых решений и отчётов о выполнении задач. Линейный тред, как в чате или мессенджере, быстро забивается лишним контекстом, в нём потом сложно найти информацию. Поэтому я решил сделать основным каналом общения старую добрую электронную почту. Я завёл продакту отдельный почтовый адрес, с которого он присылает мне верхнеуровневые статусы и вопросы. Также я могу просто написать ему письмо с просьбой подготовить отчёт в определённом формате, взять в работу уточнения по задачам или новое направление. Интересно, что я практически не пользуюсь электронной почтой для общения с коллегами. Но в данном случае этот канал полностью себя оправдывает. Я могу в удобное время открыть почтовый клиент и спокойно читать отчёты.

Но помимо удобства почта несёт дополнительные риски: письмо — это вход, который будит агента с полными правами на сервере. Поэтому входящее письмо сначала проходит проверку отправителя — точный адрес плюс совпадение подписи DKIM/SPF/DMARC — и только после этого его текст попадает в модель. Всё, что внутри письма (пересланные куски, цитаты, вложения), считается непроверенным источником: продакт исполняет только мою собственную просьбу, а не инструкции, найденные в теле письма.

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

С ИИ-командой такой подход работает плохо. Во-первых, нет привычных синков, на которых можно в сжатое время получить детальную картину того, что происходит в продукте. Во-вторых, и это уже скорее особенность классической команды сотрудников, на подготовку красивых отчётов и актуализацию досок тратится время и внимание, людям сложно оперативно актуализировать информацию и готовить наглядные презентации. А вот ИИ-команде это сделать, наоборот, очень просто. Поэтому ИИ-продакт разработал для меня наглядный процессный дашборд, на котором в реальном времени видно всю карту работы над задачами.

Важная деталь: доска показывает только наблюдаемое — живые процессы по pid, свежесть файлов прогресса, статусы задач, коммиты. Ярлык «в работе» в чьём-нибудь статус-файле ничего не значит, если процесс мёртв, а файл не менялся час. Из того же наблюдения выросло правило, которое я считаю одним из самых полезных во всей схеме: отсутствие прогресса при доступной работе — это дефект. Если очередь не пуста, а живых исполнителей ноль, продакт обязан либо запустить работу, либо сообщить мне причину простоя: кончился лимит, занято рабочее дерево, нет проверяющего или ожидается мой ответ. Молчаливого простоя не бывает — это то, чего мне больше всего не хватало, когда я сам ходил по терминалам. Интересно, что продакт и сам пользуется доской, которую разработал.

Характер моей работы после внедрения этой схемы изменился кардинально. Если раньше я тратил много времени на контроль конкретных задач и писал в терминал, то теперь я в основном читаю то, что получилось у ИИ-продакта и команды (технические отчёты), думаю над дальнейшими шагами и изредка пишу ответы на концептуальные вопросы и постановку новых задач. Концентрация внимания, которая нужна была для контроля происходящего до внедрения ИИ-продакта, резко сократилась. А интенсивность аналитической работы, наоборот, максимально выросла.

Проблемы

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

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

Поэтому по прошествии недели мы провели с ИИ-продактом ретроспективу и выделили основные сложности в организации процесса.

1. Бюрократические преграды — ИИ придумывает новые критерии завершения задач, усложняет процесс

Какая связь между ИИ и бюрократией? Дело в том, что ИИ-исполнителям надо давать чёткие критерии, когда считать задачу выполненной (гейты, DoD), в каких ограничениях выполнять задачу (constraints), в каком виде доставлять результат (контракты). Необходимость введения таких критериев я обнаружил ещё на этапах создания мультиагентной схемы и task-ориентированного подхода. Без чётко оговорённых правил ИИ будет каждую новую задачу решать так, как ему захочется, и результат получится непредсказуемый. Именно введение правил позволяет получать прогнозируемые результаты.

Но ИИ склонен к переусложнению. Это часто видно и в написании кода (оверинжиниринге), и в организации процесса. В некоторых случаях доходило до того, что ИИ придумывал правила, которые сам же не мог выполнить. Задача ходила по кругу, токены сжигались, а результат не достигался.

2. Дрейф целей и ограничений

Как сформулировал сам ИИ-продакт: «Мы защищали придуманное правило». Были случаи, когда ИИ выдумывал ограничения (например, количество циклов запуска бенчмарка — условно дорогой процедуры), которые не вводил пользователь. Это обнаруживалось в отчётах, и я указывал ИИ-продакту, что таких ограничений я не вводил. После чего он удалял такие правила, и работа продолжалась штатным образом.

3. Дробление работы до потери смысла

ИИ-продакт настолько увлёкся заведением задач, что на каждое ревью, каждое замечание заводил отдельную задачу, по которой также требовалось пройти определённые критерии её завершения. Вместо того чтобы продолжать в том же треде и быстрее дойти до осязаемого результата, продакт множил процессную работу, создавал излишние взаимные блокировки между работами и в целом сильно замедлял таким образом полезную работу.

4. Контроль качества стал важнее доставки

Как по части соблюдения процесса, так и в части контроля качества продукта продакт иногда демонстрировал параноидальную склонность к перестраховке. Это приводило к тому, что задачи многократно возвращались на доработку с комментариями: «А давай проверим ещё и вот это». Хотя проверяемые случаи были настолько незначительными и низкочастотными, что не давали никакой ценности продукту.

Либо другое проявление этой же проблемы — семь раз за трое суток продакт спрашивал у меня разрешения на очевидное: сделать следующий замер, доставить готовый отчёт, поставить ревью, перезапустить упавший прогон, воспользоваться токеном, который уже лежал на сервере. Каждый такой вопрос стоил ночи простоя готовой работы — ради решения, у которого и не было второго варианта.

Что мы поменяли после ретроспективы

Хорошие новости заключаются в том, что ни одна из проблем не выглядит неразрешимой. Отчасти такие проблемы являются следствием адаптивности всех частей процесса. Задействованные в работе ИИ-агенты делают выводы из собственных неудач и могут скорректировать процесс. Проблема состоит в их избыточном рвении сделать всё идеально — и это всё ещё остаётся моей зоной контроля, чтобы не допускать системе сваливаться в работу ради работы.

За пару дней после ретроспективы мы внесли четыре изменения, каждое из которых бьёт по конкретной проблеме из списка выше.

Одна цель — одна задача. Реализация, внутреннее ревью, независимое кросс-ревью, доработка и завершение перестали быть отдельными задачами и стали фазами одной. На доске больше не появляется новый номер на каждое замечание. Это прямое лекарство от дробления.

Передача проверяющему стала автоматической. Раньше кросс-ревью назначал и запускал продакт, теперь задача сама уходит от Codex к Claude, возвращается автору с замечаниями и перепроверяется без моего участия. Правило «автора проверяет другой провайдер» из регламента превратилось в механику. Вообще, максимальное превращение описанных словами навыков и правил в чёткие механики, реализованные в коде и скриптах, с одной стороны, экономит токены, а с другой — не даёт модели думать (и придумывать лишнее) там, где это не требуется.

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

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

Отдельных усилий потребовала борьба с переусложнением. Мы провели отдельный брейншторм, в результате которого принципы простоты и надёжности были добавлены во все уровни принятия решений. За основу формулировок взяли Aglile Manifesto и Google SRE (SRE Book и Workbook).

После всех улучшений мы провели с моим ИИ-продактом повторную ретроспективу, которая показала хороший прогресс. Доля процессных задач снизилась с 75 до 25%. Токены стали расходоваться более оптимально. Изначально сформулированные проблемы практически перестали проявляться.

На данный момент основным направлением является дальнейшая оптимизация расхода токенов на работу продакта и процессный контур. На текущий момент доля продакта в расходе токенов составляет около 40%, причём это в основном чтение контекста, а не генерация, соотношение примерно 200:1. И поскольку чтение превалирует, критически важно найти баланс, чтобы, с одной стороны, у продакта был достаточный контекст для принятия качественных решений, а с другой — исключить повторяющееся чтение избыточной информации, сделать контекст более адаптированным под каждую конкретную задачу и не допускать разрастания его нерелевантной части.

Подводя итог, можно сказать, что качественное делегирование задач ИИ-продакту существенно повышает расход лимитов. Но при этом открывает возможность делать намного больше параллельной работы. Более спокойный режим работы позволяет сфокусироваться на глубокой проработке решений, расширить свой контекст и увидеть возможности, на которые в режиме «Весёлого фермера» не хватило бы ни времени, ни внимания.