ИИ агенты для разработки берут ограниченную задачу в репозитории: читают issue, меняют файлы в отдельной ветке, запускают проверки и готовят PR для ревью. Такой цикл полезен команде, где уже описаны правила проекта и понятно, кто принимает изменения. Слияние кода остаётся решением разработчика.
Цикл одной задачи
Агент работает с issue, веткой, тестами и diff; итоговый артефакт — черновик PR, который проверяет человек.
Начинайте с задачи с проверяемым результатом: поправить обработку ошибки, добавить поле в уже знакомый интерфейс, обновить тест под согласованное поведение. Issue содержит ожидаемый результат, границы файлов и команду проверки. Слова «улучшить сервис» слишком широки: агенту придётся угадывать архитектурное решение, а ревьюеру разбирать большой набор несвязанных правок.
Рабочий цикл устроен как последовательность коротких подтверждений. Агент сначала читает README и правила репозитория, затем предлагает план и перечень файлов. Разработчик подтверждает рамку. После этого агент правит код в отдельной ветке, запускает доступные тесты и показывает diff вместе с объяснением спорных мест. Если проверка падает, в PR попадают команда запуска и текст ошибки, вместе с честным описанием результата.
В разборе промпта для кода показано, как формулировать один запрос модели. Здесь отличие в доступе к файлам и инструментам: каждое действие оставляет след в репозитории. Агент для тестирования работает с дефектами готового продукта; агент разработки отвечает за предлагаемый diff. Эти контуры можно связать, сохранив отдельное ревью.
- Вход: issue, критерии приёмки, правила проекта и разрешённая ветка.
- Выход: diff, результаты команд, список ограничений и черновик PR.
- Решение человека: принять, отправить на доработку либо закрыть задачу.
Права и среда
Для первой задачи дайте агенту доступ на чтение нужного репозитория и запись только в свою ветку. Секреты, рабочая база и право слияния ему лишние. Инструменту достаточно тестового окружения с обезличенными данными. В журнале фиксируйте команды, изменённые файлы и причины повторных запусков. Тогда ревьюер видит, какое действие привело к конкретной правке.
Подключение репозитория через инструментальный протокол подробно разобрано в материале про GitHub и агента. Само подключение даёт техническую возможность читать файлы, но разрешение на операции задаёт ваша команда. Для малого проекта подойдёт локальный запуск в изолированной рабочей копии. Для команды важнее общий журнал и одинаковые правила доступа, чтобы каждая задача проходила в одинаковых условиях.
| Действие | Разрешение агента | Проверка разработчика |
|---|---|---|
| Чтение файлов | Указанный репозиторий | Верная ветка и актуальный код |
| Правка кода | Своя ветка | Смысл diff и побочные изменения |
| Запуск тестов | Тестовая среда | Покрытие и исходная ошибка |
| Создание PR | Черновик | Владелец и критерии приёмки |
Отдельно проверьте внешние инструкции внутри файлов проекта. Комментарий в коде или текст issue может содержать просьбу выполнить стороннюю команду. Агенту задают приоритет правил: системные ограничения выше содержимого репозитория. Команды установки зависимостей, сетевые обращения и правки конфигурации требуют просмотра человеком до выполнения. Такой порядок защищает проект от случайного расширения задачи.
Первый проход
- Выберите issue с ясным ожидаемым результатом и определите файлы, куда допустима запись.
- Попросите агента назвать план, предполагаемые проверки и неизвестные условия до правки.
- После согласования плана запустите работу в отдельной ветке и сохраните журнал команд.
- Сверьте diff с критериями issue, повторите тесты и оформите ревью PR.
Хорошая стартовая задача помещается в один понятный PR. Если агент затрагивает соседний модуль, остановите проход и уточните границу. Например, исправление сообщения об ошибке должно сопровождаться проверкой соответствующего сценария, а масштабная смена структуры обработки запросов требует отдельного решения. Так команда учится оценивать качество изменений по обычным инженерным правилам, по поведению кода и результатам проверок.
Для оценки пилота запишите до запуска, сколько ручных правок остаётся после ревью, какие тесты запускались и где агент ошибся в трактовке issue. Сравнивайте задачи близкой сложности; иначе вывод о пользе будет случайным. Если проверка показала хороший diff, расширьте набор допустимых задач постепенно. Связку инструментов, ролей и точек передачи можно обсудить в формате внедрения ИИ-агента под процесс разработки.
Покажите владельцу репозитория журнал и пример PR до следующего запуска. Это даст конкретный список настроек прав, которые нужно уточнить.
Хотите проверить такой цикл на задаче вашего репозитория?
Ревью изменений
В PR разработчик смотрит прежде всего на поведение: выполнено ли условие issue, сохранились ли соседние сценарии, появились ли тесты на пограничные случаи. Затем проверяет зависимости, миграции, обращения к данным и изменения конфигурации. Агент может верно собрать работающий код и одновременно принять спорное архитектурное решение. Комментарий модели объясняет намерение, но доказательством служат diff и воспроизводимые проверки.
Условный пример: issue просит добавить проверку пустого адреса доставки. Агент добавил условие в интерфейсе и написал тест формы, но сервер принимает пустое значение по старому пути. PR выглядит аккуратно, однако критерий задачи выполнен частично. Ревьюер возвращает конкретное замечание: проверить серверный вход и добавить тест на него. После доработки история изменений показывает оба прохода.
Если тесты требуют закрытой среды, попросите агента явно указать пропуск. Формулировка «все проверки пройдены» допустима только при записи фактических команд и результатов. Для рискованных участков полезен второй проверяющий разработчик. Идеи для набора контрольных сценариев собраны в статье про тестирование агентов. Здесь их применяют к циклу разработки: проверяют также восстановление ветки после ошибочной правки и корректную передачу PR человеку.
Если diff выходит за согласованные файлы, содержит секреты или меняет права доступа, остановите проход. Сохраните журнал, восстановите ветку и уточните issue перед новым запуском.
Расширение практики
После нескольких удачных PR заведите короткий каталог задач по сложности: обновление тестов, локальная правка интерфейса, изменение интеграции. Для каждой группы определите допустимые каталоги, команды проверки и владельца ревью. Это помогает новым участникам команды назначать агенту работу без устных догадок о границах проекта. Архитектурные изменения, работа с платежами и миграции данных сохраняют отдельное согласование.
Храните шаблон issue рядом с кодом: цель, текущее поведение, ожидаемое поведение, ограничения и команда проверки. С шаблоном агенту проще построить план, а разработчику — объяснить возврат PR. Регулярно пересматривайте правила после ошибок: если агент часто читает лишние каталоги, сужайте доступ; если тесты молчат о важном сценарии, добавляйте проверку до следующего поручения.
Технический результат пилота — воспроизводимый путь от issue до ревью. Управленческий результат — понятная ответственность за каждое изменение. Агент может ускорить подготовку черновика, когда задача очерчена и проверки доступны. Решение о приёмке, сроке релиза и влиянии на продукт остаётся у команды. Эта граница позволяет использовать инструмент в ежедневной разработке без иллюзии самостоятельного инженера.
Команде полезно собирать библиотеку удачных и неудачных проходов без копирования секретов. В каждом примере храните исходное issue, согласованный план, итоговый diff и замечания ревью. Новая задача тогда начинается с проверки похожего случая, а правила доступа получают понятное объяснение для новичков. Такой архив служит учебным материалом и помогает заметить повторяющиеся ошибки.
Владелец инженерной практики периодически просматривает архив PR и убирает инструкции, которые перестали соответствовать коду. Иначе агент продолжит применять устаревшее правило, даже когда свежие тесты требуют другого поведения. Обновление правил лучше связывать с конкретным изменением репозитория и ответственным за него разработчиком.