Aider (в поиске его ищут как Aider AI) — это консольный инструмент, где вы добавляете в чат нужные файлы репозитория, выбираете модель и формулируете задачу, а правки записываются прямо в файлы и фиксируются отдельными коммитами Git. Инструмент самостоятельный, со своим циклом работы вокруг Git, и от Claude Code он отделён целиком. Схема работает там, где у задачи есть проверка запуском тестов и кто-то готов читать каждый коммит.
Файлы в чате
Запуск выглядит как aider файл1 файл2, дополнительные файлы добавляет команда /add, а лишние убирает /drop: чем короче список, тем точнее правка.
Установка по документации: python -m pip install aider-install, затем aider-install. Установщик создаёт отдельное окружение Python и ставит нужную версию, если её нет. Ключ поставщика передают флагом вида --api-key имя=ключ или через переменную окружения, а модель выбирают флагом --model. Какие поставщики и модели подключаются, описано в разделе документации о подключении моделей; доступ и условия оплаты у выбранного вендора выясняйте до начала пилота.
Документация советует добавлять только файлы, которые предстоит менять, а связанный код Aider подтягивает сам через карту репозитория. Для чтения без правок есть /read-only: так в контекст попадают соглашения проекта и интерфейсы соседних модулей, а правки в них остаются закрытыми. Условный пример для статьи: в модуле скидок интернет-магазина нужно запретить суммирование двух промокодов. В чат идут файл расчёта и файл с тестами, а описание формата заказа подключается только для чтения.
Карта репозитория — сжатое описание структуры кода: файлы, классы, функции. Aider вкладывает её в запрос рядом с добавленными файлами, и модель видит, где лежат связанные места. Для самой правки нужные файлы добавляются в чат, поэтому перед работой посмотрите список командой /ls и уберите лишнее через /drop.
Смежный инструмент с похожей идеей изложен в обзоре harness-инструментов для фаундера, где Aider назван в одном ряду с другими консольными помощниками. Здесь нужен другой взгляд: как довести правку до принятого коммита.
Сначала обсуждение
У Aider несколько режимов чата: code вносит изменения, ask отвечает на вопросы без правок, architect разделяет работу между двумя моделями, help объясняет сам инструмент. Одноразово режим вызывают командами /code, /ask, /architect, а постоянно переключают через /chat-mode или флаг --chat-mode при запуске.
Документация рекомендует чередование: сначала обсудите стратегию в режиме ask, затем перейдите в code. Для задачи с промокодами начните с вопроса, где в расчёте применяется скидка и что произойдёт при втором коде. Ответ показывает, понял ли инструмент структуру модуля, ещё до первой правки. Если описание расходится с реальным кодом, поправьте состав файлов в чате и повторите вопрос.
Режим architect разделяет модель-архитектора, которая предлагает решение, и модель-редактора, которая превращает его в правки файлов; редактор задаётся флагом --editor-model. Для пилота хватает режима code: два набора моделей удваивают поверхность для проверки, и причина ошибки труднее находится.
Читайте ответ в режиме ask как черновик плана. Отметьте, какие файлы названы, какие вызовы упомянуты и появились ли в ответе элементы, которых в коде нет. Ответ с выдуманными именами функций означает, что контекст собран неверно: исправляйте состав файлов, а переход к правкам отложите.
Коммиты Aider
Aider по умолчанию сам фиксирует свои изменения в Git с описательным сообщением в духе Conventional Commits. Есть важная деталь: перед правкой инструмент коммитит и ваши незафиксированные изменения в этих файлах, чтобы они остались отдельно от работы агента. Поэтому начинайте с чистого дерева и отдельной ветки.
| Команда или флаг | Действие | Когда применять |
|---|---|---|
| /diff | Показывает изменения после последнего сообщения | После каждого ответа, до принятия |
| /undo | Отменяет предыдущую правку Aider | Правка вышла за рамки задачи |
| --no-auto-commits | Отключает автоматические коммиты | Нужно собрать изменения в один коммит самому |
| --no-dirty-commits | Отключает коммит ваших изменений перед правкой | В рабочем дереве есть незавершённая работа |
| --attribute-co-authored-by | Добавляет в сообщение строку Co-authored-by | Команде важно видеть, где участвовал инструмент |
Автокоммиты облегчают откат, но загрязняют историю мелкими записями. Перед слиянием историю ветки можно сжать обычными средствами Git, и это решение владельца ветки. Флаг --git-commit-verify включает хуки pre-commit, по умолчанию они выключены, так что при желании пропускать правки через проверку проекта включайте его осознанно.
Тест-команда
- Создайте ветку и убедитесь, что дерево чисто. Запустите Aider с двумя файлами: расчёт скидки и тест.
- Задайте команду проверки:
--test-cmdс командой запуска тестов проекта и флаг--auto-test, чтобы тесты шли после каждой правки. - Опишите задачу утвердительно: «разрешён один промокод на заказ; второй игнорируется, покупателю показывается сообщение». Попросите сначала добавить тесты на оба случая.
- После ответа выполните
/diff, прочитайте изменения и отдельно запустите тесты в другом окне терминала. - Если правка вышла за рамки, откатите её командой
/undo, уточните формулировку и повторите.
По документации, при ненулевом коде завершения тест-команды Aider пытается исправить ошибки. Это ускоряет цикл, но создаёт соблазн: модель способна подогнать тест под свой результат. Поэтому ожидаемые значения в тестах задавайте сами и сверяйте diff тестов отдельно от diff кода.
Проверка стиля подключается флагом --lint-cmd; встроенные линтеры для популярных языков работают сами, отключить автоматическую проверку можно через --no-auto-lint. Для разовых запусков команд с передачей вывода агенту есть /run, он пригодится, когда нужно показать трассу падения. Зафиксируйте для команды, какая именно проверка служит входом в приёмку: без неё каждый разработчик решает вопрос по-своему, и качество правок зависит от случая. Список таких проверок короток: тесты, линтер и сборка проекта.
Какая команда проверки подходит вашему репозиторию как входной фильтр?
Приёмка и откат
Приёмка идёт по трём вопросам. Проходят ли тесты при ручном запуске? Соответствует ли diff задаче: тронуты расчёт и тесты, формат заказа остался прежним? Понятен ли коммит человеку, который будет читать историю через год? При отрицательном ответе на любой пункт ветка возвращается на доработку, а слияние откладывается.
Откат устроен двумя уровнями. Свежую правку отменяет /undo, пока она последняя. Если коммитов уже несколько, работайте обычными командами Git: /git позволяет вызывать их прямо из чата, а ветку всегда можно удалить целиком. Работа при этом сохраняется, ведь история хранится в репозитории.
При расширении схемы действует простое ограничение: одна задача на одну ветку и один запрос на слияние. Тогда журнал коммитов Aider читается как история одной правки, откат касается только её, а ревьюер видит границы изменения целиком. Смешанные ветки с несколькими задачами сразу лишают смысла и откат, и приёмку.
Прежде чем расширять применение, запишите правила для команды: какие каталоги закрыты для агента, какая тест-команда считается обязательной, кто читает коммиты. Аналогичная дисциплина описана для терминальных агентов в статьях про Kimi Code и OpenCode CLI.
Возьмите мелкую задачу с готовым тестом в отдельной ветке и включите --auto-test. После ответа прочитайте /diff и проверьте историю коммитов. Нужен регламент для всей команды разработки? Расскажите о задаче: схему допуска и приёмки соберём под ваш репозиторий.