AI-программирование в терминале: когда этот инструмент действительно работает

Aider не пишет за вас приложение, не генерирует пулл-реквесты с пометкой «сделано на ИИ» и не подсвечивает ошибки в редакторе, как привычные AI-помощники. Вместо этого он сидит в терминале, правит код прямо в вашем Git-репозитории и оставляет после себя коммиты с чёткими сообщениями. Это не гламурный инструмент — это хирургический скальпель для инженеров, которые привыкли работать с кодом через git diff, stash и cherry-pick.

Революция здесь не в красоте интерфейса, а в том, что Aider не ломает ваш workflow. Он его усиливает — но только если вы уже используете Git как основной интерфейс. У большинства терминальных пользователей это так и есть. У остальных начинаются проблемы.

Каждый коммит, который делает Aider, — это не просто снимок состояния, а законченный шаг. Он не просто исправляет баг, а фиксирует его с сообщением вроде «Add null-check for user_id in query to prevent SQL injection». Такой подход решает сразу две задачи: во-первых, у вас остаётся история изменений, понятная любому другому разработчику; во-вторых, сам ИИ вынужден мыслить в терминах коммитов, а не в абстрактных «исправлениях». Это не мелочь — это сдвиг парадигмы.

Но Aider не стремится объять необъятное. Он не будет генерировать с нуля целый микросервис, если не получит на вход конкретный файл или diff. Вместо этого он маппит репозиторий, собирает контекст и предлагает изменения, которые можно сразу закоммитить. Если нужно провести рефакторинг в нескольких файлах — например, вынести общий код в утилиту или мигрировать с одного фреймворка на другой — Aider справляется быстрее, чем человек. Он не устаёт, не отвлекается и не забывает импорты.

Цена такой точности — дисциплина. Если в вашей команде не принято делать небольшие, атомарные коммиты, Aider начнёт путаться в несохранённых изменениях или создавать коммиты с мусорными сообщениями. Он не заменит код-ревью. Он ускорит его — но только если вы научите его правильно.

Терминал — это не для всех. Команда, в которой половина людей не знает, как работает rebase -i, быстро превратит Aider в источник хаоса. Попробуйте объяснить дизайнеру, почему сегодняшние изменения выглядят так, а не иначе, когда коммит подписан ИИ и в сообщении — «fix typo in button label». Даже если изменения верные, процесс теряет прозрачность.

Это не техническая проблема, а организационная. Aider не придумали для смешанных команд. Он для инженеров, которые готовы заводить feature-ветку, делать мелкие коммиты, запускать линтеры и тесты перед пушем. Если ваш workflow уже такой — инструмент впишется без скрипов. Если нет — он либо потребует адаптации, либо заставит вас вернуться к старым привычкам.

Стоимость использования Aider складывается из двух частей: токенов и железа.

Если вы работаете с удалёнными моделями — скажем, Claude 3.7 Sonnet или GPT-4o — каждая сессия обходится в несколько центов. Нет плоской подписки, как у [заблокированного в России продукта]. Нет ограничений на количество запросов. Зато есть счёт за токены, который нужно отслеживать, особенно если репозиторий большой. Aider поддерживает кэширование промптов и позволяет переключаться на более дешёвые модели, но это уже ручная оптимизация.

Если вы ставите локальную модель через Ollama, то платите железом. Для больших репозиториев потребуется как минимум 32 ГБ RAM и хороший GPU. Модели вроде DeepSeek R1 или Qwen2.5-Coder-32B тянут нешуточные ресурсы. Зато токенов не нужно считать — только электричество и амортизацию железа.

Ирония в том, что Aider бесплатен как софт, но дорог как процесс. Бесплатность не отменяет необходимости платить за железо, за внимание к деталям и за дисциплину в команде.

Как Aider выглядит на практике?

Разработчик Fix Price делает пулл-реквест, добавляет изменения и запускает скрипт:

git diff --staged > staged.diff

Затем он передаёт этот diff Aider вместе с историей предыдущих комментариев:

aider staged.diff .aider.chat.history.md "${STAGED_FILES[@]}" --message="$(cat $AIDER_READ)"

ИИ анализирует изменения, ищет стилистические ошибки, отсутствующие проверки и несоответствия, а затем оставляет замечания в чате.

Теоретически это должно ускорить ревью с 30 до 10 минут. На практике разработчик всё равно тратит ещё пять минут на то, чтобы адаптировать вывод ИИ под формат пулл-реквеста. Aider не пишет сообщение для PR — он генерирует технические замечания. Их ещё нужно переработать в человеческий язык. Зато он не пропускает очевидные баги, которые могли бы ускользнуть от усталых глаз.

Так что Aider — это не серебряная пуля, а инструмент для тех, кто готов за ним следить.

Его стоит использовать, если:

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

Его не стоит использовать, если:

• ваша команда не использует Git как основной интерфейс;
• вам нужны строгие аудиторские следы, выходящие за рамки Git-коммитов;
• вы ищете инструмент «всё-в-одном» — Aider не заменит CI, код-ревью или документацию.

Иными словами: Aider не сделает ваш код лучше. Он сделает ваш процесс редактирования быстрее — если вы уже следуете дисциплине, которую он усиливает. В противном случае он просто добавит ещё один слой сложности.