Google развивает режим /swarm, в котором несколько кодовых агентов могут параллельно работать на одного разработчика; Cursor, со своей стороны, добавляет взаимодействие агентов, запущенных разными участниками команды. Мультиагентное программирование перестаёт быть лабораторным приёмом: IDE и агентные платформы пытаются превратить его в обычную часть разработки — с задачами, контекстом и неизбежными конфликтами изменений.
О двух обновлениях сообщает The New Stack. Идея проста на уровне презентационного слайда: один агент делает API-эндпоинт, второй обновляет тесты, третий разбирается с документацией или соседним модулем. Но практическая ценность появляется лишь тогда, когда эти исполнители не просто создают несколько параллельных диффов, а понимают границы своих задач и не ломают работу друг друга.
В случае Google ключевое слово — swarm, то есть «рой». Разработчик получает возможность поручить части одной работы нескольким агентам одновременно. Такой подход подходит для задач, которые можно безопасно разложить: реализация изолированных компонентов, подготовка тестов, поиск причин ошибки, миграция повторяющегося кода или сверка изменений с требованиями. Это заметно отличается от привычного сценария, где один чат-агент последовательно читает репозиторий, правит файлы и ждёт следующего указания.
Cursor делает акцент на другом уровне координации — командном. Если раньше агент в IDE в основном был персональным помощником конкретного инженера, то теперь продукт движется к модели, где агенты коллег могут обмениваться информацией. Для распределённой команды это потенциально полезнее, чем ещё один режим автодополнения: разработчик фронтенда, автор бэкенда и инженер по качеству часто работают над одной функцией, но видят разные части её контекста.
Тренд логичен. Одиночные coding agents уже умеют генерировать тесты, объяснять незнакомый код, предлагать патчи и выполнять ограниченные поручения в репозитории. Их слабое место — длинная задача, состоящая из нескольких зависимых подзадач. Когда один агент пытается удержать архитектуру, реализацию, тестирование и проверку регрессий, он либо работает медленно, либо начинает уверенно ошибаться на стыках. Разделение ролей обещает ускорение, но одновременно увеличивает цену плохой постановки задачи.
Именно поэтому мультиагентное программирование не стоит путать с кнопкой «сделать фичу». Параллельные исполнители могут изменить один файл, использовать разные предположения о контракте API или создать тесты, которые проверяют не то поведение, которое ждёт продуктовая команда. Чем больше агентов получают доступ к рабочей ветке и инструментам, тем важнее становятся ограничения: отдельные ветки или worktree, явное распределение файлов, обязательный code review, запуск тестов и контроль прав доступа к секретам и инфраструктуре.
Для российских команд здесь есть вполне прикладной вывод. Пробовать такие режимы разумнее не с крупной бизнес-фичи, а с задач, где результат легко проверить: покрытие уже существующего модуля тестами, обновление документации после API-изменений, разбор технического долга, подготовка вариантов миграции. Метрикой должна быть не скорость появления первого диффа, а время до готового, проверенного и принятого пул-реквеста. Иначе команда получит не виртуальный отдел разработки, а несколько очень быстрых авторов конфликтов.
Следующий вопрос для IDE и платформ — кто будет диспетчером этого «роя»: сам разработчик, выделенный агент-координатор или правила репозитория в CI. Пока индустрия предлагает разные ответы, но направление уже видно: конкурентное преимущество будет не у инструмента с максимальным числом агентов, а у того, который позволяет безопасно собрать их результат в один понятный релиз.
