Как запустить несколько ИИ-агентов для программирования

Среда разработки агентов (ADE, от англ. agent development environment) — это рабочее пространство, в котором одновременно работают несколько ИИ-агентов для программирования. Каждый агент получает свою задачу, изолированную копию кода и видимый статус, а человек распределяет работу, следит за ходом выполнения и проверяет каждое изменение перед слиянием.

01Коротко о главном

• Параллельные ИИ-агенты окупаются, только когда задачи независимы, узко сформулированы и поддаются проверке.
• Сначала изоляция: у каждого агента должны быть собственный git worktree и собственная ветка.
• Наблюдаемость — ключевая функция ADE: одного взгляда должно хватать, чтобы понять, какой агент работает, ждёт, застрял или закончил.
• Узким местом становится ревью, а не генерация кода, поэтому запускайте ровно столько агентов, сколько успеваете проверить.
• За каждое слияние отвечает человек: читайте diff и запускайте проверки сами.

02Что такое ИИ-агенты для программирования?

ИИ-агент для программирования — это инструмент на основе ИИ-модели, который умеет читать репозиторий, редактировать файлы, запускать команды и тесты, чтобы выполнить описанную задачу, а не просто подсказывать код по мере набора. Примеры — терминальные агенты вроде Claude Code, Codex CLI и Gemini CLI, агентные режимы в редакторах кода и удалённые агенты, которые работают в облачной песочнице и возвращают pull request.

03Что такое среда разработки агентов (ADE)?

Классическая IDE рассчитана на одного человека, который редактирует одну рабочую копию, и многие редакторы уже обзавелись собственными агентными функциями. Но когда агентов запущено несколько, центром рабочего дня становится координация, а не редактирование. Термин, который иногда пишут как agentic development environment, обозначает среду, где вы разрабатываете программы с помощью ИИ-агентов, а не инструменты для создания самих ИИ-агентов.

ADE не заменяет ни редактор, ни агентов. Это слой оркестрации над ними, который берёт на себя работу, растущую с каждым новым агентом:

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

04Зачем запускать несколько ИИ-агентов параллельно?

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

На практике почти вся параллельная работа укладывается в три схемы:

• Веерное распределение (fan-out): несколько независимых задач из одного бэклога, по агенту на задачу, и каждая сливается отдельно.
• Конкурирующие попытки: неоднозначную задачу отдают двум агентам или одному, но дважды и с разными инструкциями, а затем оставляют лучший результат.
• Конвейер (pipeline): один агент реализует, второй проверяет результат или пишет к нему тесты, а окончательное решение принимает человек.

05Как организовать параллельный запуск ИИ-агентов?

Большинство команд используют один из четырёх вариантов, а многие их комбинируют:

• Вкладки терминала или панели tmux, по одному агенту и одному git worktree на каждую: новые инструменты не нужны, но статус каждого агента вы отслеживаете сами.
• Встроенные в редактор мультиагентные функции: удобно, когда вся команда и так работает в этом редакторе.
• Облачные или фоновые агенты, которые работают в облачной песочнице и возвращают pull request: локально ничего не запускается, а вы проверяете PR.
• Специализированная среда разработки агентов: статус, diff и ревью по каждому агенту в одном месте.

06Какие задачи подходят для параллельных ИИ-агентов?

Проверьте каждую задачу-кандидата четырьмя вопросами. Независима ли она от других запущенных задач? Можно ли описать её в коротком задании? Можно ли проверить её тестами, проверкой типов, сборкой или критерием приёмки? Затрагивает ли она отдельную часть кодовой базы?

Хорошие кандидаты

• Добавление тестов в модули, которые ими не покрыты.
• Самостоятельные исправления багов с понятным сценарием воспроизведения.
• Изолированные функции за чётко определённым интерфейсом, например новый эндпоинт API или UI-компонент.
• Механические миграции, которые чисто делятся по директориям или пакетам.
• Документация, улучшение типизации и исправление замечаний линтера там, где больше никто ничего не редактирует.

Плохие кандидаты

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

07Как запустить несколько ИИ-агентов для программирования: пошагово

1. 1Разбейте работу на независимые задачи.
2. 2Изолируйте каждого агента с помощью собственного git worktree и ветки.
3. 3Напишите задание, которое агент сможет выполнить.
4. 4Наблюдайте, снимайте блокировки и вмешивайтесь.
5. 5Проверяйте и сливайте ветки по одной.

Шаг 1. Разбейте работу на независимые задачи

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

Шаг 2. Изолируйте каждого агента с помощью git worktree

Два агента в одной рабочей директории могут перезаписывать изменения друг друга и сбивать друг другу прогоны тестов. Самый простой надёжный способ изоляции — git worktree: дополнительная рабочая директория, привязанная к тому же репозиторию и стоящая на собственной ветке.

# One worktree and one branch per agent
git worktree add -b agent/auth-refactor ../app-agent-auth
git worktree add -b agent/billing-tests ../app-agent-tests

