Я прочитала десяток разборов «Copilot vs Claude Code vs Cursor vs Windsurf vs Cline» и поймала себя на мысли:
Все обзоры меряют одно — как быстро агент печатает код. Но на моём боевом Java-проекте на тысячи строк самый «быстрый» агент выдал решение за 12 секунд, а потом 40 минут гонял сборку в терминале, пытаясь заставить код компилироваться. Это втрое больше заходов до зелёной сборки, чем у Veai – агента, который читает ошибки компиляции прямо из индекса IDE, без прогона в терминале. Кто быстрее печатает код — тот дольше его чинит, а типовые сравнения этап починки не считают вовсе.
Чтобы проверить это, я взяла одну и ту же задачу «добавь фичу и покрой её тестами» и дала её трём типам агентов: CLI в терминале (Claude Code, Codex, OpenCode), кросс-IDE плагинам (Cursor через ACP, Copilot, Cline, Kilo Code, Windsurf) и агенту, встроенному в JetBrains Platform (Veai). Меряла не секунды на генерацию, а число итераций до зелёной сборки и расход токенов. Ниже — шесть метрик, которые я добавила, и почему они переворачивают выводы типовых обзоров.
TL;DR
Привычные критерии (цена, скорость, SWE-bench) меряют генерацию, а не результат.
Написать код — первый шаг из пяти. Дальше компиляция, тесты, отладка и рефакторинг — и вот тут агент на терминале, grep и логах сжигает время и токены.
Я добавила шесть технических метрик: корректность сборки, покрытие, данные для тестов, отладка, рефакторинг, запуск с SDK проекта.
Главное различие — в архитектуре: агент опирается на текст модели +
grep/embeddings + логи терминала (у части CLI — ещё LSP) — или на факты из ядра IDE (PSI, diagnostics, debugger, индексы).На больших легаси-базах разрыв максимален:
grepи векторный поиск деградируют по скорости и качеству, индексы IDE работают за константу.
Почему привычные метрики обманывают
SWE-bench и замеры скорости считаются на изолированных задачах. А реальная разработка с агентом выглядит иначе — это цикл из пяти шагов:
Шаг | Что происходит | Кто ускоряет |
|---|---|---|
1. Генерация | агент пишет код | быстрая модель |
2. Компиляция | код собирается или нет | ? |
3. Тесты | прогон, если они есть и не случайные | ? |
4. Отладка | что-то упало, ищем причину | ? |
5. Рефакторинг | правки расходятся по проекту | ? |
Быстрая модель закрывает только шаг 1. На шагах 2–5 агент на терминале буксует: гоняет компилятор в консоли и читает полный лог, вставляет System.out.println, грепает файлы при переименовании. Метрика «секунды на генерацию» про эти шаги не говорит ничего.
Вывод к которому я пришла: скорость генерации ≠ скорость результата.
Где проходит главное различие — в архитектуре
Сравнивать агентов по моделям бессмысленно — Sonnet, GPT-5 и Gemini доступны почти всем (Cursor, Copilot, Windsurf, Kilo Code тянут одни и те же frontier-модели). Разница — в том, на какие факты о проекте опирается агент между вызовами модели.
CLI-агенты (Claude Code, Codex, OpenCode) живут в терминале. Контекст —
grep/glob, чтение файлов, у части есть LSP-диагностика. Сборку и тесты запускают в консоли.Кросс-IDE плагины с общим бэкендом (Cline, Kilo Code, частично Windsurf) рендерят свой UI в окне JB IDE и работают через те же
grep+ embeddings. Cursor в JetBrains вообще подключается по ACP и индексирует проект отдельно от IDE.Агент внутри JetBrains Platform (Veai) вызывает то же, что разработчик кликает в IDE: PSI и индексы для поиска, diagnostics компилятора, рефакторинги, debugger, run-конфигурации с SDK проекта.
Дальше — шесть метрик, на которых эта разница в архитектуре превращается в разницу в счёте за токены.
Шесть метрик, которые я добавила
1. Корректность сборки в реальном времени
Claude Code, Codex, Cursor узнают об ошибке компиляции после запуска сборки — и читают полный лог компилятора. Агент внутри IDE видит ошибки и предупреждения прямо при редактировании файла, через ту же подсветку, что и я. Часть простых ошибок (недобавленный импорт) чинится quick-fix'ами IDE — без повторного вызова модели. Большие модели роняют импорты регулярно, так что это экономит токены на ровном месте.
2. Покрытие тестами: случайное против предсказуемого
Любой агент сгенерирует какие-то тесты. Но данные он берёт случайно — гарантий по покрытию нет: прогнал, получил 60%, дальше как повезёт. Альтернатива — символьное исполнение: код превращается в систему уравнений, они решаются относительно входных данных, и покрытие растёт предсказуемо до нужной цифры. Это разница между «накидать тестов» и «довести ветку до 90%». Под капотом — движки символьного исполнения по языкам (та же идея, что в SBST/Test-Comp — академических соревнованиях по генерации тестов).
3. Данные для тестов: придуманные против реальных
Обычно данные я придумываю сама или беру то, что нагенерила модель, — и получаю тесты на синтетике. Другой путь — присоединиться к живому процессу (прогон e2e или ручной тест в UI) через интерфейс debugger'а и собрать юнит-тесты на реальных данных из рантайма. Внешние зависимости при этом мокируются, чтобы тесты не были хрупкими, а потом агент размножает кейсы по краевым случаям, оставаясь в рамках реалистичных данных.
4. Отладка: дебаггер против принтов
Когда баг не объясняется чтением кода, агент на логах угадывает: вставляет println, перезапускает, читает вывод, повторяет — и так по кругу. Я хочу, чтобы агент работал как я: ставил брейкпоинты, запускал код под отладкой, смотрел значения переменных и проверял гипотезы пошагово. Принты в проект при этом не попадают, а расследование не превращается в серию догадок по консоли.
5. Рефакторинг: grep против действий IDE
Переименование через grep — это поиск по файлам и ручная правка с риском пропустить геттер, сеттер, тест или импорт. Так работают Cline, Kilo Code и CLI-агенты: грепнули, прочитали в контекст, поправили текстом. Rename средствами IDE меняет символ вместе со всеми usages, потому что платформа понимает язык, импорты и проектную модель — тот же Shift+F6, что жму я. Меньше токенов и ноль шансов оставить оборванную ссылку.
6. Запуск с SDK и конфигурациями проекта
Агент, гоняющий компиляторы через терминал, спотыкается, когда стоят несколько версий JDK/Python или когда у проекта десятки run-конфигураций с секретами, профилями и JVM-аргументами. Типичный случай: агент не видит .venv в PyCharm-проекте и настраивает окружение заново. Правильное поведение — находить и запускать run-конфигурации проекта так же, как это делаю я, и брать SDK проекта, а не собирать окружение на ходу.
Сводная таблица
Критерий | Агент на терминале, grep и логах | Агент на фактах из IDE |
|---|---|---|
Кто это | Claude Code, Codex, Cursor (ACP), Cline, Kilo Code | Veai (внутри JetBrains Platform) |
Ошибки компиляции | после прогона в терминале, читают полный лог | сразу при редактировании, из diagnostics |
Простые фиксы | повторный вызов модели | quick-fix IDE без вызова LLM |
Покрытие тестами | случайное, без гарантий | предсказуемое (символьное исполнение) |
Данные для тестов | придуманные/галлюцинации | реальные из рантайм-процесса |
Отладка |
| брейкпоинты и значения переменных |
Диагностика |
| PSI + diagnostics ядра IDE |
Рефакторинг |
| Rename со всеми usages через PSI |
Запуск и сборка | терминал, проблемы с SDK | SDK и run-конфигурации проекта |
Большие легаси-базы | деградация | индексы за константу |
Где разрыв виден сильнее всего
На большом легаси-проекте. grep и векторный поиск там деградируют по скорости и качеству: неделимый код режется по чанкам, поиск промахивается мимо нужного символа. Индексы IDE работают за константу — время поиска не зависит от размера проекта, а первичная индексация даже на 1+ млн строк занимает пару минут, сравнимо с самими JetBrains IDE. Чем больше кодовая база, тем шире разрыв — и тем дороже обходится агент, который каждый раз перечитывает чанки в контекст.
Как я теперь провожу сравнение
Беру ту же задачу, что в типовых обзорах: «добавь фичу и покрой её тестами».
Считаю не секунды генерации, а число итераций до зелёной сборки и суммарный расход токенов.
Проверяю тесты на содержательность: проверяют ли они что-то или просто проходят.
Делаю рефакторинг и проверяю, не осталось ли оборванных ссылок (компиляция + usages).
Повторяю на большом рабочем проекте, а не на маленьком демо-репозитории.
Вывод
Скорость генерации легко измерить и легко вынести в заголовок. Но счёт идёт по итерациям до зелёной сборки, и здесь выигрывает архитектура агента, а не быстрая модель.
И главное: проверить агента на маленьком демо-проекте и на большом рабочем enterprise-проекте — это две разные проверки. На демо работают почти все: проект помещается в контекст, зависимостей мало, grep быстрый. На реальном легаси на миллионы строк с десятками модулей, внешними зависимостями и десятками run-конфигураций вылезают именно те проблемы, о которых шла речь выше. Поэтому выбирайте агента на том проекте, на котором вы будете работать каждый день.
Я выбрала агента, который опирается на факты из IDE, — и предлагаю добавить эти шесть метрик в любое следующее сравнение.