Michael JohnsonFra 5. november kan team som bruker GitHub Copilot Code Review, se i API-rapportene hvilke merknader utviklere følger opp. Samme dag la GitHub til felt som hjelper administratorer med å finne hull i telemetrien og utdaterte editorversjoner. Oppdateringene gir ledere og organisasjonseiere en mer konkret måte å undersøke hvordan AI-gjennomgangen fungerer, og hvor fullstendige dataene om Copilot-bruken er.
Slik måler du responsen på AI-merknader
Et objekt kalt copilot_code_review er lagt til i den daglige rapportlinjen for repositorier, repos-1-day. Blant feltene er total_comments_evaluated, antallet vurderte merknader, og total_comments_addressed, antallet merknader utvikleren har fulgt opp. For å beregne andelen fulgte merknader for et repository deler du den andre verdien på den første. De nye feltene er beskrevet i oppdateringen av Copilot usage metrics API.
GitHub regner en merknad som fulgt opp hvis utvikleren bruker det foreslåtte rettingsforslaget, ber Copilot om å gjøre endringen, redigerer koden selv eller svarer at rettingen skal tas med i neste pull request. Rapporten deler også kommentarene inn etter alvorlighetsgrad, gjennomgangsnivå, merknadstype og om det finnes tilleggsinstruksjoner eller verktøy. Dermed kan teamet for eksempel undersøke om responsen på sikkerhetsmerknader skiller seg fra responsen på andre merknader, eller hvilke kategorier som krever mer manuelt arbeid.
Målingen viser registrert oppfølging, ikke om rettingen er bekreftet god. Derfor er det nyttig å se den i sammenheng med kodegjennomgang og statusen til pull requesten: En høy andel fulgte kommentarer viser at merknadene fikk respons, men betyr ikke i seg selv at alle endringene er riktige eller nødvendige. Det er også viktig at kommentarene telles på dagen pull requesten flettes inn, ikke dagen Copilot publiserte dem.
Hvorfor oppfølgingstallet er forskjellig fra godkjente forslag
De tidligere feltene registrerte kjøringer av Copilot Code Review og tilfeller der brukeren trykket på knappen for å bruke et ferdig forslag. Den nye målingen omfatter flere typer respons: Utvikleren kan rette feilen selv, be Copilot gjøre det eller utsette endringen til neste pull request. Derfor gjelder total_comments_addressed oppfølging av merknader, mens total_copilot_applied_suggestions bare gjelder forslag som kan brukes med én handling.
Rapporten inneholder også total_merged_no_human_change_request_after_review: antallet flettede pull requests som Copilot har gjennomgått, der ingen mennesker ba om endringer etter den første gjennomgangen. Målingene beskriver ulike stadier i arbeidet og gir mest mening sammen: Den første viser responsen på kommentarer, mens den andre viser hvordan gjennomgangen forløp fram til fletting.
Nye felt viser hvorfor rapportene er ufullstendige
En separat oppdatering fra 5. november legger til informasjon om klienttelemetri og verktøyversjoner. Feltet client_telemetry_present viser om hendelser fra brukerens editor ble mottatt en bestemt dag. usage_metrics_requirements angir om IDE-en og utvidelsene oppfyller minstekravene til versjon for målingene. Administratorer får også daglige tall for brukere uten telemetri og brukere med minst én utdatert komponent. Flere detaljer står i merknaden om mangler i Copilot-dataene.
Dette gjør det mulig å skille mellom brukeraktivitet og hvor fullstendig rapporteringen er. GitHub forklarer at en bruker kan telles som aktiv selv om ingen hendelser fra editoren ble mottatt. I så fall mangler rapporten detaljer som fordelingen av bruk på funksjoner og modeller. Mulige årsaker er en gammel IDE- eller utvidelsesversjon, deaktivert editortelemetri eller en proxy eller brannmur som blokkerer hendelsene.
De to mangeltellerne kan ikke summeres for å få antallet unike brukere, siden samme person kan være med i begge gruppene. En oppdatert editorversjon garanterer heller ikke at telemetrien kommer fram; nettverksbegrensninger kan fortsatt være et problem. Hvis en verdi mangler eller er null, angir GitHub at dataene ikke er tilgjengelige – ikke at verdien er null eller at problemet ikke finnes.
Hva dette betyr for teamene
Oppdateringene gjør det mulig å erstatte et generelt mål på Copilot-aktivitet med to mer konkrete undersøkelser: Hva skjer med merknadene fra Code Review, og hvor pålitelige er dataene som den interne rapporten bygger på? Ledere for utviklingsteam kan sammenligne merknadstyper og repositorier, mens administratorer kan finne brukere som trenger en IDE- eller utvidelsesoppdatering eller en gjennomgang av nettverksinnstillingene.
Rapportene er tilgjengelige på organisasjons- og bedriftsnivå for brukere med de nødvendige rettighetene til å vise Copilot-målinger. Retningslinjene for Copilot usage metrics må være aktivert. Code Review-dataene finnes i radene for repos-1-day, mens telemetri- og versjonsfeltene finnes i brukerrapporter for én og 28 dager. Oppdateringen er dermed særlig nyttig for organisasjoner som allerede administrerer Copilot sentralt: Nå kan de undersøke ikke bare om assistenten brukes, men også hvordan utviklerne reagerer på gjennomgangene, og hvorfor målingene kan være ufullstendige.
