Jak mierzyć pilotaż GitHub Copilot, wychodząc poza liczbę podpowiedzi

Co mierzą metryki Copilota od GitHuba

GitHub dzieli metryki użycia Copilota na adopcję, zaangażowanie, odsetek akceptacji, linie kodu i cykl życia pull requestów. Są dostępne w dashboardzie z trendami z 28 dni, w dashboardzie wpływu, w API z raportami dla organizacji, repozytoriów i użytkowników oraz w eksportach NDJSON. Dane z danego dnia pojawiają się w ciągu dwóch pełnych dni UTC.

Większość pochodzi z telemetrii IDE po stronie klienta, więc najpełniejsze dane wymagają włączonej telemetrii i obsługiwanej wersji IDE oraz rozszerzenia. Telemetria po stronie serwera nadal liczy użytkowników, których telemetria kliencka nie dociera, więc liczba aktywnych użytkowników pozostaje wiarygodna, ale ich podział według funkcji i linii kodu jest pusty. Copilot Chat na GitHub.com i GitHub Mobile nie są uwzględniane.

Warstwa pierwsza: czy pilotaż w ogóle się odbył?

Dane o użyciu odpowiadają na pytanie, czy narzędzia używano wystarczająco, żeby je ocenić. Przewodnik GitHuba po interpretacji uznaje stosunek tygodniowo aktywnych użytkowników do licencji powyżej 60 procent za zdrowe, regularne użycie. Dashboard wpływu dzieli użytkowników na kohorty: pasywni, code first, agent first i multi-agent, w zależności od tego, z jakich powierzchni korzystali w co najmniej dwóch dniach z ostatnich 28.

Traktuj tę warstwę jako warunek wstępny, a nie werdykt, i uważnie czytaj kohorty. Pasywny nie znaczy bezczynny: GitHub zaznacza, że ktoś, kto zadaje pytania w Copilot Chat albo w trybie agenta, ale nie stosuje zmian w kodzie, może pozostać w kohorcie pasywnej. Duży udział pasywnych to powód, żeby ustalić, jak grupa naprawdę pracuje z Copilotem, sprawdzając licencje, konfigurację IDE i robiąc krótką ankietę, zanim zaczniesz interpretować cokolwiek innego.

Warstwa druga: co dzieje się z pull requestami

API metryk użycia raportuje dzienną aktywność pull requestów, w tym pull requesty utworzone przez Copilot cloud agent, liczbę zmergowanych, ich medianę czasu do merge'a oraz sugestie Copilot code review i liczbę zastosowanych, z podziałem na typ komentarza. Raporty na poziomie repozytorium dodają czas trwania etapów review dla pull requestów otwartych przez ludzi i przejrzanych przez innych ludzi.

Dzienne liczby pokazują przepustowość: pull requesty Copilota utworzone i zmergowane w danym dniu. Utworzenie i merge to osobne zdarzenia w różnych dniach, więc merge podzielone przez utworzenia z tego samego tygodnia nie są odsetkiem merge'y i mogą przekroczyć 100 procent. Żeby mieć odsetek merge'y, śledź stały zbiór pull requestów Copilota po ich identyfikatorach od utworzenia przez ustalone okno, na przykład 14 dni, na podstawie danych z hosta gita. Kolejną lukę stanowi nakład review: czasy etapów review w GitHubie pomijają pull requesty tworzone przez boty, łącznie z Copilot cloud agent, oraz te zmergowane bez kwalifikującego się review człowieka, więc czas review dla pull requestów agenta też mierz na podstawie zdarzeń z hosta gita.

Warstwa trzecia: dane, których GitHub nie ma

To, czy zmergowana praca się sprawdziła, jest w twojej własnej historii. Commity Copilot cloud agent mają Copilota jako autora i programistę, który zlecił zadanie, jako współautora, więc jego zmiany łatwo oznaczyć. Na podstawie tego oznaczenia śledź dla każdego zespołu i repozytorium:

• Poprawki: kolejne commity naprawiające zmergowaną zmianę w uzgodnionym oknie czasowym
• Reverty oraz pull requesty Copilota zamknięte bez merge'a
• Czas i rundy review na pull request Copilota, na podstawie zdarzeń z hosta gita, bo czasy etapów w GitHubie pomijają pull requesty tworzone przez boty
• Wydatki z danych rozliczeniowych podzielone przez zmergowane zmiany, które nie wymagały poprawek

Gdzie liczby wprowadzają w błąd

• Odsetek akceptacji i linie kodu liczą produkcję. GitHub nazywa linie kodu miarą kierunkową, a edycje agenta nie przechodzą przez schemat propozycji i akceptacji.
• Adoption multiplier porównuje różne grupy użytkowników. Sam GitHub mówi, że skład zespołu i doświadczenie mogą wpływać na niego tak samo jak korzystanie z narzędzia, a widok zwrotu z inwestycji pokazuje powiązania, nie przyczyny.
• Raporty na poziomie zespołów pomijają zespoły z mniej niż pięcioma użytkownikami z licencją Copilota, więc suma wierszy zespołów jest mniejsza niż wynik całej organizacji.
• Metryki na poziomie organizacji liczą użytkownika w każdej organizacji, do której należy, więc wyników organizacji nie można sumować.

Arkusz decyzji o kontynuacji

Poniższe progi są hipotetyczne i należy je zastąpić własnymi, uzgodnionymi przed pilotażem i odczytywanymi dla każdego zespołu i typu zadań:

• Rozszerzyć: aktywne użycie jest stabilne w całej grupie pilotażowej, odsetek merge'y śledzonych pull requestów Copilota osiąga poziom ustalony z góry, a poprawki, reverty i czas review nie przekraczają punktu odniesienia.
• Wstrzymać i poprawić: użycie jest zdrowe, ale wzrosły poprawki albo liczba rund review. Popraw instrukcje repozytorium, kroki konfiguracji i sposób opisywania zadań, a potem zmierz ponownie.
• Przedłużyć: za mało użycia albo zmergowanych pull requestów, żeby ocenić. Pilotaż jeszcze nie odpowiedział na pytanie.
• Zakończyć: użycie pozostało niskie po wdrożeniu albo obciążenie review wzrosło, a nie przybyło zmergowanej pracy.

Jak zaprojektować uczciwy pilotaż agentów kodującychWdrożenie GitHub Copilot