Два агента на один проект: 5 этапов разделения задач в 2026

• понятное объяснение роли Claude Code в проекте; - схема распределения задач между Claude Code и Codex; - шаблон безопасной передачи задачи через файл-контракт; - список ограничений для файлов, тестов, commit, push и публикации; - правила финальной проверки и защиты от циклов review.

Claude Code - ИИ-агент для работы с проектом через командную строку. Он читает код, ищет нужные файлы, вносит изменения и запускает проверки. В статье я показываю, что такое claude code, как использовать его рядом с Codex в практике вайб-кодинга и где поставить ограничения, чтобы агент не переписал работающую часть проекта.

Что такое Claude Code и зачем он нужен?

Обычный чат предлагает фрагменты, а Claude Code работает внутри проекта.

С Codex он при этом не образует единую систему: официальная нативная интеграция не подтверждена.

Claude Code запустили 24 февраля 2025 года как первый агентный инструмент Anthropic для разработки. На старте он получил доступ к командной строке и умел работать с самим проектом:

• читать и искать код;
• редактировать файлы;
• запускать тесты;
• выполнять commit и push в GitHub.

Обычный чат отвечает на описание задачи. Claude Code получает доступ к структуре проекта и действует внутри неё. Масштаб работы здесь принципиально другой: агент ищет место изменения, правит файл и запускает проверку вместо того, чтобы просто предложить фрагмент для вставки.

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

У Claude Code есть собственные агентные сценарии Anthropic. При этом подтверждения, что Codex нативно подключается к Agent Teams Claude Code, в фактуре нет. Ролик с названием про совместную работу подтверждает только заявленную тему, но не техническую схему.

Как Claude Code работает в проекте?

Рабочий цикл выглядит так:

1. Агент осматривает проект. Он ищет файлы, читает связанную логику и пытается понять текущую структуру.
2. Ты ставишь задачу. Чем точнее цель, список файлов и критерий готовности, тем меньше пространства для случайных решений. Подробнее о структуре промпта - в статье Claude Code: короткая команда из 5 частей.
3. Агент выбирает место изменения. Он находит код, который считает связанным с задачей.
4. Агент редактирует файлы. На этом этапе и появляется риск лишнего scope, если ограничения не заданы.
5. Агент запускает проверки. Это могут быть тесты или другие команды, которые доступны в проекте.
6. Агент возвращает результат. В хорошем отчёте есть изменённые файлы, выполненные проверки и вопросы, которые остались открытыми.

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

Anthropic описывает Claude Code как партнёра по размышлению, исследованию, прототипированию и автоматизации. Это полезная рамка. Агент помогает пройти путь от идеи до изменения, но не снимает с человека контроль над результатом.

Проверять надо по следам работы:

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

Такой подход особенно нужен, когда после Claude Code к проекту подключается Codex. Второй агент видит состояние файлов, но не получает автоматически замысел первой сессии.

Как подключить Claude Code к проекту и начать работу?

1. Открой проект из CLI.

   Рабочая точка Claude Code - среда командной строки, связанная с папкой проекта.

   Агент должен видеть ту кодовую базу, с которой предстоит работать. О том, как удержать проект в файле, а не в чате, рассказано в статье Claude Code теряет контекст на третьем часу. Не смешивай в одной задаче несколько несвязанных проектов и не передавай агенту весь диск без ясной причины.

2. Опиши цель и границы.

   Напиши, что должно измениться, какие файлы разрешены и что трогать нельзя.

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

3. Разреши проверку результата.

   Попроси агента показать изменённые файлы и выполнить известную команду проверки.

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

4. Остановись перед опасным действием.

   Commit, push и публикацию не включай в задачу автоматически.

   На старте достаточно получить незакоммиченные изменения и diff. Решение о сохранении результата остаётся отдельным шагом.

В версии 1.0.0 Claude Code получил общую доступность, фоновые задачи через GitHub Actions, интеграции с VS Code и JetBrains, а также SDK для создания собственных агентов. Это расширяет способы работы, но не меняет базовое правило: сначала понятная задача, затем ограниченное изменение, затем проверка.

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

Как разделить задачи между Claude Code и Codex?

Главное правило Anthropic звучит жёстко: деление по типу работы создаёт постоянные координационные затраты. Если агент уже разобрался в задаче, передача ему реализации от одного исполнителя и тестов от другого может только усложнить процесс.

Я разделяю работу так:

Для одного агента подходит задача, где цель узкая, файлы связаны, а результат легко проверить. Например, изменить текст в одном компоненте и запустить проверку.

Для read-only проверки второй агент не должен редактировать код. Его задача - найти ошибки, рискованные места и несоответствия исходной цели. Такой режим отделяет оценку от авторства.

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

Последовательная передача выглядит проще и надёжнее:

1. Claude Code изучает проект и формирует план.
2. Первый агент меняет разрешённые файлы.
3. В проект сохраняются diff и отчёт проверки.
4. Codex получает эти артефакты и выполняет независимое ревью.
5. Человек смотрит итоговый diff и решает, что принять.

