GitHub рассказал, как переработал работу агента Copilot code review при переходе на общие инструменты анализа кода из Copilot CLI. Перенастройка инструкций к этим инструментам позволила снизить среднюю стоимость ревью примерно на 20% при сохранении качества.
Изначально Copilot code review использовал собственный набор утилит для навигации по репозиторию: просмотр директорий, поиск по файлам и чтение участков кода с дополнительным контекстом. Эти инструменты были созданы под ранние модели, которые делали меньше вызовов инструментов и хуже подтягивали нужный контекст, поэтому им заранее передавали больше кода.
Параллельно в Copilot CLI была собрана общая Unix-подобная связка для анализа кода: grep, glob и view. Её используют и другие агенты Copilot, включая облачного Copilot-агента, поэтому улучшения в этом наборе автоматически распространяются на несколько продуктов. Команда решила переехать на эти общие инструменты, чтобы сократить дублирование и упростить развитие инфраструктуры.
Ожидалось, что это будет «прозрачная» замена, однако в офлайн-бенчмарках при использовании общих инструментов стоимость ревью выросла, а число полезных замечаний уменьшилось. Трассировки показали, что агент стал вести себя как помощник по изучению всего репозитория, а не как ревьюер конкретного pull request: он делал широкие поиски, читал много файлов и тащил лишний контекст дальше по цепочке рассуждений.
Проблемой оказались не сами grep, glob и view, а инструкции к ним. Описания инструментов были заточены под Copilot CLI и общие сценарии разработки, где агенту нужно изучать репозиторий, планировать изменения и сопровождать несколько шагов диалога. Для ревью pull request такой режим оказался неэффективным.
Команда изменила подход и сформулировала отдельные инструкции под сценарий ревью. Новый желаемый рабочий цикл Copilot code review описывался так: начать с diff, сформулировать узкий вопрос о возможной проблеме, сначала сузить поиск с помощью grep и glob, а затем прочитать точные фрагменты через view, не открывая лишние части репозитория.
Изменилось и поведение при неудачных запросах. Если grep падал из‑за сложного ввода, агенту предлагалось сделать один более простой, исправленный поиск, а при неверном пути — перейти к glob, а не перебирать соседние директории и файлы. Это снижало риск того, что мелкая ошибка в вызове инструмента превратится в длинную и дорогую сессию исследования кода.
Небольшие правки формулировок привели к заметному эффекту. Ритм работы агента сменился с «обзор, чтение, новый поиск» на более целенаправленный: «вопрос, сужение, чтение, решение». По данным внутренних бенчмарков, количество вызовов инструментов осталось примерно тем же, но они чаще использовались для поиска релевантных фрагментов, а не для расширения зоны поиска.
В продакшене это дало около 20% снижения средней стоимости обзора кода по сравнению с контролем при сопоставимом уровне качества. Ключевым фактором стали не сами общие инструменты, а организация рабочего процесса вокруг них, а также наличие внутренних бенчмарков, которые позволили наблюдать и оценивать поведение агента.
Авторы подчёркивают, что поверхность инструментов для агента — часть пользовательского опыта. Описания инструментов и системные инструкции работают как документация к API: неясные формулировки могут привести к неэффективным или ошибочным решениям, а небольшие изменения текста способны повлиять на стоимость, качество и траекторию анализа кода.
Попытка перенести такой же «узконаправленный» стиль инструкций обратно в Copilot CLI не дала аналогичного выигрыша. Это объясняется тем, что Copilot code review всегда привязан к конкретному diff и вопросу ревью, тогда как Copilot CLI решает более широкие, интерактивные задачи, где разработчик может менять направления и нужный контекст не очевиден заранее. Те же инструменты grep, glob и view подходят обоим продуктам, но подход к их использованию и оценке должен соответствовать задаче.
GitHub предлагает разработчикам опробовать подход на практике с помощью GitHub Copilot code review и подчёркивает, что общий набор инструментов хорошо масштабируется, если инструкции и бенчмарки соотносятся с реальными задачами продукта.
Источник: блог GitHub, статья инженера по агентным системам Napalys Klicius.
