Michael JohnsonІз 5 листопада команди, які використовують GitHub Copilot Code Review, можуть бачити у звітах API, на які зауваження розробники реагують. Того ж дня GitHub додала поля, що допомагають адміністраторам виявляти прогалини в телеметрії та застарілі версії редакторів. Ці оновлення дають керівникам і власникам організацій конкретніший спосіб оцінювати роботу ШІ-рев’ю та повноту даних про використання Copilot.
Як виміряти реакцію на зауваження ШІ
До щоденного рядка звіту для репозиторію repos-1-day додано об’єкт copilot_code_review. Серед його полів — total_comments_evaluated, кількість оцінених зауважень, і total_comments_addressed, кількість зауважень, на які відреагував розробник. Щоб розрахувати частку опрацьованих зауважень для репозиторію, потрібно поділити друге значення на перше. Нові поля описані в оновленні API метрик використання Copilot.
GitHub зараховує дію, якщо розробник застосував запропоноване виправлення, попросив Copilot внести його, самостійно відредагував код або відповів, що виправлення увійде до наступного запиту на злиття. У звіті коментарі також розподілено за серйозністю, рівнем рев’ю, типом зауваження та наявністю додаткових інструкцій або інструментів. Це дає змогу, наприклад, з’ясувати, чи відрізняються реакції на коментарі щодо безпеки від реакцій на інші зауваження або які категорії потребують більше ручної роботи.
Метрика показує зафіксовану дію, а не підтверджену якість виправлення. Тому її варто розглядати разом із перевіркою коду та станом запиту на злиття: висока частка опрацьованих коментарів свідчить, що на зауваження відреагували, але сама собою не означає, що всі зміни правильні чи необхідні. Важливо й те, що коментарі враховуються в день злиття запиту на злиття, а не в день, коли Copilot їх опублікував.
Чому показник дій відрізняється від прийняття підказок
Попередні поля враховували запуски Copilot Code Review і випадки, коли користувач натискав кнопку застосування готової підказки. Новий показник охоплює більше способів реагування: розробник може самостійно внести виправлення, попросити Copilot зробити це або відкласти зміну до наступного запиту на злиття. Тому total_comments_addressed відповідає на запитання про дії щодо зауважень, а total_copilot_applied_suggestions — лише про прийняття підказок, які можна застосувати однією дією.
У звіті також є total_merged_no_human_change_request_after_review — кількість злитих запитів на злиття, перевірених Copilot, після першого рев’ю яких ніхто з людей не запросив змін. Ці показники описують різні етапи роботи, і їх варто розглядати разом: перший відображає реакцію на коментарі, другий — перебіг рев’ю до злиття.
Нові поля показують, чому звіти неповні
Окреме оновлення від 5 листопада додає відомості про клієнтську телеметрію та версії інструментів. Поле client_telemetry_present показує, чи надходили події з редактора користувача в конкретний день; usage_metrics_requirements вказує, чи відповідають IDE та розширення мінімальним вимогам щодо версій для метрик. Адміністратори також отримують щоденні дані про кількість користувачів без телеметрії та користувачів, які мають принаймні один застарілий компонент. Подробиці наведено в повідомленні про прогалини в даних Copilot.
Це допомагає відокремити активність користувача від повноти звітності. GitHub пояснює: користувач може враховуватися як активний, навіть якщо події з редактора не надійшли, — тоді у звіті бракуватиме таких подробиць, як розподіл використання за функціями та моделями. Причинами можуть бути застаріла версія IDE чи розширення, вимкнена телеметрія редактора, а також проксі або мережевий екран, що блокують події.
Два лічильники прогалин не можна складати, щоб отримати кількість унікальних користувачів: одна людина може належати до обох груп. Крім того, актуальна версія редактора не гарантує надходження телеметрії — наприклад, мережеві обмеження можуть зберігатися. Якщо значення відсутнє або дорівнює null, GitHub позначає його як недоступні дані, а не як нуль або відсутність проблеми.
Що це змінює для команд
Нововведення дають змогу замінити загальний показник активності Copilot двома практичнішими перевірками: що відбувається із зауваженнями Code Review і наскільки надійні дані, на яких ґрунтується внутрішній звіт. Керівники інженерних команд можуть порівнювати типи коментарів і репозиторії, а адміністратори — знаходити користувачів, яким потрібне оновлення IDE чи розширення або перевірка мережевих налаштувань.
Звіти доступні на рівні організації та підприємства користувачам із відповідними правами перегляду метрик Copilot; політику метрик використання Copilot має бути ввімкнено. Дані Code Review містяться в рядках repos-1-day, а поля телеметрії та версій — у користувацьких звітах за один і 28 днів. Це оновлення насамперед корисне організаціям, які вже централізовано адмініструють Copilot: тепер вони можуть досліджувати не лише факт використання помічника, а й реакцію на його рев’ю та причини неповноти вимірювань.