Официального подтверждения, что Codex подключается к Agent Teams Claude Code как равноправный участник, нет. Поэтому я не описываю их как одну встроенную команду. Практическая связка строится через общие файлы, diff и явную передачу результата. Подробнее о едином файле правил для обоих агентов рассказано в статье AGENTS.md в 2026: 3 раздела правил для Claude Code и Codex.

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

Claude Code против Codex: кому какую задачу отдавать?

Claude Code может исследовать проект, составлять план и выполнять изменения. Codex разумно подключать, когда нужна вторая независимая точка зрения. Роли агентов стоит определять по задаче, контексту и требуемому результату.

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

Для review полезен read-only режим. Агент смотрит на изменения, но не чинит их сам. Так замечания не смешиваются с новой серией правок.

Есть и режим rescue. Он нужен, когда агент может менять код, чтобы вывести проект из поломки. Это уже не обычная проверка. Для него нужны более строгие полномочия и отдельная команда.

Agent Teams Claude Code остаются исследовательской функцией. Официально подтверждены внутренние команды Claude Code, но нативная связка с Codex не подтверждена. Поэтому схему «Claude Code планирует, Codex пишет, третий агент тестирует» я бы не запускал без независимых зон и артефактов.

Что передать второму агенту, чтобы он не сломал проект?

Subagent получает ограниченную задачу и возвращает результат. Anthropic советует передавать результат между этапами через файлы-артефакты. Для Claude Code и Codex это особенно важно: отдельные сессии не обязаны видеть историю друг друга.

Файл-контракт может выглядеть так:

# Передача задачи

## Цель
Проверить изменение текста на странице и найти регрессии.

## Разрешённые файлы
- src/pages/Home.tsx
- src/pages/Home.test.tsx

## Запрещённые файлы
- package-lock.json
- настройки сборки
- файлы окружения
- файлы вне перечисленного списка

## Критерии готовности
- новый текст отображается на странице;
- существующая разметка не меняется без причины;
- проверка страницы проходит.

## Команды проверки
- npm test -- Home.test.tsx

## Полномочия
- читать файлы: да;
- редактировать: нет;
- запускать тесты: да;
- commit: нет;
- push: нет;
- публикация: нет.

## Состояние
- выполнено:
- провалено:
- не проверялось:
- открытые вопросы:

Не называй контракт «сделано» и не прячь в нём только пожелания. Его задача - показать следующему агенту, что разрешено, что запрещено и по чему принимать результат.

Передавай минимум такой пакет:

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

Файл spec.md подходит для цели и критериев. task.md подходит для конкретного поручения. Diff показывает фактические изменения. Отчёт тестов показывает доказательства, а не обещание.

Что делать, если агенты меняют один файл или зацикливаются?

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

Вторая поломка - слишком широкий scope. Если в поручении нет списка файлов, критериев и запретов, Codex может тронуть больше областей, чем планировалось.

Третья поломка - бесконечный review loop. Claude Code завершает работу, запускается Codex, Codex находит замечание, Claude Code снова меняет код, затем проверка начинается заново. Такой review gate способен быстро расходовать лимиты.

Безопасная схема:

1. Раздели независимые зоны. Назначь каждому агенту отдельные файлы или каталоги.
2. Передавай общий файл. Сохраняй цель, diff, проверки и открытые вопросы в проекте.
3. Переключайся на последовательность. Для тесно связанных файлов сначала закончи работу одним агентом, затем запускай второго.
4. Включай read-only review. Reviewer должен сначала находить проблемы, затем при необходимости переходить к правкам.
5. Задай лимит раундов. После заранее выбранного числа циклов останови автоматическую передачу и посмотри diff вручную.
6. Запускай gate вручную. Не превращай каждое завершение Claude Code в автоматический запуск Codex.
7. Запрети опасные действия. Commit, push, release и публикация должны требовать отдельного разрешения.

Если агенты уже изменили один файл, не проси их «синхронизироваться» в чате. Сначала останови выполнение. Затем посмотри diff, отдели нужные изменения от перезаписанных и только после этого назначай следующий шаг.

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

Кто должен проверять изменения перед слиянием?

Финальная проверка не должна состоять из одного вопроса «всё ли готово». Пройди четыре слоя:

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

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

Агенту отдельно ограничивай:

• редактирование;
• запуск тестов;
• commit;
• push;
• публикацию.

Последние три действия не должны следовать из фразы «если всё хорошо». Их нужно разрешать отдельным шагом.

Финальный порядок такой:

1. Посмотри список изменённых файлов.
2. Прочитай diff целиком.
3. Сверь изменения с целью и контрактом.
4. Проверь вывод команд.
5. Зафиксируй непройденные проверки.
6. Задай оставшиеся вопросы агенту.
7. Сам реши, делать ли merge.

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

Вопросы и ответы