Почему Codex всё ещё превосходит Claude Code для сложных монолитов на Python

За последний год разработчик, работающий над сложным монолитом на Python, в основном использовал Codex. После месяца тестирования Claude Code с Opus 4.6 и 4.7 он всё равно предпочитает Codex для этой кодовой базы. Приложение — не простой CRUD-сервер; в нём есть новый слой в стиле DDD, старый хорошо структурированный код и хрупкий легаси-спагетти-код. Команда избегает переписывать старые части без необходимости.

Ключевые преимущества Codex

• Принципы harness-инженерии: Codex надёжно следует рабочему процессу harness-инженерии без явных инструкций. Claude делает это только если в AGENTS.md содержится директива вроде «Прочитай exec_plan.md и следуй ему».
• Повторно использует существующие инструменты и шаблоны: Claude чаще создаёт новые инструменты вместо поиска существующих в кодовой базе. В кодовой базе с множеством специфичных для проекта хелперов повторное использование критически важно.
• Лучшее планирование и понимание контекста: Claude часто читает слишком мало перед добавлением новой функциональности. Разработчику приходилось неоднократно поправлять:

«Помести эту функциональность в модуль A, а не в контроллер.»
«Не конструируй объект ответа из статусов, которые ты отправил в запросе. API уже возвращает обновлённый объект — используй этот ответ.»
«Валидируй это в том же модуле, которому принадлежит эта граница.»

Codex чаще замечает отсутствующий контекст и задаёт уточняющие вопросы перед архитектурными изменениями.

Где Claude превосходит

Для фронтенд-работы Opus 4.6 был намного лучше, чем Codex 5.3 и GPT-5.4. Разработчик в настоящее время предпочитает Claude для задач UI. Он ещё не тестировал GPT-5.5 на задачах с большим объёмом UI.

Конфигурация инструментов

Обе LLM используют один общий навык: команды для запуска и остановки Docker Compose и запуска тестов внутри контейнера.

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