Sei aggiornamenti GitHub in tre giorni, dal 6 all’8 agosto, compongono un quadro che va oltre il solito changelog di prodotto. GitHub Copilot aggiunge un dashboard con sezione ROI, i livelli di sforzo per il code review diventati generalmente disponibili, e l’API delle metriche d’uso che ora separa l’attività per singolo agente (Claude, Codex, altri).

Perché ti riguarda. Se hai mandato agenti in produzione, sai che il problema non è più se funzionano. Il problema è: quale agente sta consumando cosa, quanto costa, e dove va il ritorno. Fino a ieri le metriche di GitHub mettevano tutto in un unico bucket: non potevi distinguere il lavoro del coding agent di Copilot da quello fatto attraverso Claude o Codex. Ora puoi. Per chi deve giustificare una spesa o decidere quale agente rinnovare, la differenza fra un totale aggregato e un dato per agente è la differenza fra un’ipotesi e una decisione.

Gli altri aggiornamenti seguono lo stesso filo. Le allowlist MCP a livello enterprise controllano quali server un agente può chiamare, e gli effort levels nel code review classificano quanto lavoro richiede una PR. La governance passa dal “permetti o vieta” al “misura e decidi”.

Se vuoi provarci, l’endpoint delle metriche è documentato nella Copilot usage metrics API. La novità è il campo totals_by_3rd_party_agent, che riporta un’entry per ogni agente riconosciuto.

Nel dettaglio

Fino a questa settimana, se un’organizzazione usava più agenti su GitHub, le metriche di consumo erano un numero unico. L’API restituiva un totale aggregato per “agent activity”, senza distinguere chi faceva cosa. Per un team che ha appena rollato Claude accanto a Codex, rispondere alla domanda “quale usano di più” richiedeva strumenti esterni o stime manuali.

Il nuovo campo totals_by_3rd_party_agent cambia questo. Ogni agente riconosciuto ha la sua voce: nome, identificatore stabile, numero di job avviati dall’utente, numero di sessioni. Il dato è disponibile nei report a livello enterprise, organizzazione, e per singolo utente, su finestre di 1 e 28 giorni.

Un dettaglio che conta per chi lavora con i dati: il campo user_initiated_interaction_count dentro l’array degli agenti conta gli avvii di job, ed è diverso dal campo omonimo al livello superiore che conta i prompt espliciti. GitHub lo dice esplicitamente nelle note: non sommarli, non scambiarli. È il genere di distinzione che chi costruisce dashboard deve sapere prima di presentare i numeri a chi decide i budget.

Il dashboard del ROI e gli effort levels. L’impact dashboard aggiunge una sezione dedicata al ritorno sull’investimento, e i code review effort levels passano da preview a generalmente disponibili. Gli effort levels classificano le PR per complessità: una distinzione che serve quando hai decine di revisioni al giorno e devi scegliere dove mettere l’attenzione umana.

Le allowlist MCP. Enterprise managed settings ora includono allowedMcpServers e deniedMcpServers. Chi gestisce la sicurezza può bloccare o permettere server MCP specifici a livello centralizzato, invece di affidarsi alla disciplina di ogni sviluppatore. È lo stesso pattern visto questa settimana su Claude Code, dove i controlli operativi si sono spostati dalla chat al gateway.

Cosa resta aperto. GitHub non dice quanto sia larga l’adozione degli agent app, né fornisce numeri sull’uso reale. Gli effort levels sono GA ma il dashboard ROI è nuovo: i criteri di calcolo non sono documentati nel changelog. Per chi vuole portare questi numeri in una decisione di budget, vale la pena verificare cosa c’è dietro il “ROI” prima di citarlo in una presentazione.

Questo è il filo che attraversa la settimana: la governance degli agenti smette di essere un documento di policy e diventa infrastruttura. L’avevamo visto su Bedrock AgentCore con regole temporali e rate limiting, e su Claude Code con spend-limit e workspace trust. GitHub lo fa dal lato piattaforma: il posto dove gli agenti girano diventa il posto dove vengono misurati.