За последний год я поставил на прод все три. Claude Code тянет бэкенд на NestJS, Cursor держит фронтенд-команда из четырёх человек, Codex гоняем как второго ревьюера поверх Claude в CI. Три раза видел, как один и тот же вопрос в чате команды звучит одинаково: «а что вообще выбрать, у нас бюджет на один инструмент». Каждый раз отвечал по-разному, потому что ответ зависит не от того, какой инструмент «лучше», а от того, какую задачу решает команда. Вот то, что я бы сказал себе полгода назад, когда сам выбирал.

Коротко о себе: Full-Stack JS архитектор, стек TypeScript, Node.js, NestJS, React. С Claude Code в продакшене с 2024 года, про перестройку 200К-строчного проекта под ежедневную работу с агентом писал отдельно.

1. Это не три варианта одного инструмента

Первая ошибка, которую я видел в трёх разных командах: сравнивать все три по одному чек-листу, будто это три модели телефона. Это не так. У них разная модель работы, и часть сравнений просто не имеет смысла.

Claude Code это CLI-агент. Живёт в терминале, работает с файловой системой напрямую, не привязан к редактору. Можно гонять его в CI, в отдельном tmux-сеансе, на удалённой машине без GUI вообще.

Cursor это форк VS Code с AI, встроенным в каждый слой интерфейса. Автокомплит, чат, композер-режим для мультифайловых правок. Инструмент редактора, не инструмент терминала.

Codex это облачный агент от OpenAI, который берёт задачу, работает в изолированной песочнице и возвращает диф или PR. Из терминала его тоже можно дёргать через CLI, но по духу это ближе к «делегировать таску и уйти», чем к парному программированию.

Если команда сравнивает Cursor с Claude Code по вопросу «удобно ли работать в интерфейсе», сравнение нечестное. Claude Code не про интерфейс редактора, он про то, что можно засунуть в любой пайплайн. Если сравнивать Codex с Cursor по вопросу «сколько раз в минуту он подсказывает автокомплит», тоже нечестно, Codex не для этого придуман.

2. Терминал, IDE или облако: три разные модели внимания

Здесь разница ощущается физически, не на уровне фичей.

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

С Cursor работа плотнее. Автокомплит подсказывает на каждой строке, композер-режим держит контекст открытых файлов. Это подходит, когда задача формулируется по ходу дела, когда я сам ещё не до конца понимаю финальную форму кода и хочу видеть предложения в реальном времени, а не диф целиком в конце.

С Codex работа ещё более отвязанная. Ставлю задачу, ухожу на созвон, через двадцать минут смотрю PR. Для этого нужно уметь написать задачу настолько точно, чтобы не пришлось разговаривать с агентом по ходу выполнения, там нет живого диалога в процессе, только результат.

На практике я не выбираю один режим внимания на весь день. Утром формулирую крупные задачи и раздаю их Claude Code и Codex параллельно, чтобы не ждать. Днём сажусь в Cursor на точечные правки, где нужен диалог в реальном времени.

3. CLAUDE.md, .cursorrules и AGENTS.md: три способа объяснить агенту проект

У каждого инструмента свой файл конвенций, и это не мелочь, от него зависит процентов сорок качества результата.

CLAUDE.md у Claude Code читается при каждом старте сессии. У меня в проекте держу его до 8К символов, только постоянный контекст: архитектурные границы, что запрещено, где искать примеры. Остальное лежит в отдельных файлах и подгружается по требованию.

Cursor использует .cursor/rules, набор markdown-файлов с front-matter, где можно указать, для каких паттернов файлов правило активно. Это гибче в теории, правило про тесты грузится только когда трогаешь тестовый файл, правило про API-слой только когда трогаешь контроллеры. На практике настройка этой гранулярности у меня заняла три вечера, и я не уверен, что она стоила потраченного времени против одного плоского файла.

Codex ориентируется на AGENTS.md, тот же формат, который начали принимать несколько инструментов как общий знаменатель. Плюс в том, что один файл переиспользуется между Codex и другими агентами, которые его тоже читают. Минус в том, что он не такой богатый по возможностям, как система правил Cursor, работает скорее как единая точка входа, а не как система с условной загрузкой.

Что реально важно, а не то, какой формат богаче: во всех трёх случаях правило «что нельзя» работает сильно лучше правила «как надо». Писал уже про это на примере CLAUDE.md, тут не изменилось ничего. «Не используй any» агент соблюдает. «Пиши типобезопасный код» агент кивает и делает по-своему.