# See what is checked out where
git worktree list

# Clean up once the branch has been merged locally (use -D after a squash merge)
git worktree remove ../app-agent-auth
git branch -d agent/auth-refactor

По умолчанию git не позволяет извлечь одну и ту же ветку сразу в два worktree — именно такая защита вам и нужна. При очистке git worktree remove отказывается удалять worktree с изменёнными или неотслеживаемыми файлами: сначала закоммитьте или отбросьте их либо, когда будете уверены, добавьте --force. Worktree изолируют файлы, но не всё остальное. Заранее продумайте, что остаётся общим:

• Зависимости и результаты сборки: каждому worktree обычно нужны свои установленные пакеты (node_modules, виртуальные окружения) и свои артефакты сборки.
• Порты: два сервера разработки не могут занять один и тот же порт, поэтому назначьте каждому агенту свой.
• Базы данных: используйте отдельные локальные базы или схемы и никогда — общий staging.
• Файлы окружения: копируйте только ту несекретную конфигурацию, которая нужна конкретному агенту.

Шаг 3. Напишите задание, которое агент сможет выполнить

Любой пробел в задании агент заполняет собственными допущениями. Хорошее задание короткое, но полное:

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

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

Шаг 4. Наблюдайте, снимайте блокировки и вмешивайтесь

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

Шаг 5. Проверяйте и сливайте ветки по одной

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

08Как избежать конфликтов между ИИ-агентами

Большинство конфликтов между параллельными агентами возникает в нескольких общих «горячих точках»:

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

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

09Как следить за тем, что делает каждый ИИ-агент?

За одним агентом можно следить в терминале. За пятью — уже нет. По каждому агенту вы должны с одного взгляда отвечать на следующие вопросы:

• Над чем он работает и какое задание получил?
• В каком он состоянии: работает, ждёт ввода или разрешения, застрял на ошибке или закончил?
• Что он уже изменил — каков diff относительно базовой ветки?
• Какие команды он запускал и прошли ли тесты и проверки?
• Сколько времени он работает и сколько ресурсов модели уже израсходовал?

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

10Сколько стоит запуск нескольких ИИ-агентов?

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

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

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

11Почему код, написанный ИИ, всё равно должен проверять человек

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

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

Чек-лист ревью изменений, написанных агентом

• Читайте сам diff, а не только его пересказ от агента.
• Запускайте тесты и проверки сами или убедитесь, что они прошли в CI.
• Ищите выход за рамки задачи: изменённые файлы, о которых в задании не было ни слова.
• Проверяйте новые зависимости, сетевые вызовы и всё, что касается аутентификации, платежей или персональных данных.
• Убедитесь, что в коммиты не попали секреты, токены или пути, привязанные к конкретной машине.
• Убедитесь, что новые тесты действительно проверяют новое поведение, а не просто проходят.

12Типичные ошибки при работе с несколькими ИИ-агентами

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

13Часто задаваемые вопросы

Чем IDE отличается от среды разработки агентов?

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

Сколько ИИ-агентов запускать одновременно?

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

Нужен ли git worktree для параллельной работы агентов?

Какая-то изоляция нужна обязательно, и git worktree — самый лёгкий вариант: каждый агент получает свою директорию и ветку в одном общем репозитории. Отдельные клоны или контейнеры изолируют надёжнее, но занимают больше места на диске и требуют больше настройки. Облачные песочницы, которые возвращают pull request, выносят изоляцию за пределы вашего компьютера, но ревью никуда не девается. Никогда не позволяйте двум агентам одновременно редактировать одну и ту же рабочую директорию.

Могут ли ИИ-агенты проверять код друг друга?

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

Безопасно ли разрешать ИИ-агентам запускать команды на моём компьютере?

Может быть безопасно — при наличии защитных механизмов. Давайте агентам минимально необходимые права, держите продакшен-учётные данные вне их окружения и требуйте подтверждения для деструктивных и сетевых команд. Всё, что агент читает за пределами вашей кодовой базы, например issues, веб-страницы или сторонние файлы, считайте недоверенным: там могут оказаться инструкции, специально написанные, чтобы ввести агента в заблуждение, — этот риск называется промпт-инъекцией (prompt injection). Контейнеры дают дополнительную защиту.

14Как Neptay подходит к разработке с агентами

Мы проектируем ИИ-агентов и автоматизацию в рамках услуг для клиентов и создаём собственные технологические продукты под брендом Anlato. Anlato Space, флагман семейства Anlato, — наша среда разработки агентов: множество ИИ-агентов для программирования бок о бок в одном нативном окне, у каждого своя задача и статус, и каждое изменение ждёт вашего ревью. Anlato Space скоро выйдет. Если вы проектируете агентный рабочий процесс для своей команды или хотите следить за Anlato Space, напишите нам на hello@neptay.com.