Мультиагентная разработка становится одним из заметных трендов AI-native разработки. Вместо одного ИИ, которому поручают весь проект, несколько специализированных агентов получают отдельные задачи, инструменты и контексты. Такой подход позволяет приблизить работу ИИ к модели команды, где разные участники отвечают за разные этапы и направления.
Пока эта технология находится на раннем этапе развития, но интерес к ней быстро растёт. Главный вопрос уже не в том, может ли ИИ писать код, а в том, как организовать совместную работу нескольких ИИ-агентов, обеспечить им правильный контекст и встроить их в существующий процесс разработки.
Что это
Мультиагентная разработка — это подход, при котором несколько ИИ-агентов совместно участвуют в создании и изменении программного продукта. Каждый агент может иметь собственную специализацию: анализировать требования, работать с кодом, проектировать API, изменять базу данных, писать тесты или проверять результат.
В отличие от обычного использования LLM, где человек формулирует запрос и получает ответ, здесь формируется целая система взаимодействующих агентов. Один агент может передать результат другому, запросить дополнительную информацию или инициировать следующий этап работы.
Мультиагентная разработка — это не просто несколько ИИ, а организация их совместной работы над одной системой.
Предыстория и проблематика
Появление мультиагентного подхода связано с естественным ограничением одного ИИ-агента. Современная LLM способна работать с огромным объёмом информации, но корпоративный проект может содержать миллионы строк кода, тысячи документов, десятки систем, API, базы данных и сложную бизнес-логику. Передать всё это одному агенту практически невозможно и экономически невыгодно.
Возникает и другая проблема: разные задачи требуют разного контекста. Агенту, который работает с SQL и структурой БД, не обязательно знать всю документацию пользовательского интерфейса. Тестировщику нужен один набор сведений, архитектору — другой, а разработчику API — третий.
Отсюда появляется идея разделить большую задачу на специализированные зоны ответственности. Вместо одного универсального агента создаётся несколько агентов, каждый из которых работает с ограниченным и релевантным контекстом.
Идея
Основная идея мультиагентной разработки проста: разделить сложный процесс создания ПО между несколькими ИИ-исполнителями. Один агент может получить требования и подготовить спецификацию, другой — разработать архитектурное решение, третий — написать код, а четвёртый — проверить результат.
Как в обычной команде разработчиков, специализация позволяет каждому участнику глубже работать со своей частью задачи.
Между агентами появляется обмен результатами. Например, архитектурный агент формирует решение, агент-разработчик реализует его, тестовый агент проверяет реализацию, а контрольный агент анализирует соответствие результата спецификации.
Смысл
Главный смысл подхода заключается не только в ускорении написания кода. Мультиагентная архитектура позволяет распределить сложность проекта между несколькими контекстами и несколькими исполнителями. Это особенно важно для крупных корпоративных систем, где невозможно эффективно загрузить одному агенту всю информацию о продукте.
В перспективе такая модель может привести к появлению виртуальной команды разработки, в которой ИИ-агенты выполняют значительную часть технической работы, а человек определяет цели, контролирует результат и принимает ключевые архитектурные и бизнес-решения.
Особенности
Мультиагентная разработка выглядит перспективно, но сегодня у неё есть существенные ограничения. Современные агенты уже способны выполнять отдельные этапы разработки, однако до полноценной замены всей команды разработки ещё далеко.
Пока только программирование
Сегодня основное применение ИИ-агентов находится непосредственно внутри технического цикла разработки. Агент может писать и изменять код, создавать тесты, искать ошибки, работать с репозиторием, использовать инструменты разработки и выполнять часть рутинных операций.
Но реальный цикл создания корпоративного ПО значительно шире. Сначала проходит встреча с заказчиком, собираются данные, анализируется существующая система и бизнес-процессы, выбирается архитектура, формируется протокол и вырабатываются требования. Затем необходимо понять, какие компоненты уже существуют, какие требуется создать, как они связаны между собой и какое решение будет оптимальным.
После этого начинается проектирование, программирование и тестирование. Но и на этом процесс не заканчивается. Необходимо проверить, насколько хорошо новое решение работает в реальном бизнесе: изменились ли показатели, ускорился ли процесс, снизилось ли количество ошибок, появились ли новые возможности и насколько результат отличается от прежнего процесса.
Таким образом, ИИ-агенты пока в основном помогают на участке «программирование — тестирование». Значительная часть работы аналитика, архитектора, консультанта и бизнес-эксперта всё ещё требует участия человека. Полноценная мультиагентная разработка должна охватывать весь жизненный цикл, а не только генерацию и проверку кода.
Съедает много токенов и повышает TCO
У мультиагентного подхода есть экономическая проблема. Чем больше агентов участвует в процессе и чем больше контекста они получают, тем больше токенов расходуется. Один и тот же фрагмент информации может несколько раз передаваться между агентами или повторно обрабатываться разными моделями.
Больше агентов не означает автоматически ниже стоимость разработки: плохо организованный контекст способен резко увеличить потребление токенов и TCO проекта.
Поэтому стоимость AI-native разработки определяется не только ценой самой LLM. Необходимо учитывать расходы на контекст, вызовы моделей, хранение информации, инструменты, оркестрацию, инфраструктуру и контроль результатов. Управление контекстом становится одновременно технологической и экономической задачей.
Сложность управления контекстом
Появление нескольких агентов не отменяет проблему контекста, а делает её сложнее. Необходимо решить, какому агенту какую информацию передать, в какой момент, в каком объёме и в каком формате. Если дать слишком мало контекста, агент не поймёт задачу. Если слишком много — увеличится стоимость и появится информационный шум.
Парадокс заключается в том, что люди могут потратить значительное количество времени не на выполнение самой задачи, а на организацию работы ИИ. Вместо того чтобы самостоятельно написать небольшой фрагмент кода, специалист сначала настраивает агентов, определяет их роли, готовит контексты, устанавливает связи между ними и проверяет результаты.
Получается своеобразная инверсия автоматизации: человек начинает управлять не только программным продуктом, но и целой системой ИИ-исполнителей. На нынешнем этапе это может съедать значительную часть потенциального выигрыша от автоматизации.
Однако есть позитив
Несмотря на существующие ограничения, потенциал мультиагентной разработки очень велик. Технология находится в начале своего развития, поэтому сегодняшние ограничения не обязательно будут сохраняться через несколько лет.
Если наладить работу агентов, разработка станет быстрее
Главный потенциальный эффект появляется тогда, когда компания научится правильно организовывать работу агентов. Необходимо выстроить роли, контексты, правила взаимодействия, контроль качества и передачу результатов между агентами. После такой настройки ИИ сможет выполнять гораздо больший объём работы практически непрерывно.
В этом случае разработчик будет не столько писать каждую строку кода, сколько ставить задачи, формировать спецификации, контролировать агентов и принимать результаты. Один специалист сможет одновременно управлять несколькими потоками разработки.
Главный потенциал мультиагентной разработки — не заменить программиста одним ИИ, а увеличить производительность человека за счёт параллельной работы нескольких агентов.
Если стоимость такой системы окажется ниже экономического эффекта от роста производительности, мультиагентная разработка станет естественной частью корпоративного SDLC. Тогда преимущества будут измеряться уже не количеством сгенерированных строк кода, а сокращением времени вывода продукта, снижением стоимости разработки и увеличением количества задач, которые команда способна выполнять.
Агенты становятся умнее
Важно учитывать скорость развития самой технологии. Всё, что мы сегодня называем ИИ-агентами и AI-native разработкой, фактически является результатом всего нескольких лет массового развития генеративного ИИ. Инструменты, которые ещё недавно могли только дополнять код, сегодня уже способны самостоятельно выполнять последовательность действий, работать с файлами, запускать тесты и использовать внешние инструменты.
Если следующие два-три года принесут сопоставимый прогресс, возможности агентов могут существенно расшириться. Ещё через два-три года они могут стать значительно более автономными, лучше понимать большие проекты, эффективнее работать с контекстом и надёжнее выполнять длинные цепочки действий.
Поэтому оценивать мультиагентную разработку только по возможностям сегодняшних инструментов преждевременно. Мы наблюдаем скорее начало нового этапа развития программной инженерии, чем сформировавшуюся технологию.
Сегодняшние ИИ-агенты — это только первые поколения технологии. То, что сейчас кажется сложным пределом автоматизации, через несколько лет может стать обычной функцией среды разработки.