Codex или Claude Code: какой агент выбрать для своего проекта

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

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

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

Типичный маршрут выглядит одинаково:

1. открыть правильную папку;

2. проверить Git;

3. попросить изучить проект без изменений;

4. согласовать план;

5. разрешить ограниченную правку;

6. прочитать diff;

7. запустить тесты и ручную проверку;

8. принять или откатить изменение.

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

В Codex CLI текущие разрешения можно посмотреть и изменить через /permissions. Агент сообщает о действиях, для которых нужно подтверждение. Отдельная команда /review помогает провести анализ изменений, но не заменяет тесты и чтение diff.

Codex также имеет неинтерактивный режим codex exec. Он полезен для автоматизации, но для первого знакомства лучше обычная интерактивная сессия. В ней видно, что агент собирается делать, и проще остановить слишком широкий план.

Инструкции проекта можно хранить в AGENTS.md. Такой файл должен содержать проверяемые правила: команды тестов, границы каталогов, стиль кода и запреты. Фраза «пиши качественно» не помогает. Правило «после изменения API запусти npm test -- api и не меняй миграции без подтверждения» уже влияет на поведение.

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

Claude Code предлагает несколько режимов разрешений. В plan агент работает в read-only режиме и не меняет файлы. В default он может выполнять разрешенные операции, а потенциально опасные действия запрашивают подтверждение. Есть режимы автоматического принятия редактирования и более автономной работы; полный обход разрешений подходит только для изолированной среды, где последствия ограничены.

Тонкие правила задаются через allow, ask и deny. Можно, например, разрешить чтение и безопасную команду тестов, спрашивать перед сетевым доступом и запретить команды публикации. Это полезно в проектах, где терминальный агент должен работать активно, но не иметь права менять внешнюю систему.

Claude Code использует CLAUDE.md для устойчивых инструкций. Как и в случае с AGENTS.md, файл не должен превращаться в длинное эссе. Лучше записать пять актуальных правил и регулярно их проверять, чем хранить тридцать противоречащих друг другу пожеланий.

Claude Code создает checkpoints изменений файлов в рамках сессии. Это удобная страховка, но она не откатывает внешние действия: отправленное письмо, запись в облачную базу или опубликованный релиз придется отменять отдельно.

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

Исходный запрос для обоих агентов:

После ответа оцените:

• найдены ли реальные файлы;

• учтена ли серверная часть;

• не появился ли лишний рефакторинг;

• названы ли наблюдаемые критерии;

• ясно ли, какие команды будут запущены.

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

Сохраните результаты в простой таблице. Не ставьте субъективную оценку «код красивый». Используйте факты:

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

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

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

Для новичка Codex удобен, когда первая задача заранее ограничена. Запускать агент из домашней директории и просить «приведи компьютер в порядок» опасно. Начните в отдельной папке с Git и простым файлом.

Claude Code стоит начать тестировать первым, если вам близка модель управления через явные permission modes, нужны детальные allow/ask/deny правила или проект уже использует CLAUDE.md и процессы Anthropic.

Plan mode дает понятную границу: сначала чтение и план, затем отдельное разрешение на изменение. Для команды с осторожным внедрением это удобная учебная модель. Но сам режим не проверяет качество плана. Пользователь по-прежнему должен сверить файлы, ограничения и критерии готовности.

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

У Codex и Claude Code разные варианты доступа через подписки и API, а условия меняются. Нельзя надежно выбрать инструмент по цифре из старой статьи. На дату решения откройте официальные страницы тарифов и ответьте на четыре вопроса:

• какая учетная запись нужна;

• что входит в подписку;

• что тарифицируется отдельно;

• какие лимиты относятся к вашей модели работы.

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

Перед обоими тестами сделайте одинаковый baseline:

Команды по порядку: git status, git branch --show-current и git log -1 --oneline.

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

После работы:

Команды по порядку: git status и git diff.

Прочитайте новые неотслеживаемые файлы отдельно. Запустите тесты сами. Проверьте поведение приложения вручную. Только после этого добавляйте точные файлы в staging и смотрите git diff --cached.

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

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

Ревью вторым агентом дополняет, но не заменяет линтер, тесты, типизацию, security-checks и человека, который понимает требование. Также не стоит передавать закрытый код двум поставщикам, пока команда не проверила политику данных и договорные условия.

Личный тест не показывает, как агент повлияет на pull request. После локального сравнения проведите по одной задаче в обычном командном процессе. Другой разработчик должен прочитать diff без истории чата и понять причину каждого изменения.

Запишите в описание pull request исходную задачу, ограничения, команды проверки и ручной сценарий. Не пишите «сделано с Claude» или «сделано Codex» вместо объяснения решения. Инструмент не является основанием для принятия кода.

Сравните, сколько замечаний ревьюера относится к неверной логике, лишнему scope и непонятной структуре. Если один агент стабильно создает diff, который легче проверить вашей команде, это сильнее любого общего бенчмарка.

Для закрытого репозитория отдельно согласуйте, каким поставщикам разрешена обработка кода. Проверьте управление аккаунтами, удаление доступа, журналирование и модель хранения данных. Технически удобный CLI может не пройти организационные требования. В таком случае его нельзя выбирать как командный стандарт, даже если личный тест был удачным.

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

Создайте две одинаковые ветки от одного коммита. Выполните одну задачу по протоколу «изучи, спланируй, дождись подтверждения, измени, проверь». Ограничьте время, например 45 минут на инструмент. Не помогайте одному больше, чем другому. Запишите результат по таблице выше.

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

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