Как выбрать лучшего AI-ассистента для разработки: тестируем Codex, Claude и Cursor

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

На вершине все этой гонки — привычные тяжеловесы: OpenAI и Anthropic публично конкурируют за роль главного «мозга» для разработки. С другой стороны, китайские модели вроде DeepSeek и Qwen сокращают разрыв с неожиданной скоростью. Параллельно растёт слой продуктовых команд: Cursor, Cognition и другие стартапы докручивают UX, контекст, интеграции и превращают модели в инструменты, которыми реально хочется пользоваться каждый день.

Но вот проблема: в этом болоте агентов легко утонуть. Один ассистент блестяще дебажит, но плывёт на рефакторинге. Другой силён в Python, но разваливается на TypeScript. Третий пишет убедительные объяснения, но ломает функционал и не замечает очевидные ошибки. Как же выбрать ту модель, которая будет решать все и при этом не ломать намеченные процессы?

Чтобы оценивать кодовые модели, крупные компании давно опираются на бенчмарки. Самый популярный в этой теме — SWE-Bench. Его идея простая: взять реальные GitHub issues, дать ассистенту доступ к репозиторию и проверить, способен ли он починить проблему так, чтобы тесты прошли. Он ясно показывает, где модель помогает решить задачу, а где уходит в галлюцинации и ломает рабочий код.

В статье

• Какой бенчмарк выбрать для теста кодовой модели?

• Почему многие выбирают именно Codex/Claude Code и Cursor как компаньонов по разработке
  ◦ Claude Code
  ◦ Codex
  ◦ Cursor

• Какие задачи брали для прогона

• Результат
  ◦ Сравнение с публичными бенчмарками
  ◦ Сравнение с приватным Python-репозиторием

• Итоговый рейтинг

• Итоговый рейтинг на разных языках

• Разбивка по языкам

• Заключение

Какой бенчмарк выбрать для теста кодовой модели?

На сегодняшний день есть несколько бенчмарков которые проверяют способности LLM. Самая известная версия сегодня — SWE-Bench Verified. Она отличается от обычного SWE-Bench тем, что задачи там тщательно проверены, но есть нюансы: набор построен на open-source репозиториях и пока покрывает только Python. Поэтому, если вы хотите понять, как ассистент ведёт себя на Java/Go/TS/C++ и других языках — одного SWE-Bench Verified уже недостаточно.

Мы в Doubletapp решили закрыть этот пробел и собрали свой SWE-Bench-подобный бенчмарк на 15+ языках, с нормальными тестовыми контурами и едиными правилами оценки — ранее мы уже писали, как именно его собирали.

Дальше всё честно: мы прогоним задачи через самые заметные решения на рынке — Codex (GPT-5.3 Codex), Claude Code (Opus и Sonnet), Cursor (во всех конфигурациях) — и посмотрим, кто лучше решает, кто лучше рассуждает, кто стабильно дебажит и рефакторит, не превращая фикс в лотерею, и экономит ваши драгоценные кредиты.

Почему многие выбирают именно Codex/Claude Code и Cursor как компаньонов по разработке

За последние годы наша команда испробовала все взятые для сегодняшнего теста инструменты для кодинга: Codex/GPT-5.3, Claude Code/Opus 4.6, Cursor (все 3 модели) в разных конфигурациях. И собрав все отзывы воедино мы поняли, что идеального ассистента нет и, скорее всего, никогда не будет. У каждого есть свой любимчик, а все разговоры в стиле «Opus похоронил GPT» обычно заканчиваются тем, что человек просто тестировал один и тот же тип задач.

Ниже хотели бы без фанатизма расписать, что мы заметили: в чем ассистент реально хорош, где раздражает, и где у него объективные минусы.

Claude Code

Claude Code сейчас выглядит, пожалуй, самым привлекательным агентом именно для тех, кто много пишет код и работает с масштабными проектами. Он очень уверенно справляется с проектом целиком, хорошо держит контекст и в целом дает ощущение, что ты пользуешься реально умным решением. Плюс Anthropic довольно активно развивают свои продукт: регулярно улучшают качество модели, добавляют новые возможности для агентского режима и в целом заметно двигают рынок вперёд. Многие идеи, как MCP, которые сегодня уже воспринимаются как стандарт для AI-инструментов, у них появились одними из первых.

Что мы также выделили для себя:

1. Claude хорошо понимает структуру проекта, связи между модулями и архитектурные паттерны, за счёт чего уверенно справляется не только с локальными правками, но и с более крупным рефакторингом. Особенно заметно это на больших кодовых базах, где важно быстро разобраться в устройстве проекта.

