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

Что такое ИИ-агент для программирования

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

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

Цикл работы агента

1. 01Понять задачу: прочитать формулировку и инструкции проекта.
2. 02Собрать контекст: найти нужные файлы, изучить похожий код, посмотреть тесты.
3. 03Спланировать изменения: явно или «в уме», в зависимости от инструмента и настроек.
4. 04Внести правки в один или несколько файлов.
5. 05Проверить себя: запустить сборку, тесты, линтер, проверку типов.
6. 06Исправить найденные ошибки и повторить проверку.
7. 07Отчитаться: описать, что сделано, и вернуть управление человеку.

Из этого следует главное отличие для разработчика: вы перестаёте писать каждую строку и начинаете управлять процессом. Ваша работа смещается к постановке задачи, контролю действий агента и ревью итогового диффа. Если пропустить ревью, агент будет уверенно приносить код, который компилируется, но делает не совсем то или делает это не так, как принято в проекте.

Какие бывают агенты и когда какой выбирать

Названия и возможности конкретных продуктов меняются быстро, поэтому полезнее думать о классах инструментов. Многие продукты совмещают несколько режимов, но исходная модель работы у каждого своя, и именно она определяет, где инструмент удобен.

• Агенты внутри редактора кода. Работают рядом с открытыми файлами, изменения видны прямо в интерфейсе, их удобно принимать и отклонять по частям. Подходят для повседневной разработки, когда вы рядом и следите за процессом.
• Агенты в терминале. Запускаются в папке проекта и сами выполняют команды. Хорошо подходят для многошаговых задач, работы со скриптами, инфраструктурой, миграциями, для работы на удалённом сервере и в связке с другими консольными инструментами.
• Облачные (фоновые) агенты. Получают задачу, работают в изолированной среде с копией репозитория и возвращают результат в виде ветки или запроса на слияние. Подходят для задач, которые можно отдать «на сторону» и проверить потом, и для параллельной работы над несколькими задачами.
• Агенты в процессе ревью. Читают пул-реквест и оставляют замечания. Это дополнительный рецензент, который ловит часть ошибок, но не заменяет человека, отвечающего за код.

Простое правило выбора

• Если вы хотите видеть каждое изменение по ходу работы и вмешиваться — выбирайте агента в редакторе, потому что там короче путь от правки до вашего решения.
• Если задача требует много команд, работы с окружением или сервером — выбирайте терминального агента, потому что у него естественный доступ к тем же инструментам, что и у вас в консоли.
• Если задачи однотипные и хорошо проверяются автоматически — обновление зависимостей, исправление предупреждений, мелкие баги по тесту — отдавайте их фоновому агенту, потому что вам нужен только итоговый дифф и зелёный CI.
• Если в команде мало рецензентов — добавьте агента в ревью как первый фильтр, но не снижайте требований к человеческому ревью.

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

Как выбрать агента под свой проект

Демонстрации на чистом учебном проекте почти ничего не говорят о том, как инструмент поведёт себя в вашем коде: с вашей историей, нестандартной сборкой, старыми модулями и неписаными соглашениями. Оценивать стоит по практическим критериям, которые важны именно вам.

• Где проходит ваша работа. Инструмент должен встраиваться в привычную среду команды, а не требовать менять её ради себя.
• Контроль над действиями. Можно ли настроить, какие команды агент выполняет сам, а какие только после подтверждения; видно ли, что именно он сделал и в каком порядке.
• Инструкции проекта. Умеет ли агент читать постоянный файл с правилами репозитория: как собирать, как тестировать, какие соглашения приняты, что запрещено.
• Работа с большим кодом. Насколько хорошо он находит нужные места в крупном репозитории, а не только в паре открытых файлов; как ведёт себя на монорепозитории.
• Расширяемость. Можно ли подключить ему ваши инструменты: внутреннюю документацию, трекер задач, базу данных для чтения, собственные скрипты.
• Политика данных. Куда уходит код, хранится ли он у поставщика, используется ли для обучения, допустимо ли это для ваших клиентов и договоров.
• Предсказуемость расходов. Как считается оплата, можно ли ограничить траты на человека и на команду, видно ли, на что ушли средства.
• Интеграция с git и CI. Работает ли агент через ветки и пул-реквесты, чтобы его изменения проходили тот же контроль, что и код людей.

Модель и оболочка — разные вещи

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

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

Как провести честное сравнение за пару дней

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

1. 01Выберите несколько задач из реального бэклога разного типа: исправление бага с понятным воспроизведением, небольшую функцию по образцу существующей, рефакторинг одного модуля.
2. 02Для каждой задачи напишите одну и ту же постановку: цель, место в коде, ограничения, критерии готовности.
3. 03Заранее определите, что считается успехом: тесты проходят, дифф затрагивает только нужные файлы, решение соответствует стилю проекта, вам не пришлось переписывать логику.
4. 04Запустите каждый инструмент в отдельной ветке от одного и того же коммита.
5. 05Не помогайте одному инструменту больше, чем другому: одинаковое число уточнений, одинаковые подсказки.
6. 06Оцените результат как ревьюер: прочитайте дифф целиком, запустите проверки сами, запишите замечания.
7. 07Отдельно отметьте процесс: насколько понятно было, что делает агент, сколько раз пришлось подтверждать действия, были ли попытки сделать что-то лишнее.

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

