GitHub ha annunciato il 6 ottobre 2026 un aggiornamento per gli IDE volto a correggere un errore di attribuzione dei dati relativi agli agenti, che causava una sottostima delle linee di codice e dell'attività nei report di utilizzo.
Il 6 ottobre 2026, GitHub ha annunciato un fix per un problema tecnico che influenzava la precisione delle metriche di utilizzo di Copilot. Se i dati relativi all'attività degli agenti e alle linee di codice generate mostrano un calo mentre l'utilizzo generale di Copilot cresce, la diminuzione delle metriche non basta a dimostrare una riduzione dell'attività effettiva. La causa documentata da GitHub è un errore di attribuzione legato allo spostamento delle sessioni agent verso il Copilot SDK, che non identificava correttamente l'IDE di provenienza dei dati. Gli aggiornamenti correttivi vengono distribuiti nei diversi ambienti di sviluppo con tempistiche distinte. [1]
L'impatto di questo bug si è manifestato principalmente in due modi: una parte significativa dell'attività degli agenti è stata completamente esclusa dai report, mentre un'altra parte è stata erroneamente attribuita all'attività di Copilot CLI. Questo ha creato una distorsione nei dati per le organizzazioni che monitorano l'adozione degli agenti per valutare l'efficacia dei flussi di lavoro AI. È importante sottolineare che l'errore ha riguardato esclusivamente la reportistica delle metriche e non ha avuto alcun impatto sulla fatturazione, che è rimasta corretta poiché basata su parametri differenti rispetto alla telemetria dettagliata dell'IDE. [1]
Per comprendere perché questo errore si sia verificato, è necessario distinguere tra telemetria client-side e server-side. Le metriche più dettagliate, come la scomposizione per linguaggio, modello e le linee di codice (LoC), dipendono esclusivamente dalla telemetria inviata dall'IDE. Quando le sessioni agent sono state migrate al Copilot SDK, l'identificatore dell'IDE è andato perduto, rendendo impossibile per GitHub attribuire correttamente l'attività al client specifico. Questo spiega perché i dati di 'linee di codice aggiunte' o 'eliminate' risultassero sottostimati nei report a 1 e 28 giorni per le versioni colpite. [1][3]
GitHub utilizza inoltre dati server-side per identificare gli utenti attivi, un metodo che risulta più affidabile per contare chi sta effettivamente usando il servizio, indipendentemente dalle impostazioni del client. Tuttavia, il server non può vedere cosa accade all'interno dell'editor di testo; pertanto, dettagli come i suggerimenti accettati o le modifiche effettuate dagli agenti possono provenire solo dall'IDE. Questo crea un gap informativo quando la telemetria del client è bloccata da firewall, proxy o, come in questo caso, da un bug di versione dell'SDK che impedisce la corretta attribuzione dell'IDE. [1][3]
Processo di raccolta dati tra client IDE e server GitHub
La soluzione al problema di attribuzione viene distribuita gradualmente attraverso gli aggiornamenti degli IDE. Al momento dell'annuncio, il fix è già disponibile per Visual Studio Code a partire dalla versione 1.139.0. Per gli altri ambienti di sviluppo, il rilascio è scaglionato: Visual Studio (versione 18.12) è atteso per ottobre 2026 e il prossimo aggiornamento del plugin per gli IDE JetBrains è previsto entro fine ottobre 2026, mentre per Eclipse e Xcode l'aggiornamento è previsto entro novembre 2026. È fondamentale che gli sviluppatori aggiornino i propri strumenti non appena le versioni corrette diventano disponibili, poiché i dati persi durante il periodo di malfunzionamento non possono essere recuperati retroattivamente. [1]
Un aspetto critico per i gestori di flotte di computer aziendali è la gestione centralizzata delle versioni. Poiché l'attività degli agenti torna a essere conteggiata solo dopo l'aggiornamento del client, le aziende che si affidano a queste metriche per misurare il ROI (Ritorno sull'Investimento) devono pianificare un rollout forzato delle versioni minime. Senza un aggiornamento coordinato, i report mostreranno una ripresa graduale e frammentata dell'attività agent, rendendo difficile distinguere tra un reale aumento dell'uso e il semplice ripristino della visibilità dei dati precedentemente invisibili. [1]
L'errore ha influenzato diverse tipologie di report, inclusi quelli a livello di enterprise, organizzazione e singolo utente. In particolare, le metriche di 'agent lines of code' (come loc_added_sum e loc_deleted_sum per agent_edit) sono risultate sottostimate. Parallelamente, le metriche relative a Copilot CLI hanno subito un'inflazione artificiale, poiché alcune attività provenienti da altri client basati su SDK sono state erroneamente classificate come attività CLI. Questo significa che i dati storici del periodo interessato per la CLI non possono essere corretti, poiché è impossibile separare l'uso reale della CLI da quello erroneamente attribuito. [1]
Per chi analizza l'adozione di Copilot, questo scenario evidenzia l'importanza di non basarsi su un unico set di dati. Se i report di utilizzo (basati su telemetria client) divergono dai dati di attività generale (basati su server), è probabile che ci sia un problema di configurazione del client. Un esempio illustrativo di verifica consiste nel confrontare il numero di utenti attivi totali (dato server) con il volume di linee di codice agent prodotte (dato client): se l'attività utenti è alta ma le LoC agent sono quasi nulle in un IDE specifico, è probabile che quel gruppo di sviluppatori stia utilizzando una versione dell'IDE non aggiornata o che la telemetria sia bloccata da un proxy aziendale. [1][3]
Per garantire che i dati di utilizzo siano accurati e completi, GitHub raccomanda una serie di misure preventive. Innanzitutto, è essenziale mantenere aggiornati sia gli IDE che le estensioni di Copilot Chat. L'uso di strumenti di gestione dei dispositivi (MDM) per imporre versioni minime è la strategia più efficace per evitare gap nei dati. Inoltre, è necessario assicurarsi che la telemetria dell'IDE sia abilitata e che gli endpoint di telemetria di Copilot siano autorizzati attraverso i firewall e i proxy aziendali, poiché qualsiasi blocco a questo livello impedisce l'invio dei dati dettagliati necessari per i report di produttività. [1][3]
Un'ulteriore best practice consiste nell'utilizzare l'API delle metriche di utilizzo di Copilot invece delle sole dashboard. L'API fornisce una vista più completa e aggiornata, includendo dettagli a livello di repository e utente che permettono di individuare i client obsoleti. Nei report per utente, il campo 'totals_by_ide' include le versioni dell'IDE e del plugin più recenti conosciute; monitorare questi campi permette agli amministratori di identificare esattamente quali sviluppatori necessitano di un aggiornamento per ripristinare la visibilità della loro attività agent nei report aziendali. [1][3]
Le organizzazioni devono valutare l'impatto di questo aggiornamento in base al loro livello di dipendenza dalle metriche agent. Chi utilizza le dashboard di 'Impact' per calcolare il ROI basandosi sulle coorti di utenti (come gli 'Agent First Users') troverà in questo aggiornamento un elemento essenziale per non sottostimare l'efficacia dell'AI nei flussi di lavoro. Al contrario, chi monitora solo l'adozione generale (DAU - Daily Active Users) tramite telemetria server-side non ha subito interruzioni, poiché il conteggio degli utenti attivi è rimasto accurato nonostante il bug di attribuzione dell'IDE. [1][3]
L'aggiornamento è prioritario per i team che operano con IDE diversi da VS Code, dato che per questi ultimi il fix è già operativo. Per chi utilizza JetBrains, Eclipse o Xcode, l'azione immediata è il monitoraggio delle release di ottobre e novembre 2026. Una volta aggiornati i client, l'amministratore vedrà un incremento delle metriche agent; questo non deve essere interpretato come un improvviso boom di produttività, ma come il ripristino della visibilità di attività che erano già in corso ma non tracciate correttamente a causa del problema dell'SDK. [1]
Il 7 ottobre 2026 GitHub ha reso generalmente disponibile il sandboxing locale per Copilot CLI, l'app Copilot e VS Code, permettendo l'esecuzione di workflow agentici in ambienti isolati e sicuri.
Rilasciato il 6 ottobre 2026, Gemini Nano Banana 2.1 introduce miglioramenti nella qualità visiva, nel rendering del testo e nel supporto per formati panoramici, sostituendo il modello Nano Banana 2.
Mistral Large 4 arriva in public preview: architettura MoE, testo e immagini, risultati sul coding e pesi attesi a fine ottobre. Analizziamo specifiche, divergenze nelle fonti e criteri per provarlo.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.