ИИ-агенты для программирования: что они действительно ускоряют в коде

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

ИИ-агенты для программирования снимают механическую часть работы — ту, где решение известно, а времени уходит много. Разобраться, где в чужом репозитории обрабатывается конкретное поле; написать тесты на код, который писали без тестов; протащить переименование через восемьдесят файлов; поднять версию библиотеки и починить сломавшиеся вызовы; прочитать трёхсотстрочный стектрейс и найти в нём свою строку. Эти задачи не требуют изобретения, требуют усидчивости и полного обхода кода. Ускорение здесь измеримое, в отличие от разговоров про «замену разработчика».

Как устроено

Три разных формата, которые часто называют одним словом.

Дополнение в редакторе. Модель видит открытый файл и соседние, предлагает продолжение строки или функции. Решение принимает человек на каждом шаге.

Агент в редакторе или терминале. Есть доступ к файловой системе, поиск по репозиторию, запуск команд, git. Работает циклом: прочитать → изменить → собрать → прогнать тесты → прочитать ошибку → изменить. Останавливается по достижении цели или лимита шагов.

Фоновый агент. Запускается по событию — упавший пайплайн, новый тикет, комментарий в задаче — и приносит готовую ветку с изменениями на ревью.

Внутри у агента четыре опоры.

Контекст. Дерево каталогов, поиск по тексту, чтение конкретных файлов. Весь репозиторий в модель не помещается, поэтому агент видит фрагменты и достраивает остальное по догадке. Всё, что делает нужный фрагмент дешёвым для нахождения — говорящие имена, типы, тесты, README рядом с модулем, — напрямую поднимает качество правок.

Инструменты. Чтение и запись файлов, запуск команд, git, тесты, линтер. Набор инструментов и определяет потолок: агент без права запускать тесты работает вслепую.

Правила проекта. Файл в корне репозитория с инструкциями: как поднять окружение, чем запускать тесты и линт, какого стиля держаться, что трогать нельзя. Такой файл читается агентом в начале работы и заменяет повторение одних и тех же указаний в каждом запросе.

Изоляция. Отдельная ветка или отдельная рабочая копия, чтобы правки не смешивались с чужими, и чтобы откат стоил одну команду.

Выход всегда один — набор изменений, который читает человек. Ревью diff остаётся частью цикла независимо от того, насколько хорош агент.

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

Начать с чистого дерева и отдельной ветки. Правки агента поверх незакоммиченных чужих изменений разбирать невозможно:

git status --short          # должно быть пусто
git switch -c fix-import-dates

Положить в корень файл правил проекта. Минимум, который окупается сразу: команда установки зависимостей, команда тестов, команда линта, стиль именования, список запретов — файлы окружения, каталог зависимостей, миграции, сгенерированный код.
Сделать команды воспроизводимыми. Одна цель на действие, без длинных строк из памяти:

make test
make lint
npm run typecheck

Дать агенту право запускать тесты и линтер локально. Доступ к боевым системам, ключам и базе прода не давать: цикл правка-проверка должен замыкаться на локальном окружении.
Первая задача — маленькая и проверяемая. Починить одну функцию, добавить тест, привести к общему виду один модуль. Задача «отрефактори проект» даёт большой diff, который никто не проверит.
Читать изменения целиком перед принятием:

git diff --stat            # объём: сколько файлов и строк
git diff                   # содержимое

Оформлять черновиком через запрос на слияние, чтобы работал обычный конвейер сборки. Автоматическая проверка ловит то, что глаз пропускает.

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

Ориентирование в незнакомом коде: где обрабатывается конкретное поле, кто вызывает функцию, какой путь у запроса от точки входа до базы.
Тесты на существующий код: агент читает реализацию и покрывает граничные случаи, включая те, что человек ленится расписывать.
Механический рефакторинг: переименование, вынесение повторов, приведение одинаковых мест к общему виду по всему репозиторию.
Миграция версии: поднять зависимость и починить сломавшиеся вызовы по списку ошибок сборки.
Разбор упавшего пайплайна: прочитать лог, найти первую настоящую ошибку среди последствий, предложить правку.
Обвязка вокруг задачи: скрипты выгрузки, разбор формата, фикстуры, наполнение тестовыми данными.
Первый проход ревью: пройтись по diff и выписать очевидное — необработанные ошибки, потерянные проверки, забытые индексы.

Ограничения

Агент видит фрагмент репозитория и уверенно достраивает остальное. Отсюда вызовы несуществующих методов и параметры, которых в сигнатуре нет. Все обращения к внутренним библиотекам проверяются по исходникам, а не по правдоподобности.

Слияние конфликтов — опасное место. Разрешение вида «переписать файл целиком по своей версии» тихо теряет чужой код, и синтаксическая проверка этого не покажет. Конфликты разбираются по кускам, с чтением обеих сторон.

Зелёные тесты не равны правильности, если тесты писал тот же агент по той же неверной догадке о поведении. Ценность теста определяется тем, поймает ли он реальную поломку, а не тем, что он проходит.

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

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

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

Секреты и файлы окружения агенту не показывают. Значения ключей попадают в контекст модели, в логи и в историю запусков — доступ к таким файлам закрывается на уровне правил проекта.

Правило: агенту отдают то, что проверяется командой; всё, что проверяется только мнением, остаётся человеку.

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

Посмотреть на объём правки до содержимого. Задача на одну функцию, давшая изменения в двадцати файлах, разбирается заново:

git diff --stat
git diff --numstat | sort -k2 -nr | head   # где больше всего удалений

Большие блоки удалений проверять отдельно — там чаще всего теряется код, который агент счёл лишним.

Прогнать тесты и статические проверки на чистой копии, а не только в том окружении, где агент работал:

git clone --branch fix-import-dates . /tmp/check && cd /tmp/check
make install && make test && make lint

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

Отдельно прочитать все места, где агент трогал обработку ошибок, права доступа и запросы к базе. Эти три категории дают самые дорогие незаметные регрессии.

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

Если доля откатов держится высокой на конкретном типе задач, этот тип возвращают человеку и оставляют агенту соседние — чтение кода, тесты, обвязку.