Как превратить намерение пользователя в управляемую эволюцию продукта

Дата публикации: 2026-05-19

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

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

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

Это не означает, что пользователи должны напрямую управлять продуктом. И это не означает, что любой пользовательский запрос должен автоматически превращаться в код. Здесь речь о более осторожной и управляемой схеме.

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

Такой подход заставляет по-новому посмотреть на сам процесс развития продукта.

Рисунок 1. Управляемый путь от пользовательского намерения к изменению продукта. Подписи внутри схемы пока даны на английском, но её смысл раскрыт в тексте ниже.

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

1. Пользовательское намерение как недооценённый источник изменений

Любой продукт меняется потому, что кто-то хочет его изменить.

Пользователь замечает баг. Заказчику не хватает функции. Тестировщик видит неочевидное поведение. Разработчик понимает, что документация уже не соответствует продукту. Всё это не просто шум вокруг системы. Это сигналы о том, как продукт может эволюционировать.

Сегодня большинство таких сигналов проходят длинный ручной путь.

Пользователь пишет отзыв, отправляет сообщение, заводит тикет или задачу в трекере. Кто-то в команде читает это, интерпретирует, решает, насколько это важно, превращает в задачу, передаёт в разработку, ждёт реализации, проверяет результат и в конце принимает или отклоняет изменение.

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

ИИ-агенты могут этот путь сократить.

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

Ключевое слово здесь: управляемый.

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

2. Владелец продукта не должен терять контроль

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

Пользователи часто видят реальные проблемы, но они не обязаны видеть продукт целиком.

Один запрос может улучшить один сценарий и испортить другой. Маленькое изменение может нарушить архитектурное правило. Хорошая идея может противоречить продуктовой стратегии. А вполне разумный запрос может просто оказаться не тем следующим шагом, который сейчас нужен продукту.

Именно поэтому не каждый пользовательский запрос должен превращаться в код.

Небезопасная трактовка звучит так: пользователь создаёт задачу, а ИИ-агент автоматически меняет продукт.

Но статья предлагает не это. Более надёжная модель выглядит иначе:

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

Рисунок 2. Маршрутизация запроса после проверки границ. Подписи на схеме пока на английском, но различие между небезопасным и безопасным маршрутом пояснено в тексте.

Это различие принципиально.

Делегирование - не отказ от контроля. Делегирование означает, что владелец продукта заранее решает, какие решения агент может принимать сам, а какие обязательно нужно поднимать на уровень человека.

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

3. Разрешённые маршруты изменений

Чтобы агенты были и полезными, и безопасными, владелец продукта должен определить разрешённые маршруты изменений.

Изменения такого типа допустимы, если они укладываются в эти границы и проходят эти проверки.

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

Это не означает, что каждое изменение будет автоматически влито в основную ветку. Это означает, что агенту разрешено начать работу без отдельного управленческого решения в каждом конкретном случае.

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

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

Именно здесь документация перестаёт быть просто пассивным описанием продукта. Она становится практическим инструментом управления.

Чем лучше владелец продукта описывает продукт, тем безопаснее становится делегирование работы агентам.

Без чётких ограничителей автономия агента рискованна. С чёткими ограничителями она превращается в практический инструмент.

4. ИИ-агенты как делегированные посредники

В этой модели ИИ-агент - не просто помощник программиста.

Он выступает делегированным посредником между пользователями и владельцем продукта.

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

Рисунок 3. Агент как делегированный посредник. Надписи на схеме пока на английском, но роли участников подробно разобраны в этом разделе.

Если запрос укладывается в разрешённые границы, агент может его обработать: проанализировать задачу, составить план, изменить код, создать pull request, то есть запрос на включение изменений, и зафиксировать сделанное.

Если запрос неясен, рискован или затрагивает границы продукта, агент не должен гадать. Он должен остановиться, кратко описать ситуацию и запросить решение у владельца продукта.

