Руководство по параллельному AI-кодингу

При двух параллельных рабочих областях Git каждая из них может иметь собственную ветку, индекс и каталог файлов; именно это позволяет git worktree держать несколько веток одновременно без постоянного переключения. Это подтверждает официальная документация Git по worktree. Но сама изоляция не ускоряет проект: если задачи зависят от одних и тех же файлов, вы получите конфликты и дополнительную проверку. Поэтому правильный план параллельного AI-кодинга такой: сначала определить независимые работы и интерфейсы, затем создать отдельные среды, после этого запускать агентов и пропускать каждый результат через единые тестовые ворота.

Эта статья предназначена:

• для независимых разработчиков, которые переходят от одного AI Coding Agent к нескольким;
• для небольших команд, которым нужно сократить цикл доставки функций;
• для платформенных инженеров, планирующих рабочие места, удалённые среды и ресурсную ёмкость для агентов.

До запуска: определите, действительно ли проект готов к параллельной работе

Параллельная разработка начинается не с открытия нескольких терминалов, а с карты зависимостей. Возьмите задачу и разделите её на модули:

1. пользовательский интерфейс;
2. серверный API;
3. слой данных;
4. тесты;
5. документация и миграции.

Затем отметьте для каждого модуля:

• какие файлы разрешено изменять;
• какие интерфейсы он вызывает;
• какие артефакты нужны от другого агента;
• какие файлы являются общими;
• какой командой проверяется готовность.

Например, добавление функции «экспорт отчёта» можно разделить на API-эндпоинт, генератор файла и интерфейс загрузки. Но если все три части требуют одновременно менять один центральный контроллер, реальная независимость исчезает. В таком случае сначала создайте стабильный контракт API, а уже затем запускайте параллельные задачи.

Какие задачи можно запускать одновременно

Хорошими кандидатами обычно являются:

• добавление независимых тестов;
• разработка отдельных экранов после фиксации API;
• адаптеры к разным внешним сервисам;
• документация и примеры использования;
• исправление разных дефектов в непересекающихся пакетах;
• сравнение нескольких реализаций одной функции.

Плохими кандидатами являются:

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

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

Первый час: оформите единый контракт для каждого агента

Каждый AI Coding Agent должен получать не общий призыв «сделай функцию», а короткий контракт. Его удобно хранить в задаче, pull request или версионируемом файле вроде AGENTS.md.

Минимальный контракт включает:

Цель:
Что должно измениться и какую проблему это решает.

Разрешённые пути:
Какие каталоги и файлы можно изменять.

Запрещённые пути:
Что нельзя менять без отдельного согласования.

Входные интерфейсы:
Какие API, типы, события или схемы уже считаются стабильными.

Команды проверки:
Какие тесты, линтер, сборку и анализ безопасности нужно запустить.

Артефакты:
Какой commit, отчёт, патч или описание должен вернуть агент.

Критерий готовности:
Что считается завершённой задачей и при каком результате работа останавливается.

Это важнее длины промпта. Если один агент получил старую версию схемы, а другой — новую, конфликт возникнет ещё до объединения веток. Общие правила должны находиться в репозитории, а не только в истории чата.

Для команд полезно отдельно зафиксировать:

• правила именования веток;
• формат commit-сообщений;
• допустимый размер pull request;
• обязательные тесты;
• порядок эскалации блокирующих вопросов;
• список файлов, которые изменяются только владельцем проекта.

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

Как несколько AI-агентов избегают изменения одного файла

Самый надёжный базовый механизм — отдельная ветка и отдельный Git worktree для каждой задачи. Git описывает worktree как несколько рабочих деревьев, связанных с одним репозиторием; при этом у каждого есть собственные HEAD и индекс. Это удобнее, чем постоянно переключать одну папку между ветками. Подробности доступны в руководстве Git по управлению рабочими деревьями.

Пример подготовки:

git fetch origin
git switch main
git pull --ff-only

git worktree add ../project-api -b agent/api-contract origin/main
git worktree add ../project-ui -b agent/report-ui origin/main
git worktree add ../project-tests -b agent/report-tests origin/main

git worktree list

Теперь каждый агент получает собственный путь:

• ../project-api — контракт и серверная часть;
• ../project-ui — интерфейс;
• ../project-tests — тестовые сценарии.

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

