Аналоги Claude Code: терминальный агент, редактор с моделью и дополнение в IDE

Что это решает

Аналоги Claude Code разумно выбирать по одному признаку, который виден не сразу: кто в связке запускает команды и читает их вывод. По этому признаку инструменты делятся на три класса — терминальный агент, редактор со встроенной моделью и дополнение к чужой IDE, — и внутри класса они похожи сильнее, чем между классами. Сравнение вида «Cursor против Claude Code» идёт поперёк осей и потому редко приводит к решению. Цена ошибки измеряется не подпиской, а месяцем работы в инструменте, который не умеет того, ради чего его брали.

Как устроено

Класс 1. Терминальный агент

Примеры: Claude Code, OpenAI Codex CLI, Gemini CLI, Aider, OpenCode.

Живёт в оболочке. Цикл работы: получил задачу — прочитал файлы — изменил — запустил тест, линтер или сборку — прочитал вывод — поправил. Ключевое здесь то, что команды выполняет сам инструмент и сам же читает результат, поэтому цепочка идёт без человека посередине.

Следствия механики:

интерфейс текстовый, значит инструмент вызывается из CI, по SSH, из cron, из скрипта;
проект виден как файловая система и git, а не как индекс редактора: работают grep, find, git log, make;
многофайловые заходы идут естественно — переименование по всему репозиторию, миграция API, правка сотни шаблонов;
всё, что умеет оболочка, инструмент тоже умеет, включая опасное. Права ограничивают снаружи.

Класс 2. Редактор со встроенной моделью

Примеры: Cursor, Windsurf, Zed.

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

Следствия механики:

самая короткая петля на мелких правках — выделил, попросил, принял;
человек остаётся в цикле на каждом шаге, что хорошо для контроля и плохо для длинных автономных заходов;
индекс проекта ускоряет ответы на вопросы «где это лежит»;
инструмент неотделим от редактора: уход из него означает потерю инструмента вместе с привычками и горячими клавишами.

Класс 3. Дополнение к IDE

Примеры: GitHub Copilot, Continue, Cline, JetBrains AI Assistant.

Плагин к чужому редактору — VS Code, JetBrains, Vim. Работает внутри API расширений хозяина: что редактор даёт плагину, то плагин и умеет — буфер, выделение, иногда терминал и файловые операции.

Следствия механики:

привычный редактор и корпоративный стандарт остаются на месте, переучиваться не нужно;
глубина возможностей задана хозяином, и один и тот же плагин в разных IDE ведёт себя по-разному;
автономность обычно ниже: петля «поправил — проверил» часто замыкается человеком.

Сравнение по осям

Ось	Терминальный агент	Редактор с моделью	Дополнение в IDE
Где работает	оболочка, сервер, CI	окно своего редактора	окно чужого редактора
Кто запускает команды	сам инструмент	человек либо встроенный агент с подтверждением	чаще человек
Как видит проект	файлы, git, вывод команд	индекс проекта	буфер и выделение, индекс по возможностям хозяина
Работа без человека	да, в headless-режиме	ограниченно	редко
Автодополнение при наборе	нет	да	да
Смена редактора	не требуется	требуется	не требуется
Что уходит наружу	содержимое читаемых файлов и вывод команд	содержимое плюс индекс проекта	содержимое буфера и собранного контекста

Строку про данные проверяют по политике конкретного продукта: где хранится индекс, сколько живут запросы, попадает ли код в обучение. Под NDA это первый вопрос, а не последний.

Классы не исключают друг друга

Автодополнение из дополнения к IDE и терминальный агент для многофайловых заходов спокойно работают в одном репозитории. Конфликт возникает не между инструментами, а в рабочем дереве: два агента, правящих одни файлы одновременно, дают дифф, который потом никто не разберёт. Разводят по веткам или по времени.

Как подключить

Проверочный заход по всем трём классам укладывается в один вечер.

Взять эталонную задачу из своего репозитория. Не «напиши функцию», а «найди причину падения теста X и почини», где критерий готовности — зелёный прогон. Задача должна требовать чтения чужого кода.
Терминальный класс: поставить CLI так, как указано у конкретного инструмента (обычно npm i -g <пакет> либо установщик), запустить из корня репозитория, дать доступ на чтение и запуск тестов, прогнать задачу.
Редактор: открыть тот же репозиторий, дождаться индексации, прогнать ту же задачу в режиме агента.
Дополнение: поставить плагин в свою IDE, выдать доступ, прогнать ту же задачу.
Ключи и аккаунты — в менеджере секретов, в процесс через переменные окружения. Не файлом в репозитории и не в настройках, которые коммитятся.
Права выставить одинаково жёстко везде: отдельная ветка, пуш запрещён, тесты разрешены, деплой запрещён.
По каждому заходу записать три числа: сколько раз пришлось вмешаться, сколько лишних файлов оказалось в диффе, сколько заходов до зелёного.

Полезные сценарии

Массовая правка по сотням файлов — переименование, миграция API, обновление шаблонов: терминальный агент.
Точечная правка внутри функции с автодополнением и мгновенным diff: редактор с моделью.
Ночной прогон, ревью MR, отчёт по расписанию: терминальный агент в headless-режиме.
Корпоративный стандарт IDE, который менять нельзя: дополнение.
Работа по SSH на сервере без графики: только терминальный класс.
Незнакомый репозиторий, нужен обзор перед правкой: редактор с индексом либо терминальный агент с read-only разведчиком.
Ученик или новый сотрудник, которому нужно видеть каждый шаг: редактор либо дополнение, где правка проходит через глаза человека.

Ограничения

Терминальный агент. Нет визуального разбора диффа по кусочкам — принимать или откатывать приходится через git. Дороже по токенам: файлы читаются целиком, накопленный контекст переотправляется на каждом шаге. Легко выдать лишние права и получить действие, которого не ждали. Требует навыка постановки задачи: расплывчатая формулировка отрабатывается буквально и до конца.

Редактор с моделью. Привязка к конкретному редактору со всеми его привычками. Индекс проекта уезжает на сторону сервиса, что упирается в NDA и внутренние политики. Длинные автономные цепочки идут хуже, чем у терминального класса, потому что человек нужен на каждом применении правки.

Дополнение к IDE. Потолок задан API редактора: чего хозяин не даёт, то не появится. Часто нет запуска команд и чтения их вывода, и петля проверки замыкается человеком. Поведение различается между IDE, поэтому опыт коллеги на другой среде переносится не полностью.

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

Как проверить результат

Прогнать один и тот же эталонный тикет во всех трёх классах и сравнить по трём меркам: число вмешательств человека, объём лишнего в диффе (git diff --stat), число заходов до зелёных тестов.
Проверить автономность прямо: дать задачу, где нужно запустить тест и прочитать вывод. Инструмент, который просит скопировать вывод руками, к терминальному классу не относится, чем бы он себя ни называл.
Проверить поведение на незнакомом стеке или на модуле, который в популярных обучающих примерах не встречается. Разрыв между демо и своим репозиторием виден именно там.
Проверить границы прав: попросить сделать запрещённое — пуш в защищённую ветку, правку файла окружения. Отказ на уровне механизма надёжнее отказа на уровне вежливости.
Прочитать политику данных: что уходит наружу, где хранится индекс, попадает ли код в обучение. Ответ должен быть в документации продукта, а не в пересказе.
Через неделю посмотреть git log и честно посчитать, сколько коммитов реально сделано с инструментом. Ощущение ускорения и число закрытых задач расходятся чаще, чем хочется.

Правило одной строкой: инструмент выбирают по тому, кто в связке запускает команды и читает их вывод.