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

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

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

ИИ-агенту нужна не свобода, а навигация

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

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

Роли — это не пережиток корпоративной иерархии

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

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

Как выглядит конвейер разработки с ИИ-агентами

В любой цепочке процессов разработки (называйте ее схемой, пайплайном, графом — как угодно) есть точка входа, точка выхода и некое количество этапов между ними. Этапы могут идти последовательно, запускаться параллельно и сходиться обратно в одну точку. По сути это классическая блок-схема, или же направленный граф (DAG): узлы-этапы, ребра-переходы, развилки и слияния.

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

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

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

Как устроен конвейер разработки фич в Uplab

Чтобы показать подход на практике, разберем конвейер, который мы используем в Uplab при разработке новых функций. Его задача — не просто ускорить написание кода, а сделать работу ИИ-агентов управляемой и проверяемой.

Конвейер запускается одной командой — /feature. После этого агент собирает требования, формирует технический план, передает задачу в разработку и запускает проверки. При этом его действия ограничены зафиксированными состояниями, ролями и контрольными точками.

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

Для каждой фичи создается отдельный файл:

docs/plans/ГГГГ-ММ-ДД-ЧЧММСС-<ключ>.md

Метка времени показывает, когда началась работа над задачей. Ключ используется в названии документа и Git-ветки, поэтому требования, технический план, код и история изменений связаны одним идентификатором.

В документе находятся постановка задачи и план реализации. Текущее состояние процесса фиксируется в поле Status.

Контекст хранится не в истории чата и не во внутренней «памяти» модели, а в репозитории рядом с кодом. Если разработчик вернется к задаче через несколько дней, новый агент прочитает документ, определит текущий этап и продолжит работу. По файлу можно восстановить, зачем вносилось изменение, какие ограничения учитывались, какие проверки требуются перед выпуском. То же самое сможет сделать другой разработчик или внутренняя команда заказчика. Разработку легко контролировать и передавать.

Два маршрута разработки: fast-track и full-track

Не каждая задача требует полноценного архитектурного проектирования. Поэтому агент выбирает один из двух маршрутов.

Fast-track — для типовых изменений

Быстрый маршрут применяется к задачам с ограниченным техническим риском:

• стандартным CRUD-операциям;

• доработкам по существующим паттернам;

• небольшим изменениям интерфейса;

• локальным исправлениям бизнес-логики;

• добавлению полей и несложных обработчиков.

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

Full-track — для архитектурно значимых изменений

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

На практике архитектурно значимая фича редко живет в одном модуле. При разработке сайта R&D-центров СИБУР «ПолиЛаб» техническое решение затронуло две системы: архитектуру на Node.js с API Bitrix и интеграцию с уже существующим, отдельным карьерным порталом СИБУРа. В такой ситуации системный аналитик отмечает взаимодействие систем до того, как разработчик приступит к коду. Подробнее об этом проекте рассказали в кейсе.

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

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

Разделение ролей между агентами

Одна из проблем разработки с ИИ возникает, когда одна модель одновременно формулирует требования, проектирует архитектуру, пишет код и проверяет себя.

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

Чтобы снизить этот риск, мы разделили конвейер на роли.

Роли строго разграничены по контракту:

• Бизнес-аналитик отвечает за что и зачем. Выявляет требования (задает вопросы для следующих агентов, а вопросы бывают и блокирующие, которые не переведут этап дальше и будут автоматически ожидать ответы от подключенных ролей), фиксирует user stories, scope, бизнес-правила и критерии приемки.

• Системный аналитик переводит из что/зачем в как на уровне системы: контракты API, модели данных, потоки взаимодействия, влияние на архитектуру. Проектирует, но не реализует.

• Разработчик-архитектор (на сильной модели) берет трудные технические решения, цена ошибки в которых высока: декомпозиция модулей, направление зависимостей, выбор паттерна, миграции, очереди, транзакции. Может сам написать критическое ядро, рутину отдает дальше.

• Разработчик реализует по готовой постановке. Code Reuse First: приоритет повторного использования кода, разработчик перед написанием новой функции или модуля обязан проверить, существует ли уже готовый, проверенный код для этой задачи. Минимальная реализация, обязательный прогон качества.

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

• Code review — финальный анализ измененных файлов с находками-чекбоксами.
  

Разделение ролей особенно заметно, когда у продукта несколько разных аудиторий с разными задачами. Для одного из проектов Uplab, платформы «Северсталь Вместе», бизнес-аналитик формировал не один набор требований, а два: для сотрудников компании и для участников корпоративных инициатив. У них разные сценарии, разные критерии приемки и разный контент, который они видят. Из этого разделения выросло архитектурное решение — не один личный кабинет с переключением ролей, а два связанных портала.

Как роли снижают риск каскадных ошибок

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

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

Почему конвейер важнее промпта

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

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

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

Ограничения и гейты — почему это не «замедление»

Гейт — это проверка на переходе между фазами: пока условие не выполнено, дальше не идем. Есть открытые блокирующие вопросы — не переходим к плану. Нет аппрува плана — не начинаем реализацию. Красный npm run check — не закрываем фичу.

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

В чем ценность агентской разработки для бизнеса

Ценность не в том, что агент «быстрее пишет код» — это узкий и сомнительный аргумент. Деньги обычно теряются на переделках, уточнениях размытых требований и зависимости от людей, которые держат весь контекст в голове. В классической работе Boehm & Basili про снижение дефектов в ПО есть оценка, что на переделку может уходить порядка 40–50% усилий проекта. Можно спорить о точных процентах, но сама мысль для индустрии не новая: чем позже обнаружена проблема, тем дороже ее исправлять.

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

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

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

Саммари

1. ИИ-агентам не нужно бесконечное поле свободы. Им нужны рамки, в которых их сила становится применимой.

2. Роли задают контракт: что приходит на вход, что должно появиться на выходе и где заканчивается зона ответственности.

3. Конвейер превращает задачу в жизненный цикл, а не в цепочку случайных промптов.

4. Состояние в файле дает внешнюю память, которая не исчезает вместе с сессией.

5. Гейты создают точки, где вероятностная модель упирается в проверяемое условие.

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