4. Автономность и разрешения: кто сколько может сделать без вопроса

Здесь три инструмента разошлись сильнее всего, и это самая недооценённая ось выбора.

Claude Code по умолчанию спрашивает перед почти каждым действием, но permissions настраиваются гранулярно: можно разрешить чтение файлов без вопросов, запретить деструктивные bash-команды, дать зелёный свет на правки в конкретных папках. У меня в settings.json acceptEdits включён только для тестовых файлов и файлов с покрытием больше 80%, для остального инструмент спрашивает каждый раз.

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

Codex по конструкции более автономный. Задачу ставишь один раз, дальше агент работает в песочнице до результата без диалога. Это одновременно преимущество и риск. Преимущество, потому что не нужно сидеть рядом и отвечать на уточняющие вопросы. Риск, потому что если задача сформулирована неточно, узнаешь об этом только когда PR уже готов, а не на середине пути.

За полгода поймал две ситуации, где автономность Codex сыграла против: агент переписал контракт публичного API вместо того, чтобы расширить его, потому что формально решение было проще и «правильнее». Заметил на этапе ревью, откатил. С Claude Code такое ловится раньше, потому что диалог идёт по шагам и я вижу план до того, как код написан.

5. MCP и интеграции: у кого шире экосистема прямо сейчас

Model Context Protocol стал общим стандартом, и все три инструмента его поддерживают, но глубина интеграции разная.

У Claude Code MCP встроен на уровне первого класса, конфиг в .mcp.json, серверы подключаются без плясок. У меня в проекте висит восемь MCP-серверов одновременно: Postgres, GitHub, Notion, Playwright, и инструмент их использует без напоминаний, если в правилах явно прописано, для каких задач какой сервер брать.

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

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

Если для команды MCP не абстракция, а рабочий инструмент, то есть реально нужно, чтобы агент лазил в БД или тикет-трекер по ходу задачи, разница между Claude Code и остальными двумя ощутимая, не на уровне «тоже поддерживается», а на уровне «работает без напоминаний».

6. Экономика: подписка, API, кредиты

Три разные модели оплаты, и здесь легко просчитаться, если считать по прайс-листу, а не по реальному использованию.

Claude Code продаётся и по подписке (Claude Max), и по API. На подписке команда из пяти человек у меня укладывается в $150-200 на человека в месяц при плотном использовании. На API вышло бы дороже при том же объёме, потому что подписка даёт эффективный дисконт на объём токенов, но зато на API нет rate limit подписки, который иногда режет в пиковые дни.

Cursor берёт за подписку с включённым количеством «быстрых» запросов к топовым моделям, дальше запросы идут медленнее или с доплатой. Команда из четырёх фронтендеров у меня укладывается в стандартный план, но при активном композер-режиме на большие рефакторинги упирались в лимит быстрых запросов в последнюю неделю месяца дважды за полгода.

Codex через API считается по токенам напрямую, без абонентской модели. Для команды, которая гоняет его как второго ревьюера по расписанию, а не постоянно, вышло дешевле, чем городить ещё одну подписку. У нас Codex-ревью одного PR обходится в среднем $0.4-0.7 в зависимости от размера диффа.

Реальный вывод по деньгам не «что дешевле», а «что дешевле при вашем паттерне использования». Постоянная плотная работа весь день, подписка почти всегда выгоднее API. Точечное использование по расписанию, API без подписки выгоднее. У нас в итоге смешанная модель: подписка на Claude Code для ежедневной разработки, API-биллинг на Codex для CI-ревью, потому что паттерны использования разные внутри одной команды.

7. Легаси и большие кодовые базы

Про миграцию 200К строк JS в TypeScript я писал отдельно, и там был именно Claude Code, не случайно. На большой legacy-базе критично не то, насколько умная модель, а то, насколько инструмент умеет работать с контекстом за пределами одного файла.

Claude Code в терминале свободно бегает по всему дереву проекта, читает столько файлов, сколько нужно для задачи, без ограничения «открытые вкладки». Для рефакторинга, который трогает пятнадцать файлов сразу, это то, что нужно.

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

Codex на легаси-задачах работает неровно. Автономность, которая хороша для чётко сформулированных задач, становится проблемой, когда правило проекта нигде явно не задокументировано, а живёт только в голове у сеньоров. В greenfield-части задачи Codex быстрый и точный. В brownfield-части, где нужно сначала понять недокументированное поведение, а потом аккуратно его не сломать, автономный режим без диалога рискованнее.