export APP_PORT=4101
export DATABASE_NAME=project_agent_api
export CACHE_NAMESPACE=agent-api

Для другой рабочей области используйте другие значения. Секреты не следует копировать в рабочий каталог агента без контроля доступа. Особенно осторожно работайте с файлами .env, токенами, SSH-ключами и конфигурацией облачных сервисов.

Существуют и другие модели. Orca в своей документации описывает создание отдельного worktree для каждой задачи, запуск разных CLI-агентов и последующий просмотр diff. Это не заменяет вашу политику доступа, но показывает практическую модель «одна задача — одна рабочая область». (onorca.dev)

Cursor Background Agents работают в изолированной среде Ubuntu, клонируют репозиторий из GitHub и используют отдельную ветку для передачи результата. При этом официальная документация отдельно предупреждает об интернет-доступе, автоматическом выполнении команд и рисках prompt injection. Перед использованием проверьте описание окружения и ограничений Cursor Background Agents. (docs.cursor.com)

Как организовать параллельный цикл от запуска до первого результата

Шаг 1. Сформируйте карту зависимостей

Нарисуйте граф:

контракт API → серверная реализация → интерфейс
схема данных → миграция → интеграционные тесты

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

Шаг 2. Назначьте каждому агенту узкую область

Вместо задачи «реализуй отчёты» используйте формулировку «добавь обработчик GET /reports/:id, не меняя миграции и интерфейс». Чем уже область изменения, тем проще проверка и тем дешевле исправление конфликта.

Шаг 3. Создайте одинаковое окружение

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

OpenHands разделяет среду выполнения агента и хостовую систему через sandbox-модель. В документации указаны Docker-, process- и remote-варианты; process-вариант быстрее, но не даёт контейнерной изоляции. Это важная граница при выборе среды для кода, который может выполнять произвольные команды. (docs.openhands.dev)

Шаг 4. Запустите только независимые задания

Зафиксируйте время старта, ветку, рабочий путь и текущий commit. В командном проекте полезно вести таблицу состояния:

Задача | Агент | Ветка | Статус | Блокер | Артефакт

Статусы должны быть однозначными: готовится, в работе, ожидает интерфейс, тесты не пройдены, готово к проверке. Не полагайтесь на чат как на единственную историю проекта. Финальный результат должен находиться в commit, pull request или отчёте в системе задач.

Шаг 5. Передавайте зависимости через артефакты

Если задача B зависит от задачи A, агент A должен передать конкретный результат:

• commit с описанием изменений;
• опубликованную схему;
• файл контракта;
• пример запроса и ответа;
• список известных ограничений.

Не передавайте зависимость фразой «агент почти закончил». Пока интерфейс не закреплён, B либо ждёт, либо работает на предположении, которое потом придётся переписывать.

Шаг 6. Проведите локальную проверку до общего merge

Каждый агент обязан выполнить минимум:

npm test
npm run lint
npm run build

Команды должны соответствовать вашему стеку; приведённый пример не является универсальным набором. Для Python это могут быть pytest, ruff и сборка пакета, для Go — go test ./..., go vet и go build ./....

Дополнительно проверьте:

• изменённые файлы;
• незапланированные зависимости;
• попытки чтения секретов;
• фоновые процессы;
• сетевые обращения;
• запрещённые каталоги;
• изменения lock-файлов.

Если ветка не проходит базовую проверку, она не готова к объединению. Не переносите дефект на финальную стадию: там его стоимость выше, потому что уже изменились соседние ветки.

Единые тестовые ворота: как принять код нескольких агентов

Надёжная схема приёмки состоит из нескольких уровней.

Первый уровень — быстрые проверки. Линтер, форматтер, типизация и unit-тесты должны запускаться на каждом pull request.

Второй уровень — сборка. Проверяйте production-сборку, миграции и генерацию артефактов. AI-агент может сделать локальный тест зелёным, но сломать процесс упаковки.

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

Четвёртый уровень — безопасность. Сканируйте зависимости, права доступа, секреты и опасные shell-команды. Это особенно важно для удалённых агентов, которые могут автоматически выполнять команды и иметь доступ в интернет. Cursor прямо указывает на такой риск в документации Background Agents. (docs.cursor.com)

