Claude Opus 4.6 и GPT-5.3-Codex: почему сравнивать только модели становится бессмысленно
Как отделить качество модели от инструментов, контекста, execution loop и правил среды агента.

Два релиза в один день

5 февраля 2026 года Anthropic представила Claude Opus 4.6, а OpenAI выпустила GPT-5.3-Codex. Обе компании говорят о сложных задачах, coding, reasoning и длительной агентной работе. Для разработчика напрашивается простой вопрос: какая модель лучше?

Такой вопрос всё ещё имеет смысл, но его недостаточно. В реальном проекте мы почти никогда не работаем с моделью в чистом виде. Мы открываем Codex, Claude Code или другую агентную среду, которая сама собирает контекст, предоставляет инструменты, управляет разрешениями и решает, когда запускать следующий шаг.

Model
+ Tools
+ Context
+ Instructions
+ Sandbox
+ Execution loop
+ Permissions
= Coding agent

Поэтому победа Codex над Claude Code в конкретной задаче ещё не доказывает превосходство GPT-5.3-Codex над Claude Opus 4.6. Она показывает, что лучше сработала вся система.

Мы смешиваем два разных сравнения

Первое сравнение — модельное. Двум моделям дают одинаковый prompt, один набор файлов, те же инструменты, лимиты и бюджет вычислений. Так можно исследовать reasoning, точность изменений или способность исправить ошибку после результата теста.

Второе — продуктовое. Codex и Claude Code запускают в их штатных средах и дают реальную задачу в репозитории. Здесь оценивается уже coding agent целиком: насколько хорошо он нашёл код, выбрал инструменты, удержал ограничения, проверил diff и объяснил результат.

Что делает agent harness

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

Допустим, нужно исправить редкий 401 после обновления access token. Самой модели недостаточно знать PHP и OAuth. Агенту понадобится найти authentication flow, проследить работу middleware, открыть тесты, воспроизвести сбой, изменить код и снова запустить suite.

THINK → ACT → OBSERVE → CORRECT
          ↑                 │
          └──── harness ────┘

Если среда умеет только читать и записывать файлы, модель будет проверять решение мысленно. Если доступны shell, Git и PHPUnit, ошибка становится новым наблюдением. Даже при одной и той же модели это два разных режима работы.

Где именно меняется результат

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

Поиск и контекст репозитория

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

Инструкции проекта

AGENTS.md, архитектурные документы и команды проверки меняют реализацию не меньше prompt. Правило «не размещать бизнес-логику в controller» защищает проект от технически корректного, но архитектурно плохого решения. Доступ к документу ещё не гарантирует соблюдение правила: harness должен вовремя включить его в рабочий контекст.

Execution loop

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

Разрешения и sandbox

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

Даже benchmark измеряет не только название модели

Методология важнее строки в рейтинге. В примечаниях к релизу Claude Opus 4.6 Anthropic указывает, что запуски Terminal-Bench 2.0 использовали Terminus-2 harness, а OpenAI Codex CLI — собственную конфигурацию. Для других оценок перечислены web search, code execution, compaction и разные бюджеты. Компания отдельно показывает, что добавление multi-agent harness меняло результат одного из тестов.

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

Я бы не доверял сравнению coding agents без трёх деталей: точной версии продукта, списка разрешённых инструментов и условий остановки. Фраза «дал обоим одну задачу» сама по себе почти ничего не говорит.

Как проверить именно модели

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

• один snapshot репозитория и один текст задачи;
• одинаковый набор файлов, project rules и доступных команд;
• одинаковые лимиты времени, токенов и tool calls;
• одну версию тестов и единые acceptance criteria;
• одинаковую политику человеческого вмешательства;
• несколько повторов, а не один удачный запуск.

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

Как сравнить Codex и Claude Code как продукты

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

Возьмём Laravel-задачу:

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

Оба агента получают чистые копии одного commit. Вмешательства разработчика либо запрещены, либо записываются дословно. Время заканчивается по общему лимиту, а готовность определяют внешние тесты, которых агент не видел. Так остаётся реальная продуктовая работа, но исчезает возможность объявить успех по собственному отчёту агента.

Что записывать кроме итогового кода

Строка tests pass слишком груба. Два агента могут получить зелёный suite, но один переиспользует существующий паттерн в трёх файлах, а второй добавит одиннадцать файлов и параллельно изменит публичный сервис.

RESEARCH
- найден ли существующий паттерн
- какие файлы и правила прочитаны

IMPLEMENTATION
- размер diff и лишние изменения
- корректность при конкурентных запросах
- совместимость с архитектурой

VERIFICATION
- какие тесты запущены
- исправлены ли собственные failures
- проверен ли итоговый diff

COST
- время, токены и стоимость
- число вмешательств человека

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

Как не испортить вывод

После такого эксперимента корректный итог звучит конкретно: «в этой версии продуктов на Laravel-задаче Codex быстрее нашёл существующий паттерн, а Claude Code сделал меньший diff». Он не превращается автоматически в универсальное «GPT лучше Claude».

Результат зависит от класса задач. Один harness может быть сильнее в исследовании большого legacy-репозитория, другой — в коротких исправлениях с быстрым test loop, третий — в работе через браузер. Важны и локальные условия: Docker, скорость тестов, объём документации, ограничения сети и качество project rules.

Поэтому я выбираю coding agent не по одному leaderboard. Сначала смотрю, как система работает с моим репозиторием: находит ли принятые решения, соблюдает ли границы, умеет ли доказывать готовность и сколько review оставляет человеку.

Сравнивать нужно правильный объект

Claude Opus 4.6 и GPT-5.3-Codex остаются центральными компонентами своих агентных систем. Качество модели важно: слабое reasoning не исправить удобной кнопкой запуска тестов. Но небольшая разница между сильными моделями легко перекрывается качеством поиска, контекста, инструментов и execution loop.

Поэтому сравнение моделей не исчезает — ему нужны контролируемые условия. А сравнение Codex и Claude Code должно честно называться сравнением coding agents.

Главный практический вопрос теперь звучит не «Claude или GPT?», а точнее: какая связка модели и agent harness надёжнее выполняет мой класс инженерных задач. Именно на этом уровне разработчик получает результат, который потом попадёт в production.