GitHub aggiunge una metrica: quanti commenti di Copilot Code Review vengono gestiti dagli sviluppatori

Dal 5 novembre, i team che utilizzano GitHub Copilot Code Review possono vedere nei report dell’API a quali commenti gli sviluppatori danno seguito. Lo stesso giorno, GitHub ha aggiunto campi che aiutano gli amministratori a individuare lacune nella telemetria e versioni obsolete degli editor. Questi aggiornamenti offrono ai responsabili e ai titolari delle organizzazioni un modo più concreto per valutare il funzionamento della revisione assistita dall’IA e la completezza dei dati sull’uso di Copilot.

Come misurare la reazione ai commenti dell’IA

Alla riga giornaliera del report per repository repos-1-day è stato aggiunto l’oggetto copilot_code_review. Tra i suoi campi ci sono total_comments_evaluated, il numero di commenti esaminati, e total_comments_addressed, il numero di commenti a cui lo sviluppatore ha dato seguito. Per calcolare la quota di commenti gestiti per un repository, occorre dividere il secondo valore per il primo. I nuovi campi sono descritti nell’aggiornamento dell’API Copilot usage metrics.

GitHub considera un commento gestito quando lo sviluppatore applica la correzione proposta, chiede a Copilot di apportarla, modifica il codice autonomamente o risponde che la correzione sarà inclusa nella prossima pull request. Il report suddivide inoltre i commenti per gravità, livello di revisione, tipo di commento e presenza di istruzioni aggiuntive o strumenti. Questo consente al team, per esempio, di verificare se le reazioni ai commenti sulla sicurezza differiscono da quelle agli altri commenti, o quali categorie richiedono più lavoro manuale.

La metrica registra un’azione, non conferma la qualità della correzione. È quindi utile leggerla insieme alla revisione del codice e allo stato della pull request: una quota elevata di commenti gestiti indica che i commenti hanno ricevuto una risposta, ma non dimostra di per sé che tutte le modifiche siano corrette o necessarie. Un altro aspetto importante: i commenti vengono conteggiati nel giorno in cui la pull request viene unita, non in quello in cui Copilot li pubblica.

Perché il tasso di azioni intraprese differisce dall’accettazione dei suggerimenti

I campi precedenti conteggiavano le esecuzioni di Copilot Code Review e i casi in cui l’utente premeva il pulsante per applicare un suggerimento pronto. La nuova metrica comprende più modalità di reazione: lo sviluppatore può apportare la correzione autonomamente, chiedere a Copilot di farlo o rimandare la modifica alla pull request successiva. Perciò total_comments_addressed risponde alla domanda sulle azioni intraprese in seguito ai commenti, mentre total_copilot_applied_suggestions conta solo l’accettazione dei suggerimenti applicabili con un’unica azione.

Il report include anche total_merged_no_human_change_request_after_review: il numero di pull request unite e revisionate da Copilot per le quali, dopo la prima revisione, nessuna persona ha richiesto modifiche. Questi indicatori descrivono fasi diverse del lavoro e si interpretano meglio insieme: il primo riflette la reazione ai commenti, il secondo l’andamento della revisione prima dell’unione.

I nuovi campi mostrano perché i report sono incompleti

Un aggiornamento separato del 5 novembre aggiunge informazioni sulla telemetria client e sulle versioni degli strumenti. Il campo client_telemetry_present indica se, in un determinato giorno, sono arrivati eventi dall’editor dell’utente; usage_metrics_requirements segnala se l’IDE e le estensioni soddisfano i requisiti minimi di versione per le metriche. Gli amministratori ricevono inoltre i conteggi giornalieri degli utenti senza telemetria e di quelli con almeno un componente obsoleto. I dettagli sono elencati nella nota sulle lacune nei dati di Copilot.

Questo aiuta a distinguere l’attività dell’utente dalla completezza dei report. GitHub spiega che un utente può essere conteggiato come attivo anche quando non arrivano eventi dall’editor: in tal caso, il report perde dettagli come la ripartizione dell’uso per funzionalità e modelli. Le cause possono includere una versione obsoleta dell’IDE o dell’estensione, la telemetria dell’editor disattivata oppure un proxy o un firewall che blocca gli eventi.

I due contatori delle lacune non vanno sommati per ottenere il numero di utenti unici: la stessa persona può rientrare in entrambi i gruppi. Inoltre, una versione corretta dell’editor non garantisce che la telemetria arrivi: per esempio, possono persistere restrizioni di rete. Se un valore è assente o pari a null, GitHub lo indica come dato non disponibile, non come zero o assenza del problema.

Cosa cambia per i team

Le novità consentono di sostituire un indicatore generico dell’attività di Copilot con due verifiche più concrete: cosa succede ai commenti di Code Review e quanto sono affidabili i dati alla base dei report interni. I responsabili dei team di ingegneria possono confrontare tipi di commenti e repository, mentre gli amministratori possono individuare gli utenti che necessitano di aggiornare l’IDE o l’estensione oppure di controllare le impostazioni di rete.

I report sono disponibili a livello di organizzazione e impresa per gli utenti che dispongono dei permessi necessari per visualizzare le metriche di Copilot; la relativa policy di utilizzo delle metriche deve essere attiva. I dati di Code Review si trovano nelle righe repos-1-day, mentre i campi relativi a telemetria e versioni sono inclusi nei report utente di uno e 28 giorni. L’aggiornamento è quindi particolarmente utile per le organizzazioni che già amministrano Copilot in modo centralizzato: ora possono analizzare non solo l’uso dell’assistente, ma anche le reazioni alle sue revisioni e le cause delle misurazioni incomplete.