Aider или OpenCode: как выбрать CLI для своего Git-проекта

Если вы хотите явно выбирать файлы для правки и видеть небольшие изменения в Git, начните проверку с Aider. Если вам удобнее переключаться между планированием и выполнением, управлять инструментами и отдельными агентами, начните с OpenCode. Это выбор способа работы; качество ответа также зависит от модели, контекста и самой задачи.

Не переносите сравнение на основной репозиторий с незавершёнными изменениями. Возьмите небольшой тестовый проект или две чистые рабочие копии одной ревизии. Секреты, рабочие ключи и лишние данные не должны попадать в тестовый контекст.

Какие различия проверить до первой правки

Ваше требование	Aider	OpenCode
Явно задать файлы для редактирования и справки	/add, /read-only, /drop, список через /ls	Файлы и инструменты доступны в сессии; проверяйте контекст и разрешения выбранного агента
Обсудить решение до изменения кода	Режим /ask, затем переход к /code	Переключение между Plan и Build
Контролировать Git-коммиты	Есть автоматические коммиты; поведение настраивается	Отдельно определите, какие Git-команды разрешено запускать
Ограничить выполнение инструментов	Начните с режима обсуждения и контроля добавленных файлов	Правила allow, ask, deny для инструментов и команд

В Aider команды задают файлы в чате и способ работы с ними; полный список есть в справочнике команд. В OpenCode основной агент может привлекать subagents, поэтому при проверке границ смотрите не только название текущего режима, но и фактически вызванные инструменты.

В Aider сначала разберитесь с коммитами

По умолчанию Aider фиксирует свои правки в Git. Перед редактированием dirty-файлов он также может закоммитить уже существующие изменения. Если вы ожидаете, что история останется полностью под вашим контролем, настройте это до первой правки.

Для теста с ручными коммитами запустите уже установленный и настроенный клиент так:

aider --no-auto-commits --no-dirty-commits

Эти параметры не запрещают редактирование файлов и не заменяют резервную копию. Они отключают два описанных автоматических действия с коммитами. Поведение, /diff и условия /undo описаны в Git integration.

В сессии добавьте только файл задачи, а справочный файл — в read-only. Проверьте /ls, перейдите в /ask и попросите объяснить предполагаемую правку. После согласования используйте /code с узкой задачей. Разница режимов описана в Chat modes.

В OpenCode проверьте права выбранного агента

У OpenCode есть основные агенты Build и Plan. В текущей документации Plan запрашивает разрешение на правки файлов и Bash-команды, а Build предназначен для выполнения работы. Название Plan не означает отдельную файловую песочницу. Сверьте поведение со своими настройками в руководстве Agents.

Если для первого опыта нужен явный запрет на изменение файлов и запуск команд, в новом тестовом проекте можно задать:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "deny",
    "bash": "deny"
  }
}

Сохраните это в opencode.json. В существующем проекте объедините секцию с настройками, не заменяя весь файл. Правила конкретного агента могут переопределять глобальные; проверьте их до опыта. Конфигурация ограничивает указанные инструменты, но не является обещанием полной изоляции всех внешних действий.

Попросите объяснить тот же файл без изменений. До этапа правки отдельно измените необходимые разрешения и проверьте, какие команды будут доступны. Не выдавайте общее разрешение на все инструменты только ради прохождения теста. Синтаксис и приоритет правил приведены в Permissions.

Сравните на одной небольшой задаче

Выберите изменение, которое можете проверить без доверия к объяснению модели. Например, в тестовом проекте есть функция, переводящая название в URL-фрагмент. Задайте оба примера: строка " Release Notes " должна стать "release-notes", а пустая строка — вызвать ValueError. Ограничьте изменение одним файлом функции и одним тестовым файлом.

Перед запуском для каждого инструмента запишите:

• одну исходную Git-ревизию и одинаковый текст задания;
• выбранную модель и источник доступа;
• файлы, доступные для правки, и разрешённую команду проверки;
• ожидаете ли вы автоматические коммиты.

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

git status --short
git diff --check
git diff --stat
git log -3 --oneline

При наличии автоматического коммита обычный git diff может быть пустым. Сравните текущий HEAD с записанной исходной ревизией, чтобы увидеть всю правку. Проверьте и untracked-файлы: они не входят в обычный diff.

Если клиенту пришлось дать больше файлов или разрешений, запишите конкретную причину. Это полезнее общего впечатления «он справился быстрее». Один успешный запуск не доказывает преимущество инструмента на других языках, моделях или репозиториях.

Как принять решение после опыта

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

Подключение API проверяйте отдельно от качества правки: успешная авторизация не означает правильный код. Для установки OpenCode уже есть отдельная инструкция; здесь критерий выбора — контролируемый результат в вашем Git-проекте.