2. Хорошие размышления. Не просто тыкает на проблему, а подробно и понятно объясняет ее суть.

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

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

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

2. Относительно долгие размышления на Sonnet. Opus, конечно, самая сильная кодовая модель на рынке и думает быстро, но и стоит соответственно дорого. А вот с Sonnet бывает по-другому: иногда он уходит в размышления на 10 минут, даже когда задача простая и ты буквально написал, откуда взять и куда положить. Справедливости ради, такое случается довольно редко, но когда случается, то это заметно сбивает ритм работы.

3. Только терминал. В отличие от Cursor, здесь нет визуальной IDE-обёртки. Для тех, кто привык к работе в терминале, это не проблема, но порог входа выше, и часть разработчиков это просто отпугивает.

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

Codex

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

Главный плюс Codex — хороший баланс между качеством и стоимостью. Он всё ещё даёт сильный результат на кодовых задачах, но при этом не так быстро съедает бюджет, как более тяжелые и дорогие конкуренты. Поэтому в реальной работе это может быть более удобный вариант, особенно если задач много и они идут потоком.

Из остальных плюсов также хотим выделить:

1. Хорошо подходит для регулярного использования. Если вы часто пишете код, чините баги, вносите мелкие и средние изменения в проект и не хотите каждый раз думать о стоимости очередного прогона, такой инструмент ощущается более практичным и предсказуемым.

2. Приемлемая рациональность. Это не обязательно тот инструмент, который всегда даст самый глубокий разбор или самый умный ответ на сложной архитектурной задаче, но как рабочий агент на каждый день он выглядит очень убедительно.

3. Достаточно быстрый. С выходом GPT-5.3-Codex-Spark модель выдаёт больше 1000 токенов в секунду. Код генерируется практически мгновенно, и это меняет ощущение от работы с инструментом.

Из минусов:

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

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

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

Cursor

С Cursor картина получилась более неоднозначной. В наших прогонах он показал смешанные результаты: многое, похоже, сильно зависит не только от самой модели, но и от того, насколько удачно она сочетается с внутренними тулзами, агентной логикой и общими гайдлайнами продукта.

Если внутри стоит не самая сильная модель, Cursor местами заметно проседает. Возникает ощущение, что в таких конфигурациях ему не всегда хватает качества инструментов и общего видения задачи, из-за чего результат получается слабее, чем ожидаешь от такого зрелого продукта.

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

Главный плюс Cursor — это удобство. По визуальной части и общему пользовательскому опыту это до сих пор один из самых приятных инструментов на рынке. Cursor многое делает для того, чтобы AI-кодингом было удобно пользоваться не только тем, кто уверенно живет в терминале, но и разработчикам, которые привыкли к более привычному интерфейсу IDE.

Именно поэтому Cursor остаётся сильным повседневным инструментом. Он хорошо упакован, понятен, удобен в использовании и в целом снижает порог входа в агентные сценарии разработки.

Больше плюсов:

1. Разнообразие моделей. Можно поставить Opus на сложные задачи, а на быстрые фиксы переключиться на Sonnet или что-то полегче. По сути собираешь свой стек под необходимую задачу.

2. Всё в одном месте. Инлайн-подсказки, чат и агентный режим живут прямо в IDE, и тебе не нужно переключаться между терминалом и редактором. Для повседневной работы это экономит кучу контекстных свитчей.

Из минусов: качество у Cursor ощущается менее стабильным, чем хотелось бы. Очень многое зависит от выбранной модели, и не каждая конфигурация даёт действительно сильный результат. Поэтому Cursor легко полюбить за UX, но с точки зрения качества решения задач он не всегда одинаково надежен.

Больше минусов:

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

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

Личные впечатления — это, конечно, важно, но субъективно. Кому-то в нашей команде нравится скорость, кому-то — глубина рассуждений, а кто-то выбирает инструмент просто потому что привык к интерфейсу. Поэтому мы решили проверить всё это цифрами: прогнали каждого ассистента через open-source и приватный бенчмарки на разных языках программирования, чтобы посмотреть, у кого действительно сильнее мозги, когда дело доходит до реальных задач.

Какие задачи брали для прогона 

У почти любого бенчмарка агентов есть одна и та же проблема: можно подобрать такой набор задач, на котором итоговая таблица будет выглядеть красиво, но мало что скажет о реальной работе модели. Мы старались этого избежать и использовали для прогона собственный мультиязычный бенчмарк в формате SWE-Bench с разными типами проектов и разным масштабом правок.

