Michael JohnsonС 5 ноября команды, использующие GitHub Copilot Code Review, могут видеть в отчётах API, к каким замечаниям разработчики перешли к действию. В тот же день GitHub добавила поля, помогающие администраторам находить пробелы в телеметрии и устаревшие версии редакторов. Эти обновления дают руководителям и владельцам организаций более предметный способ проверять, как работает ИИ-ревью и насколько полны данные об использовании Copilot.
Как измерить реакцию на замечания ИИ
В ежедневную строку отчёта по репозиторию `repos-1-day` добавлен объект `copilot_code_review`. Среди его полей — `total_comments_evaluated`, число проверенных замечаний, и `total_comments_addressed`, число замечаний, на которые разработчик отреагировал. Чтобы рассчитать долю обработанных замечаний для репозитория, нужно разделить второе значение на первое. Новые поля описаны в обновлении Copilot usage metrics API.
GitHub засчитывает действие, если разработчик применил предложенное исправление, попросил Copilot внести его, отредактировал код самостоятельно или ответил, что исправление войдёт в следующий pull request. Отчёт отдельно разбивает комментарии по серьёзности, уровню ревью, типу замечания и наличию дополнительных инструкций или инструментов. Это позволяет команде изучать, например, отличаются ли реакции на комментарии о безопасности от реакций на другие замечания, или какие категории требуют больше ручной работы.
Метрика показывает зафиксированное действие, а не подтверждённое качество исправления. Поэтому её полезно читать вместе с проверкой кода и состоянием pull request: высокая доля обработанных комментариев говорит о том, что замечания получили отклик, а не сама по себе о том, что все изменения верны или необходимы. Важно и другое: комментарии учитываются в день слияния pull request, а не в день, когда Copilot их опубликовал.
Почему показатель действий отличается от принятия подсказок
Предыдущие поля учитывали запуски Copilot Code Review и случаи, когда пользователь нажимал кнопку применения готовой подсказки. Новый показатель охватывает больше способов реакции: разработчик может внести исправление самостоятельно, попросить Copilot сделать это или отложить изменение до следующего pull request. Поэтому `total_comments_addressed` отвечает на вопрос о действиях по замечаниям, а `total_copilot_applied_suggestions` — только о принятии подсказок, которые можно применить одним действием.
В отчёте также есть `total_merged_no_human_change_request_after_review`: число слитых pull request, проверенных Copilot, после первого ревью которых никто из людей не запросил изменения. Эти показатели описывают разные этапы работы и лучше читаются вместе: первый отражает реакцию на комментарии, второй — ход ревью до слияния.
Новые поля показывают, почему отчёты неполны
Отдельное обновление от 5 ноября добавляет сведения о клиентской телеметрии и версиях инструментов. Поле `client_telemetry_present` показывает, поступали ли события из редактора пользователя в конкретный день; `usage_metrics_requirements` указывает, соответствуют ли IDE и расширения минимальным версиям для метрик. Администраторы также получают дневные числа пользователей без телеметрии и пользователей хотя бы с одним устаревшим компонентом. Подробности перечислены в заметке о пробелах в данных Copilot.
Это помогает отделить активность пользователя от полноты отчётности. GitHub поясняет: пользователь может учитываться как активный, даже если события из редактора не поступили, — тогда отчёт теряет детали вроде распределения использования по функциям и моделям. Причинами могут быть старая версия IDE или расширения, отключённая телеметрия редактора, а также прокси или сетевой экран, блокирующие события.
Два счётчика пробелов нельзя складывать как число уникальных пользователей: один человек может попасть в обе группы. Кроме того, корректная версия редактора не гарантирует поступление телеметрии — например, сетевые ограничения могут сохраняться. Если значение отсутствует или равно `null`, GitHub обозначает его как недоступные данные, а не как ноль или отсутствие проблемы.
Что это меняет для команд
Нововведения позволяют заменить общий показатель активности Copilot двумя более прикладными проверками: что происходит с замечаниями Code Review и насколько надёжны данные, на которых строится внутренний отчёт. Руководители инженерных команд могут сравнивать типы комментариев и репозитории, а администраторы — находить пользователей, которым требуется обновление IDE, расширения или проверка сетевых настроек.
Отчёты доступны на уровне организации и предприятия пользователям с соответствующими правами просмотра метрик Copilot; политика Copilot usage metrics должна быть включена. Данные по Code Review находятся в строках `repos-1-day`, а поля телеметрии и версий — в пользовательских отчётах за один и 28 дней. Это делает новое обновление полезным прежде всего для организаций, которые уже администрируют Copilot централизованно: теперь они могут исследовать не только факт использования помощника, но и реакцию на его ревью и причины неполных измерений.
