Как устроена управляемая агентная разработка

Разговор об ИИ в разработке обычно сводится к скорости: насколько быстрее пишется код. Вопрос верный, но узкий. Самой дорогой частью проекта написание кода бывало редко. Дорого обходились неверно понятая задача, неудачная архитектура и изменение, последствия которого никто не просчитал. Генерация ускоряет ту часть работы, которая и раньше давалась легче остальных, и тем заметнее становится всё прочее.

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

Чего модель не видит в репозитории

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

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

Отсюда задача: вынести контекст из головы в процесс. Записать его, разделить по ролям и сделать проверяемым.

Роль, контекст, инструменты, границы

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

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

Каждый агент получает:

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

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

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

Этапы и контрольные точки

Работа идёт последовательными этапами, и результат одного становится проверяемым входом для следующего:

Контекст → Архитектура → Спецификация → Реализация → Проверка → Выпуск

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

Процесс построен по принципу «человек в контуре» (human-in-the-loop). В нём есть точки, где решает только человек: формирование архитектуры, согласование спецификации, приёмка реализации, содержательное ревью, допуск в эксплуатацию.

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

Что меняется в работе инженера

Меняется в первую очередь распределение времени.

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

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

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

Чего это стоит

У такого процесса есть цена, и о ней лучше сказать прямо.

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

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

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

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