Когда ИИ проверяет код во многих проектах, мало включить его по одному разу. GitHub добавила управление настройками через API и сделала итог проверки компактнее.
ИИ-проверка полезна, пока команда понимает, что именно она проверяла. Иначе длинный комментарий выглядит убедительно, а важный файл оказывается за пределами просмотра. При десятках проектов добавляется ещё одна проблема: настройки расходятся и менять их вручную неудобно.
Новый выпуск GitHub Copilot code review от 6 ноября затрагивает обе задачи — управление правилами и чтение результата.
GitHub расширила управление проверкой кода Copilot через API, то есть программный интерфейс. В зависимости от роли можно читать и менять настройки предприятия, организации или отдельного репозитория.
Для руководителя это способ задать единый порядок работы. Например, решить, где проверка включена, какое усилие используется по умолчанию и разрешены ли определённые инструкции и инструменты.
Правила верхнего уровня сохраняют силу: организация не может переопределить настройку, которой управляет предприятие. Наличие API не означает, что любой пользователь получил право менять проверку во всех проектах.
В анонсе отдельно перечислены ограничения типов ключей и разрешений. Поэтому такой переход стоит поручать тому, кто отвечает за настройки GitHub, а не передавать общий административный ключ каждому участнику.
Замечания собраны в верхней части, сведения об использованном усилии перенесены в компактный нижний блок, а пропущенные и исключённые файлы объединены в раздел Files not reviewed. Пустые разделы не показываются.
Это небольшая перемена интерфейса с понятным смыслом: читатель быстрее добирается до находок и видит границы проверки. Отсутствие замечаний в комментарии не равно проверке каждого файла проекта.
Условная команда может договориться так: перед принятием правки автор смотрит не только список ошибок, но и список пропусков. Если важный расчёт или форма не проверялись, их рассматривают отдельно.
О том, где находится запрос на принятие кода и как его читать, — в объяснении GitHub. Даже без навыка программирования полезно понимать, где увидеть предмет изменения и результаты проверок.
В сессии Copilot code review теперь отображаются использованные ИИ-кредиты. Это даёт команде больше информации о расходе, но само по себе не показывает окупаемость проверки.
Для неё нужно связать затраты с последствиями: какие существенные ошибки нашли, какие ложные замечания пришлось разбирать и сколько работы осталось человеку. Просто количество комментариев — слабая цель.
Небольшой внутренний разбор можно построить на нескольких типичных изменениях: заранее отметить важные места, дать Copilot выполнить проверку и затем сопоставить находки с человеческим чтением. Отдельно записать расход и пропуски файлов.
Так команда выбирает полезную глубину проверки для своих задач. Общий подход к выбору первой ИИ-задачи и оценке эффекта разбираем в материале о внедрении ИИ.
