Агент написал код за 12 секунд и чинил его 40 минут: как я на самом деле сравнила ИИ-агентов

Я прочитала десяток разборов «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–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 работают за константу — время поиска не зависит от размера проекта, а первичная индексация даже на 1+ млн строк занимает пару минут, сравнимо с самими JetBrains IDE. Чем больше кодовая база, тем шире разрыв — и тем дороже обходится агент, который каждый раз перечитывает чанки в контекст.

Как я теперь провожу сравнение

1. Беру ту же задачу, что в типовых обзорах: «добавь фичу и покрой её тестами».

2. Считаю не секунды генерации, а число итераций до зелёной сборки и суммарный расход токенов.

3. Проверяю тесты на содержательность: проверяют ли они что-то или просто проходят.

4. Делаю рефакторинг и проверяю, не осталось ли оборванных ссылок (компиляция + usages).

5. Повторяю на большом рабочем проекте, а не на маленьком демо-репозитории.

Вывод

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

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

Я выбрала агента, который опирается на факты из IDE, — и предлагаю добавить эти шесть метрик в любое следующее сравнение.