Для основной ветки включите обязательные status checks. GitHub указывает, что при такой настройке необходимые проверки должны завершиться успешно до слияния в защищённую ветку; строгий режим также требует актуальности ветки относительно базовой. Ознакомьтесь с документацией GitHub по защищённым веткам. (docs.github.com)

Сценарий из небольшой команды

Представьте сервис с формой оплаты. Один агент меняет серверный валидатор, второй обновляет интерфейс, третий пишет тесты отказа платежа. Они могут работать одновременно только после фиксации формата ответа API. Если формат меняется во время работы, UI-агент и автор тестов будут проверять разные контракты.

Практический порядок такой:

1. руководитель фиксирует JSON-схему ответа;
2. агент API реализует серверную часть;
3. UI-агент работает по схеме, не меняя её;
4. агент тестов создаёт проверки на тот же контракт;
5. после первого merge остальные ветки обновляются от новой базы;
6. запускаются интеграционные тесты;
7. только затем оценивается готовность функции.

Когда объединять ветки и как выбирать между несколькими реализациями

Объединяйте изменения в порядке зависимостей:

1. типы, интерфейсы и схемы;
2. общие библиотеки;
3. серверные адаптеры;
4. пользовательский интерфейс;
5. тесты и документация.

После каждого важного merge обновляйте оставшиеся ветки:

git fetch origin
git rebase origin/main

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

Если несколько агентов сделали одну и ту же функцию, не выбирайте вариант по размеру diff. Используйте оценочную матрицу:

• соответствие контракту;
• покрытие тестами;
• сложность поддержки;
• безопасность;
• совместимость с текущей архитектурой;
• качество обработки ошибок;
• объём ручной доработки.

Побеждает не самый длинный код, а реализация с минимальным риском дальнейшей поддержки.

Для работы с удалёнными агентами заранее проверьте:

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

Orca документирует локальные worktree, запуск нескольких CLI-агентов и отдельный просмотр diff. Cursor предлагает программное управление фоновыми агентами и заявляет поддержку до 256 активных агентов на API-ключ, однако это лимит конкретной API-модели, а не обещание линейного ускорения проекта. (onorca.dev)

Чек-лист перед увеличением числа агентов

• [ ] Для каждой задачи указан владелец результата.
• [ ] Определены разрешённые и запрещённые пути.
• [ ] Зафиксированы API, типы или схемы, от которых зависит работа.
• [ ] Для каждой ветки создан отдельный Git worktree или изолированная среда.
• [ ] Разделены порты, базы, кэши и временные каталоги.
• [ ] Секреты не копируются в неконтролируемые рабочие области.
• [ ] У каждой задачи есть команда локальной проверки.
• [ ] Результат агента записывается в commit, pull request или отчёт.
• [ ] Зависимости передаются через конкретные артефакты.
• [ ] В основной ветке включены обязательные проверки.
• [ ] Неуспешная ветка не допускается к финальному merge.
• [ ] После объединения нижнего слоя остальные ветки обновляются.
• [ ] Через неделю измеряются конфликты, ожидание, возвраты и нагрузка на ревью.

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

Какая схема среды подходит для разных проектов

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

Если вы тестируете удалённую разработку на Mac, можно начать с аренды Mac mini для удалённой разработки, а при необходимости сравнить региональные варианты, например аренду Mac mini в США. Для сценариев, где важны подключение и проверка доступа, пригодится также чек-лист удалённой среды Mac.

Почему параллельный AI-кодинг иногда медленнее одного агента

Причины обычно не связаны с качеством отдельной модели:

• задачи пересекаются по файлам;
• агенты ждут общий интерфейс;
• тестовая среда не выдерживает одновременные сборки;
• один человек не успевает проверить все pull request;
• несколько агентов создают разные трактовки требований;
• конфликты обнаруживаются только перед релизом;
• удалённые рабочие места дольше поднимаются, чем длится сама задача.

На первой неделе измеряйте не только количество завершённых задач, но и:

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

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

Локальная схема обычно лучше, когда задачи короткие, код не содержит чувствительных данных и у вас уже есть подходящая машина. Временная аренда Mac разумна для разового эксперимента, тестирования CI/CD, запуска нескольких окружений или проверки спроса до покупки оборудования. Постоянная удалённая инфраструктура оправдана, когда команды регулярно запускают длительные сборки и готовы поддерживать права доступа, резервирование и очистку сред.

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