8. Одна и та же задача, три раза

Чтобы не спорить абстрактно, прогнал через все три инструмента одну и ту же реальную задачу из бэклога: добавить rate limiting на публичный эндпоинт с настраиваемым лимитом на пользователя, плюс тесты, плюс обновление OpenAPI-схемы. Задача среднего размера, три файла, один новый модуль, покрытие тестами обязательно.

Claude Code: 14 минут от постановки задачи до зелёного CI. Инструмент сам нашёл похожий guard в проекте, повторил паттерн, добавил тесты по образцу соседних. Одна правка руками: неправильно посчитал дефолтный лимит из конфига, поправил за минуту.

Cursor в композер-режиме: 9 минут до рабочего кода, но без полного набора тестов с первого захода, композер сгенерировал happy path тест и пропустил edge case на превышении лимита. Пришлось попросить отдельно. С учётом второго прохода вышло 16 минут итого.

Codex: поставил задачу, ушёл на 20-минутный созвон, вернулся к готовому PR. Код рабочий, тесты полные, но лимит был захардкожен вместо чтения из конфига, потому что в задаче я не указал явно, что лимит должен быть настраиваемым через переменную окружения, только сказал «настраиваемый лимит». Агент интерпретировал это как параметр функции, не как конфиг. Правка заняла три минуты, но её нельзя было сделать, пока я не вернулся с созвона.

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

9. Командная работа

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

У Cursor тут преимущество, потому что это IDE, и вокруг него уже есть team-фичи: общие настройки правил на репозиторий, единый биллинг на команду через организацию, видимость, кто сколько токенов тратит. Онбординг нового разработчика в команду с готовым .cursor/rules занимает пятнадцать минут, установил Cursor, открыл репозиторий, правила подхватились сами.

Claude Code командную работу решает менее централизованно, CLAUDE.md версионируется в git вместе с кодом, что хорошо для консистентности, но нет встроенного дашборда потребления на команду, приходится собирать через API вручную или сторонними инструментами.

Codex в командном контексте у нас работает как часть CI, а не как персональный инструмент разработчика, поэтому вопрос онбординга не стоит так остро, конфиг один на репозиторий, а не на человека.

Если у команды нет отдельного человека, который любит настраивать инфраструктуру разработки, Cursor из коробки требует меньше возни на старте. Если такой человек есть и хочется гибкости, Claude Code даёт больше контроля ценой того, что этот контроль нужно настраивать руками.

10. Где каждый инструмент ломается

Честный раздел, потому что маркетинг у всех трёх инструментов рассказывает только про успехи.

Claude Code ломается на задачах, где нужна быстрая визуальная обратная связь, вёрстка пиксель в пиксель, тонкая работа с CSS-анимациями. Терминальный диалог для такого медленнее, чем инлайн-редактор с превью.

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

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

Ни один из трёх не ломается «вообще», у всех есть предметная область, где они слабее остальных двух. Выбор инструмента без учёта этого списка почти гарантированно приведёт к разочарованию через месяц.

11. Матрица выбора

Свёл в короткое правило, которым пользуюсь сам, когда советую инструмент новой команде.

Маленькая фронтенд-команда, задачи точечные, нужна быстрая визуальная обратная связь: берите Cursor. Онбординг быстрый, интерфейс привычный для тех, кто уже сидел в VS Code.

Бэкенд-команда с большой кодовой базой, нужен CLI, CI-интеграция, гибкий контроль permissions: берите Claude Code. Дороже по настройке на старте, окупается на масштабе.

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

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

12. Что я бы сказал себе полгода назад

Не начинать с вопроса «какой инструмент лучше». Начинать с вопроса «какая у нас модель работы»: сколько в команде людей, где легаси, а где greenfield, нужна ли автономность или нужен диалог по каждому шагу. Ответ на эти вопросы почти всегда определяет выбор инструмента раньше, чем сравнение фичей.

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

Итог

Три инструмента, три разные модели работы, три разных набора компромиссов. Ни один не универсальный победитель, и я бы насторожился, если бы кто-то сказал обратное. У меня в проде все три одновременно, каждый закрывает свою часть процесса. Если выбираете один на команду, отталкивайтесь от модели работы, а не от рейтинга в очередном сравнительном посте, включая этот.

Про опыт с CLAUDE.md и настройками Claude Code для архитектора писал отдельно, ссылки в профиле. Если интересно, как строить такую же связку MCP-серверов под конкретный стек, пишите в комментариях, разберу отдельным постом.