Если запрос явно противоречит направлению развития продукта, агент должен его отклонить или пометить для обсуждения.

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

В этом и состоит ключевой сдвиг.

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

5. Событийный рабочий процесс как модель исполнения

Чтобы это было не только красивой идеей, работа агента не должна зависеть исключительно от ручных чат-сессий.

Чат полезен для обсуждения, исследования и обдумывания. Но для изменения продукта нужно нечто более стабильное: процесс, который можно наблюдать, повторять, проверять и при необходимости разбирать постфактум.

Репозитории исходного кода уже дают для этого хорошую основу.

Пользователь создаёт задачу. Ей присваивается метка. Появляется комментарий. Открывается pull request, то есть запрос на включение изменений. Публикуется проверка коллегой. Затем происходит слияние. Каждое из этих действий может породить событие.

Событийный рабочий процесс использует такие события, чтобы продвигать задачу по управляемой цепочке. Задача фиксирует пользовательское намерение. Событие в репозитории запускает процесс. Движок рабочего процесса проверяет правила и выбирает следующий шаг. Если запрос допустим, ИИ-агент стартует в ограниченном рабочем окружении. Агент выполняет задачу и записывает результат обратно в репозиторий.

Рисунок 4. Архитектура событийного рабочего процесса для агентов. Подписи на схеме пока на английском, но последовательность шагов описана в тексте.

Результатом может быть pull request, комментарий, метка, результат проверки или любой другой видимый след выполненной работы.

Это отличается от ситуации, когда вы просто пишете модели в чат: "почини это".

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

Каждый шаг что-то означает. Каждый переход можно проверить. Каждое решение можно зафиксировать.

Именно так делегирование превращается в инженерную практику, а не в красивую умозрительную схему.

6. Доказательства делают автономию подотчётной

Автономия агента приемлема только тогда, когда его действия остаются видимыми.

Если ИИ-агент меняет продукт, владелец продукта должен иметь возможность ответить на базовые вопросы:

Именно поэтому доказательства так важны.

Задача фиксирует исходный запрос. Метка может показывать текущее состояние. Комментарий может объяснять решение агента. Pull request показывает фактическое изменение кода. Результат проверки показывает, пройдены ли нужные этапы контроля. А человеческая проверка фиксирует принятие или отклонение результата.

Без такого следа работе агента трудно доверять.

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

Владельцу продукта уже не нужно вручную делать каждую мелкую операцию. Но он должен иметь возможность посмотреть, как устроен процесс, изменить правила, остановить опасное поведение и решить, что действительно попадёт в продукт.

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

Задача рабочего процесса - не только автоматизировать работу. Его задача ещё и сделать делегированную работу подотчётной.

7. ADSM и github-flows: от идеи к работающей системе

Для такого подхода нужны два слоя.

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

Это и есть роль ADSM (Agent Driven Software Management).

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

Второй слой - технический. Процесс должен быть исполнимым.

Здесь и появляется @teqfw/github-flows.

@teqfw/github-flows - это технический слой этой идеи. Библиотека связывает события GitHub с работой агентов: она реагирует на действия в репозитории, проверяет правила процесса, запускает CLI-агентов в изолированных средах на базе Docker и возвращает результат обратно в репозиторий через задачи, pull requests, метки, комментарии и артефакты-доказательства.

При необходимости поверх неё можно использовать github-flows-app - экспериментальную веб-обвязку, которая делает этот механизм удобнее для практического запуска.

Для этой статьи важен не столько внутренний состав инструмента, сколько сам факт: такая схема уже исполнима не только в теории, но и в коде.

Сейчас я использую этот подход в реальном GitHub-репозитории: viktor-gusev/dnd-game-master. Задачи #17, #19 и #21 были обработаны агентами внутри этого процесса.

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

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

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

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

Будущее агентной разработки связано не только с тем, чтобы сделать агентов сильнее.

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

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