Michael JohnsonOd 5 listopada zespoły korzystające z GitHub Copilot Code Review mogą sprawdzać w raportach API, na które uwagi programiści reagują. Tego samego dnia GitHub dodał pola pomagające administratorom wykrywać braki w telemetrii i przestarzałe wersje edytorów. Aktualizacje te dają kierownikom i właścicielom organizacji bardziej konkretny sposób oceny działania przeglądu kodu przez AI oraz kompletności danych o użyciu Copilota.
Jak mierzyć reakcje na uwagi AI
Do dziennego wiersza raportu dla repozytorium repos-1-day dodano obiekt copilot_code_review. Wśród jego pól są total_comments_evaluated, czyli liczba ocenionych uwag, oraz total_comments_addressed, czyli liczba uwag, na które zareagował programista. Aby obliczyć odsetek uwag, którymi zajęto się w repozytorium, należy podzielić drugą wartość przez pierwszą. Nowe pola opisano w aktualizacji API metryk użycia Copilota.
GitHub zalicza reakcję, gdy programista zastosuje sugerowaną poprawkę, poprosi Copilota o jej wprowadzenie, samodzielnie zmodyfikuje kod lub odpowie, że poprawka trafi do następnego pull requesta. Raport osobno dzieli komentarze według powagi, poziomu przeglądu, typu uwagi oraz tego, czy wykorzystano dodatkowe instrukcje lub narzędzia. Dzięki temu zespół może na przykład sprawdzić, czy reakcje na komentarze dotyczące bezpieczeństwa różnią się od reakcji na inne uwagi albo które kategorie wymagają więcej pracy ręcznej.
Wskaźnik pokazuje odnotowaną reakcję, a nie potwierdzoną jakość poprawki. Dlatego warto analizować go razem z przeglądem kodu i stanem pull requesta: wysoki odsetek uwag, na które zareagowano, oznacza, że spotkały się z odpowiedzią, ale sam w sobie nie dowodzi, że wszystkie zmiany są poprawne lub potrzebne. Istotne jest też to, że komentarze są uwzględniane w dniu scalenia pull requesta, a nie w dniu ich opublikowania przez Copilota.
Dlaczego wskaźnik reakcji różni się od przyjęcia podpowiedzi
Wcześniejsze pola uwzględniały uruchomienia Copilot Code Review oraz przypadki, w których użytkownik kliknął przycisk zastosowania gotowej podpowiedzi. Nowy wskaźnik obejmuje więcej sposobów reakcji: programista może sam wprowadzić poprawkę, poprosić o nią Copilota lub odłożyć zmianę do następnego pull requesta. Dlatego total_comments_addressed odpowiada na pytanie o reakcje na uwagi, a total_copilot_applied_suggestions — wyłącznie o przyjęcie podpowiedzi, które można zastosować jednym działaniem.
Raport zawiera również total_merged_no_human_change_request_after_review: liczbę scalonych pull requestów sprawdzonych przez Copilota, w których po pierwszym przeglądzie żaden człowiek nie zażądał zmian. Wskaźniki opisują różne etapy pracy i najlepiej analizować je łącznie: pierwszy pokazuje reakcje na komentarze, a drugi — przebieg przeglądu przed scaleniem.
Nowe pola pokazują, dlaczego raporty są niekompletne
Osobna aktualizacja z 5 listopada dodaje informacje o telemetrii klientów i wersjach narzędzi. Pole client_telemetry_present wskazuje, czy danego dnia napłynęły zdarzenia z edytora użytkownika; usage_metrics_requirements informuje, czy środowisko IDE i rozszerzenia spełniają minimalne wymagania wersji dla metryk. Administratorzy otrzymują również dzienne liczby użytkowników bez telemetrii oraz użytkowników mających co najmniej jeden przestarzały komponent. Szczegóły opisano w informacji o brakach w danych Copilota.
Ułatwia to odróżnienie aktywności użytkownika od kompletności raportowania. GitHub wyjaśnia, że użytkownik może być zaliczony jako aktywny nawet wtedy, gdy nie napłynęły zdarzenia z edytora — w takim przypadku raport traci szczegóły, takie jak podział użycia według funkcji i modeli. Przyczyną może być stara wersja IDE lub rozszerzenia, wyłączona telemetria edytora, a także serwer proxy lub zapora sieciowa blokujące zdarzenia.
Dwóch liczników braków nie należy sumować, by ustalić liczbę unikalnych użytkowników: ta sama osoba może należeć do obu grup. Ponadto aktualna wersja edytora nie gwarantuje napływu telemetrii — ograniczenia sieciowe mogą nadal występować. Jeśli wartość nie występuje lub wynosi null, GitHub oznacza ją jako niedostępne dane, a nie jako zero lub brak problemu.
Co to oznacza dla zespołów
Nowości pozwalają zastąpić ogólny wskaźnik aktywności Copilota dwiema bardziej praktycznymi kontrolami: co dzieje się z uwagami Code Review i jak wiarygodne są dane, na których opiera się wewnętrzny raport. Kierownicy zespołów inżynierskich mogą porównywać typy komentarzy i repozytoria, a administratorzy — identyfikować użytkowników, którzy potrzebują aktualizacji IDE lub rozszerzenia albo sprawdzenia ustawień sieciowych.
Raporty są dostępne na poziomie organizacji i przedsiębiorstwa dla użytkowników z odpowiednimi uprawnieniami do przeglądania metryk Copilota; polityka metryk użycia Copilota musi być włączona. Dane dotyczące Code Review znajdują się w wierszach repos-1-day, a pola telemetrii i wersji — w raportach użytkowników za jeden i 28 dni. Aktualizacja jest więc szczególnie przydatna dla organizacji, które już centralnie administrują Copilotem: mogą teraz analizować nie tylko sam fakt korzystania z asystenta, lecz także reakcje na jego przeglądy oraz przyczyny niekompletnych pomiarów.