Подготовка репозитория к работе с агентом

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

Файл с правилами проекта

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

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

Быстрые и надёжные проверки

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

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

Рабочий цикл: от задачи до слияния

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

1. 01Создайте ветку под задачу. Одна задача — одна ветка, чтобы неудачный результат можно было выбросить без потерь.
2. 02Поставьте задачу как короткую спецификацию: цель, контекст, ограничения, критерии готовности, команды проверки.
3. 03Для нетривиальной задачи попросите сначала план без правок. Прочитайте его и поправьте до начала работы — исправить план дешевле, чем дифф.
4. 04Разрешите выполнение. Следите за ходом работы, но не вмешивайтесь в каждый шаг: если направление верное, дайте агенту закончить.
5. 05Потребуйте отчёт: какие файлы изменены и зачем, какие проверки запущены и с каким результатом, какие решения приняты самостоятельно.
6. 06Проведите ревью диффа целиком, как ревью кода коллеги. Запустите проверки сами, если отчёт вызывает сомнения.
7. 07Если результат не устраивает — решите, что дешевле: уточнить задачу и продолжить или откатить ветку и начать заново с лучшей постановкой.
8. 08Откройте пул-реквест, пройдите обычный процесс ревью и CI. Код агента не получает исключений.

Условный пример

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

Разрешения, среда и безопасность

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

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

Где агенты ошибаются и как это поймать

Ошибки агентов повторяются, и это хорошая новость: если знать типовые сценарии, их можно ловить целенаправленно, а не надеяться на внимательность.

Меняет больше, чем просили

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

Подгоняет тест под код

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

Использует несуществующие или устаревшие API

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

Теряет контекст в длинной сессии

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

Уверенно сообщает об успехе

Отчёт агента — это утверждение, а не доказательство. Он может написать, что всё протестировано, хотя тесты не запускались или упали. Ловится требованием показать вывод команд проверки и собственным прогоном в CI.

Агент в команде: правила и ответственность

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

• Ответственность за код всегда на человеке, который открыл пул-реквест, независимо от того, кто написал строки.
• Пул-реквест от агента должен быть того же размера, что и обычный: если он больше, его режут на части.
• Файл правил проекта общий и живёт в репозитории; его правят через обычное ревью, как код.
• В описании пул-реквеста указывают, какие части написаны с помощью агента и как они проверены, — это помогает рецензенту.
• Начинающим разработчикам агент полезен, но их ревью должно быть особенно внимательным: важно, чтобы они понимали код, который отправляют.

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

Чек-лист: первые две недели с агентом

1. 01Выберите два-три инструмента разных классов для сравнения.
2. 02Отберите несколько реальных задач разного типа из бэклога.
3. 03Запишите критерии успеха до начала сравнения.
4. 04Создайте файл с правилами проекта: команды, структура, соглашения, запреты.
5. 05Сделайте одну команду, которая проверяет изменение целиком.
6. 06Настройте разрешения: что агент делает сам, что — только с подтверждением.
7. 07Уберите из доступа агента секреты и боевые ключи.
8. 08Работайте только через ветки и пул-реквесты.
9. 09Для нетривиальных задач требуйте план до правок.
10. 10Требуйте в отчёте вывод команд проверки, а не только слова «готово».
11. 11Просматривайте изменения в тестах отдельно от изменений в коде.
12. 12После каждой задачи записывайте, где агент ошибся, и дополняйте файл правил.
13. 13Договоритесь в команде о размере пул-реквестов и об ответственности за код.

Короткий словарь терминов

• Агент — языковая модель с инструментами, которая сама выполняет действия для решения задачи.
• Контекст — всё, что модель видит в данный момент: задача, инструкции, прочитанные файлы, результаты команд.
• Файл правил проекта — постоянные инструкции для агента, которые лежат в репозитории и читаются в начале сессии.
• Дифф — набор изменений между двумя версиями кода; главный предмет ревью.
• Режим подтверждения — настройка, при которой агент спрашивает разрешения перед определёнными действиями.
• Фоновый агент — агент, который работает без вашего постоянного участия в отдельной среде и возвращает готовые изменения.

Вывод

ИИ-агент — это не замена разработчику, а исполнитель, которым нужно управлять. Выбирайте его по своему процессу и проверяйте на своём коде, а пользу ему обеспечат подготовленный репозиторий, маленькие задачи, автоматические проверки, разумные разрешения и честное ревью.

Навыки, которые делают работу с агентом эффективной, — постановка задачи, чтение чужого кода, понимание архитектуры и строгость в проверке — это те же навыки, что отличают сильного разработчика. Агент просто делает их ещё ценнее.