19 апреля 2026 года разработчик провёл жёсткий сравнительный тест: скопировал свой многомодульный Java-монолит в две папки, создал ветки opus_4_6 и codex_5_3, запустил обоих агентов с одинаковым размытым промптом и ждал результата. Единственный критерий — прохождение всех тестов, включая e2e. Никакого ручного контроля, чистый вайбкодинг.
Контекст
Проект — Telegram-бот с агентским loop на самописном FSM и ReAct-паттерне (ранее на Spring AI). Автор отказался от Spring AI из-за неудовлетворительной памяти, скрытого агентского loop и нерабочего кеширования промптов. Код не работал как надо, было много багов. Подписка Claude Max стоила $100 в месяц — токены кончались быстро. OpenAI предложила месяц бесплатной базовой подписки ($20), что дало повод сравнить.
Методология простая до жестокости: агент работает автономно, получает только общий промпт «делай как считаешь нужным», потом запускается review, потом просьба починить — и так по кругу до прохождения всех тестов. Без чтения промежуточных результатов, без подсказок.
Позже был проведён второй эксперимент: Codex 5.3 против gpt_5_5 — на той же кодовой базе, с теми же условиями.
Аналитика
Итог первого теста на поверхности выглядит в пользу Opus: лучше держит архитектуру streaming-пайплайна, чище разделяет слои, правильно фильтрует <thinking>-теги до отправки в Telegram. Codex быстрее тащил прикладные фичи — timeout для stream-вызова, восстановление истории из БД после рестарта, проверку живости URL — но добавлял сложность и concurrency-риски.
Но здесь главный twist эксперимента. Когда автор попросил построить sequence diagram, выяснилось: весь красивый архитектурный код Opus вообще не запускался. Тесты проходили потому, что старый Spring AI streaming всё ещё работал и закрывал e2e-сценарии. Новый ReAct/FSM flow не был реально встроен. Codex тоже не без греха — его ветка падала в REST test slice.
Второй эксперимент подтвердил паттерн: gpt_5_5 предложила аккуратные абстракции, код не выполнялся, баги не нашла. Codex снова дошёл до конца — работающий код, обработка 429 Too Many Requests от Telegram API, батчинг обновлений. Это перекликается с документацией Anthropic: в Claude Code Opus используется для plan mode, а Sonnet — для execution. Сильная модель хороша для планирования и ресёрча; доделать что-то рабочее в автономном режиме — другая история.
Кейсы применения в бизнесе
B2B-SaaS стартап: если нужно быстро доставить фичу в production — Codex в автономном агентском режиме даст работающий, пусть и не идеально архитектурный результат. Используйте более мощную модель для написания архитектурного решения и требований, затем передавайте Codex на реализацию. Это ближе к тому, как Anthropic выстроил план/исполнение в Claude Code.
Корпорация с legacy: Java-монолиты — типичный сценарий. Запускать мощную модель автономно без жёсткого тестового harness — риск получить «красивый» код, который не выполняется. Инвестиция в e2e-тесты до подключения AI-агента окупается: именно тесты стали единственным честным арбитром в этом эксперименте.
SMB и локальный бизнес в КР/СНГ: при ограниченном бюджете вопрос цена/результат острее. Подписка на более дорогую модель не гарантирует лучший автономный результат — стоит тестировать конкретную задачу, а не полагаться на бенчмарки. Codex-подписка в эксперименте оказалась экономнее при лучшем практическом результате.
Кейсы в личной жизни
Разработчик с пет-проектом: схема автора воспроизводима. Напишите e2e-тесты для целевого сценария, скопируйте проект в соседнюю папку, запустите двух агентов параллельно с одинаковым промптом — и пусть тесты решают. Это дешевле и честнее, чем интуитивные оценки.
Контент-мейкер или фрилансер, автоматизирующий рутину: если у вас Telegram-бот или любой другой инструмент с агентским loop — timeout на stream, батчинг обновлений и восстановление памяти после рестарта (все три фичи, которые нашёл Codex) — это базовые вещи, о которых легко забыть. Попросите любую модель провести review именно по этим трём пунктам.
Студент или начинающий разработчик: главный урок эксперимента не про конкретные модели, а про метод. Тесты — единственный честный судья. Код, который выглядит правильным в review, может просто не запускаться. Это справедливо как для AI-агентов, так и для людей.
Как применить сегодня
- Перед запуском AI-агента напишите хотя бы минимальный e2e-тест для целевого сценария — без него невозможно объективно оценить результат.
- Для автономных задач с конкретным критерием успеха попробуйте Codex вместо самой мощной модели — результат может удивить.
- Используйте мощные модели (Opus, o3) для планирования и архитектурного review, а исполнение отдавайте модели, заточенной под coding — это то, что Anthropic сделал в Claude Code по умолчанию.
- После автономного агентского прогона запросите sequence diagram или цепочку вызовов — это выявит мёртвый код, который тесты случайно обходят через старые пути.
- Если токены на Claude Max заканчиваются быстро — проверьте, работает ли кеширование промптов. Spring AI его не поддерживает; на самописном loop это решается явно.