Сравнивать Codex и Claude Code по обзорам бесполезно: честный ответ даёт прогон обоих агентов на одной и той же задаче вашего репозитория, где сопоставляют постановку, права, diff, тесты и время, которое уходит у ревьюера. Победителя без контекста нет, а выбор для команды складывается из привычек разработчиков, политики доступа и стоимости ошибки. Метод ниже подходит командам, у которых есть автоматические тесты и хотя бы один человек, готовый читать чужой diff.
Условия прогона
Для честного сравнения нужны одинаковый текст задачи, одинаковая стартовая ветка, отдельные рабочие каталоги и заранее записанные критерии приёмки. Оценивают diff, вывод тестов и время ревью, а впечатление от интерфейса остаётся за скобками.
Условная задача для прогона: в сервисе уведомлений нужно добавить повторную отправку при временном сбое внешнего канала так, чтобы каждое сообщение уходило ровно один раз. Задача хороша тем, что содержит бизнес-ограничение, требует понимания существующего кода и проверяется тестом. Подберите аналог из своего бэклога, где правильный результат вы можете описать заранее.
- Создайте две ветки или два рабочих дерева git от одного коммита: по одному на агента.
- Запишите критерии приёмки до запуска: какие тесты должны пройти, какое поведение сохраниться, какие файлы вне границы.
- Вставьте обоим агентам один и тот же текст задачи без устных пояснений.
- Оставьте ход работы агенту до доклада о завершении и отмечайте каждый вопрос, который он задал.
- Проверьте результат одинаковым набором шагов и занесите в таблицу.
Один прогон остаётся анекдотом. Повторите сравнение на двух-трёх разных задачах и хотя бы раз поменяйте агентов местами в порядке запуска. Тогда различия объясняются инструментом, а настроение дня выпадаёт из объяснения.
Постановка и правила
Оба инструмента читают файл правил проекта. У Codex это файл AGENTS.md, который создаёт команда /init в документации Codex CLI. У Claude Code аналогичную роль играет файл CLAUDE.md, как описано в разборе про единый контур Claude Code для команды. Оба файла хранят команды запуска тестов, стиль кода и запретные каталоги; сравнение стоит делать при одинаковом содержании этих файлов.
| Этап | Что сопоставить | Как зафиксировать |
|---|---|---|
| Вход | Установка, способ входа, число действий до первой задачи | Заметки о препятствиях |
| Постановка | Сколько уточняющих вопросов задал агент | Список вопросов и ответы |
| Правила проекта | Учтены ли файлы правил | Цитаты из diff или отчёта |
| Ход работы | Видно ли, что агент делает, и можно ли вмешаться | Скриншот или журнал |
| Результат | Размер diff, тесты, описание | Таблица критериев |
Вход у обоих инструментов привязан к учётной записи вендора. Для Codex CLI документация называет вход через учётную запись ChatGPT или ключ API, для Claude Code различаются подписка и ключ. Условия оплаты и доступа из вашей страны определяют вендоры; условия зависят от страны, поэтому вопрос доступа решайте до сравнения, иначе эксперимент остановится на старте.
Отдельно отметьте, сколько уточняющих вопросов задал агент. Вопросы по делу показывают, что постановка двусмысленна, и это повод улучшить текст задачи для обоих. Отсутствие вопросов добродетелью считать рано: молчаливый агент мог молча выбрать неверное толкование.
Перед стартом проверьте, что содержание файлов правил действительно одинаково. Если в одном файле перечислены команды запуска тестов, а в другом их нет, агенты начнут работу с разных позиций, и выигрыш одного из них окажется заслугой файла правил, и выиграл здесь файл, а инструмент ни при чём. Сверьте также версии зависимостей и состояние кэша сборки на обеих ветках.
Права и запуск
Права на запуск команд и правку файлов определяют, насколько безопасно оставить агента без присмотра. В Codex CLI границы задают командой /permissions: она определяет, когда Codex правит файлы и запускает команды без вопроса, а перед продолжением можно посмотреть активную песочницу и каталоги, доступные для записи. Запуск без диалога в сценариях автоматизации выполняет codex exec. В Claude Code работают режимы разрешений: ручное подтверждение, режим планирования через /plan и режимы с автоматическим принятием правок. Названия и набор режимов в обоих продуктах меняются, поэтому сверяйте их с документацией на день прогона.
Для сравнения поставьте обоих агентов в самый строгий режим подтверждения и посчитайте, сколько раз каждый просил разрешения. Слишком частые запросы утомляют, и человек начинает подтверждать без чтения. Слишком редкие означают, что часть решений принята без вас. Запишите наблюдение для обоих и вернитесь к нему, когда будете выбирать режим по умолчанию для команды.
Принцип остаётся общим для любого агента: объёмную работу выполняет скрипт или система, модель объясняет и предлагает, человек сверяет результат, а права и подтверждения проверяет сервер. Любому агенту доступ к продуктовым секретам и к команде развёртывания в основном контуре открывают только после отдельного подтверждения человека.
В каком режиме подтверждений вы бы запускали агента на проде?
Diff и тесты
После завершения обоих прогонов запустите один и тот же набор проверок. Первое: полный прогон тестов проекта отдельной командой, своими руками. Второе: diff целиком вместо доклада агента. Третье: сверка с критериями, записанными до запуска. Для Codex CLI документация упоминает команду /review для разбора изменений перед коммитом; её результат считайте подсказкой, а решение остаётся за человеком.
Оценивайте diff по трём вопросам. Совпадает ли он с границей задачи. Читается ли он без пояснений автора. Добавлены ли проверки на повторную отправку наряду с успешным случаем. Условный итог выглядит так: один агент сделал точечную правку и добавил тест на дубль, другой переписал модуль отправки целиком и тесты оставил прежними. Второй вариант может работать, но ревью растягивается, и именно это время сравнение должно учесть.
Полезно заранее решить, что считать провалом. Например, агент изменил файлы вне разрешённой границы, оставил в коде отладочный вывод, отчитался об успешных тестах, которые на деле падают, или завершил работу молча, без итогового описания. Любой из этих случаев получает пометку в таблице и учитывается как расход времени ревьюера. Список провалов заводят до запуска, иначе после прогона его подгоняют под удобный результат.
Скорость ревью измеряйте секундомером у ревьюера вместо оценки на глаз: сколько времени человек читает diff до решения «принять», «принять с правками» или «отклонить». Добавьте число возвратов агенту, то есть сколько раз пришлось уточнять задачу после первой выдачи. Эти два числа важнее скорости самой генерации, потому что человеческое внимание остаётся самым дорогим звеном цепочки.
Когда результаты записаны, дайте таблицу посмотреть второму ревьюеру со стороны. Если его мнение совпало с вашим, вывод устойчив. Если расходится, значит, критерии приёмки были слишком расплывчатыми, и их стоит уточнить до следующего круга.
Выбор для команды
Результат сравнения редко сводится к единственному победителю. Чаще складывается раскладка: один инструмент лучше ложится на задачи с жёсткой границей и тестами, другой лучше справляется с задачами иного рода; какими именно, покажет ваш прогон. Запишите правило в формате «для задач такого рода берём этот агент, для таких-то другой», и пересматривайте его после каждого заметного обновления любого из продуктов.
Учтите организационные факторы: где живёт ваш репозиторий, какие подписки уже оплачены, как устроена политика данных и чью учётную запись допускает служба безопасности. Лимиты и расход влияют на ритм команды; для Codex это разобрано в статье про распределение лимитов Codex в команде, для Claude Code в материале про путь задачи от issue до pull request. Сравнение редактора Cursor с Claude Code вынесено в отдельный текст про выбор между Cursor и Claude Code.
Выберите одну реальную задачу из бэклога с понятным тестом и запустите её на обоих агентах в разных ветках. Занесите в таблицу размер diff, результат тестов, число вопросов и время ревью. Если нужен выбор с учётом политики доступа и данных, опишите нам ваш контур разработки, и мы поможем провести сравнение.