Это важно ещё и потому, что многие популярные бенчмарки открыты. Это хорошо для прозрачности и воспроизводимости, но у этого есть и обратная сторона — часть задач модели или агентские пайплайны могли уже видеть раньше, например, во время обучения, в публичных разборах или даже в собственных eval-процессах. Поэтому результат может отражать не только умение решать новую задачу, но и степень знакомства с самим бенчмарком.

Внутри среза у нас оказались очень разные проекты
‣ В Go
– [gocron](https://github.com/go-co-op/gocron),
– [fasthttp](https://github.com/valyala/fasthttp),
– [go-sql-driver/mysql](https://github.com/go-sql-driver/mysql),
– [aws-sdk-go](https://github.com/aws/aws-sdk-go),
– [miekg/dns](https://github.com/miekg/dns) — планировщик задач, HTTP-библиотека, драйвер MySQL, SDK и DNS-библиотека.

‣ В Kotlin
– [detekt](https://github.com/detekt/detekt),
– [ktlint](https://github.com/pinterest/ktlint),
– [arrow](https://github.com/arrow-kt/arrow) — статический анализ, форматирование кода и функциональные abstractions/codegen.

‣ В Rust
– [fd](https://github.com/sharkdp/fd),
– [minijinja](https://github.com/mitsuhiko/minijinja).

‣ В TypeScript
– [nest](https://github.com/nestjs/nest),
– [styled-components](https://github.com/styled-components/styled-components). 

‣ В PHP
[Carbon](https://github.com/briannesbitt/Carbon), где много задач связано со временем, интервалами и локалями.

Из каких репозиториев состоял прогон

В выборке заметно преобладают багфиксы, и это в целом отражает специфику open-source репозиториев. Небольших исправлений в реальных PR обычно больше, чем крупных фич или архитектурных изменений. Но даже внутри этого перекоса задачи были очень разными — от дат, интервалов и локалей до сетевых контрактов, CLI-семантики, сериализации, обработки ошибок и edge кейсов в линтерах и форматтерах. При этом выборка не сводится только к фиксам, особенно среди Rust-проектов на более ранней стадии, встречались и feature-задачи, где нужно было не чинить старое, а корректно встраивать новое.

Типы задач

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

В результате сравнение не сводится к одному удобному режиму работы. Модель проверяется и на локальных исправлениях, и на задачах, где изменение затрагивает несколько связанных частей проекта. Это делает итоговый прогон более показательным и позволяет смотреть не только на общий счёт, но и на устойчивость агента на задачах разного масштаба.

Насколько локальными были изменения

Результат

Итоговый счёт в нашей таблице стоит читать не как абсолютный рейтинг моделей на все случаи жизни, а как результат в конкретном и довольно жёстком сценарии: фикс реальных багов в мультиязычных репозиториях, с единым пайплайном проверки и без подгона под один любимый стек. Именно поэтому здесь важен не только общий счёт, но и то, насколько стабильно агент держится между языками. Один и тот же ассистент может выглядеть очень убедительно на Kotlin и Rust, но заметно проседать на TypeScript или Go. Для практики это часто важнее, чем красивая цифра на одном публичном Python-бенче.

Сравнение с публичными бенчмарками

Если смотреть на наши результаты в контексте публичных бенчмарков, картина получается довольно показательная. SWE-Bench Verified до сих пор остаётся самым узнаваемым ориентиром: это 500 вручную проверенных задач, но он по-прежнему завязан на Python-репозитории. Поэтому высокий результат на Verified хорошо показывает силу модели на открытых Python-issue, но слабо отвечает на вопрос, как тот же агент поведёт себя на других языках. Это особенно важно сейчас, когда лучшие публичные результаты на Verified уже вышли в зону 76%+, то есть бенч постепенно превращается из стресс-теста в более узкий индикатор качества на публичном Python-домене.

На этом фоне SWE-rebench выглядит интереснее именно как поправка на переобученность на бенч. Его авторы прямо позиционируют набор как continuously evolving и decontaminated: окно задач двигается по времени, а сами инстансы подбираются так, чтобы уменьшить эффект знакомства модели с конкретными issue. На публичном лидерборде за январское окно 2026 года у лидеров речь идёт уже не о 70%+, а примерно о 50% с небольшим. Это важный сигнал, как только бенч становится более свежим и хуже запоминаемым, разрыв между моделями снижается, а абсолютные проценты падают. В этом смысле наш приватный и мультиязычный прогон ближе по духу именно к SWE-rebench, чем к классическому Verified. Он тоже хуже поддаётся эффекту публичной натренированности и сильнее наказывает за слабую переносимость между стеками.

Отдельно стоит сравнить наш сетап с Multi-SWE-bench. Это уже прямой родственник нашей постановки задачи: мультиязычный SWE-bench-подобный набор, который был создан именно как ответ на ограничение Python-only. У Multi-SWE-bench большой плюс в масштабе: в paper и официальном репозитории заявлены 1,632 задач на 7 языках. Но у такого масштаба есть и обратная сторона: публичные baseline-результаты там исторически были довольно низкими, а сам бенчмарк сильнее распадается на языковые и инфраструктурные подзадачи. То есть Multi-SWE-bench хорошо показывает общую сложность мультиязычного SWE-сценария, но для прикладного сравнения конкретных агентов часто удобнее более компактный и контролируемый срез, как у нас: одинаковое число задач на язык, единый харнесс и понятная таблица без перекоса в один язык или один тип репозиториев.

Если упростить, то разница между этими тремя ориентирами такая.
‣ SWE-Bench Verified отвечает на вопрос: насколько модель хороша на публичных Python-issue.
‣ SWE-rebench отвечает на вопрос: насколько этот результат держится на свежих и хуже заучиваемых задачах.
‣ Multi-SWE-bench отвечает на вопрос: что происходит, когда мы выходим за пределы Python и просим агента решать реальные issue в нескольких языках сразу.
Наш прогон находится ближе всего к третьему сценарию, но при этом остаётся более компактным и управляемым для честного side-by-side сравнения конкретных продуктовых агентов.

Сравнение с приватным Python-репозиторием

Отдельно мы сверили результаты с прогоном на нашем приватном Python-репозитории. Это важная проверка, потому что даже публичные SWE-бенчи, включая Verified, всё равно остаются open-source-наборами с хорошо изученной структурой задач. Приватный репозиторий убирает этот фактор и лучше показывает, насколько модель переносит свои навыки в боевой код, который она точно не видела ни в обучении, ни в чужих разборах. Если на публичных Python-бенчах агент выглядит сильнее, чем на приватном Python-коде, это обычно говорит не о плохой модели, а о том, что публичные оценки уже частично отражают familiarity effect, а не только реальное качество.

Итоговый рейтинг

В этом срезе картина получилась особенно показательной. На публичных бенчмарках мы привыкли к ситуации, где в верхней части таблицы обычно доминируют GPT-модели и их производные конфигурации. Но на закрытом Python-репозитории лучший одиночный запуск показала не GPT-линейка, а claude-code / opus-4-6: 34/50. Для сравнения, лучший результат у codex в этом же прогоне составил 30/50, а версия на gpt-5.3-codex закончила с 29/50. То есть на production закрытом коде лидерство сместилось в сторону Opus, хотя на публичных таблицах интуитивное ожидание у многих уже обратное.

Если смотреть не на лучший запуск, а на средний результат по серии, вывод остаётся тем же. Claude-code по четырём прогонам дал в среднем 56.94%, а codex по трём прогонам — 54.94%. Разница не выглядит драматической, но она важна именно как сигнал о переносимости: когда мы уходим из публичного benchmark-сценария в приватный репозиторий, меняется не только абсолютный уровень, но и сам порядок лидеров. Это хороший аргумент против слишком буквального чтения публичных лидербордов: они полезны как ориентир, но не гарантируют, что тот же агент окажется лучшим на внутреннем коде компании.

Итоговый рейтинг на разных языках

Разбивка по языкам

Заключение

Если вы дочитали до этого момента, то наверняка уже поняли главное: идеального кодового ассистента не существует. И это не маркетинговая оговорка — это реальность, с которой мы столкнулись и в прогонах, и в повседневной работе.

По результатам наших бенчмарков, Claude Code на Opus 4.6 забрал первое место на приватном Python-репозитории с результатом 68%, а Cursor на той же модели неожиданно вырвался вперёд в тестах на нескольких языках — 71%. Codex показывает стабильную надежность с хорошим балансом цены и качества, хоть и отдельные модели не показали столь выдающихся результатов, как в Cursor и Claude Code.

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

Рынок кодовых ассистентов сейчас меняется настолько быстро, что любая расстановка сил может сдвинуться уже через пару месяцев. Но одно точно не изменится: лучший ассистент — это тот, который вы протестировали на пробах и ошибках. Попробуйте каждый, прогоните на своих задачах, послушайте ощущения. Потому что в конечном счёте код пишете вы, а ассистент — это просто инструмент, который должен вам помогать, а не мешать.