Come Misurare l’Utilità di Claude Code

Come Misurare l’Utilità di Claude Code

“Claude Code ci fa lavorare meglio” è una frase che in azienda non basta più: serve un numero, o meglio un set di numeri, che regga davanti a un dirigente. In questo articolo vediamo quali strumenti nativi Anthropic e quali stack di monitoring esterni usare per misurare davvero l’impatto di Claude Code su un progetto software, con un caso pratico, l’implementazione tecnica e cosa ne pensano gli sviluppatori che lo usano ogni giorno.

Indice dei contenuti – Come Misurare l’Utilità di Claude Code

1. Perché “sembra più veloce” non è una metrica
2. Gli strumenti nativi Anthropic: dashboard, Console e Analytics API
3. E se hai solo il piano Pro? Misurare la produttività senza dashboard di team
4. Monitoring avanzato: OpenTelemetry, Prometheus e Grafana
5. Le trappole delle metriche: cosa NON ti dicono i numeri
6. Caso pratico: misurare l’impatto su un team di 12 sviluppatori
7. Implementazione: come collegare Claude Code al tuo stack di osservabilità
8. Cosa dicono davvero gli sviluppatori: un giro su Reddit
9. Conclusioni: governare la complessità nascosta

1. Perché “sembra più veloce” non è una metrica

Iniziamo a spiegare Come Misurare l’Utilità di Claude Code. Ogni team che adotta Claude Code passa per la stessa fase: qualche settimana di entusiasmo, la sensazione diffusa di scrivere codice più in fretta, e poi la domanda del management: “quanto ci sta facendo risparmiare, in soldi o in tempo?”. A quel punto le sensazioni non bastano più.

Il problema non è la mancanza di dati, Claude Code ne genera moltissimi, ma il fatto che vengono esposti su livelli diversi e disconnessi tra loro: log locali in JSONL, il comando /cost in sessione, la dashboard di claude.ai, la Console per chi usa l’API, e infine un eventuale layer di observability costruito in casa. Prima di scegliere uno strumento, conviene capire cosa misura ciascun livello e a chi serve davvero.

2. Gli strumenti nativi Anthropic: dashboard, Console e Analytics API

Il punto di partenza è la dashboard integrata, raggiungibile su claude.ai/analytics/claude-code per i piani Team ed Enterprise, oppure su platform.claude.com/claude-code per chi usa l’API tramite Console. Mostra due famiglie di metriche: metriche di utilizzo (righe di codice accettate, tasso di accettazione dei suggerimenti, utenti e sessioni attivi al giorno) e metriche di contribuzione, che collegano le sessioni di Claude Code alle pull request effettivamente unite grazie all’integrazione con GitHub.

Per un dato più granulare, esiste la Claude Code Analytics API: richiede una Admin API key e restituisce un record al giorno per ogni utente, con sessioni, righe aggiunte e rimosse, commit, pull request, uso dei tool e costo stimato per modello. È pensata proprio per costruire report ROI da mostrare a chi decide il budget, oppure per esportare i dati verso un data warehouse interno.

Un dettaglio poco intuitivo ma importante: l’attribuzione del codice a Claude Code non è “tutto o niente”. Anthropic esclude dal conteggio il codice che lo sviluppatore ha riscritto per oltre il 20%, considera solo le sessioni in una finestra di 21 giorni prima della merge e ignora file generati automaticamente o lock file. È una scelta conservativa che rende i numeri più difendibili in una revisione di board, ma va spiegata prima di presentarli, altrimenti qualcuno chiederà perché il totale “non torna” rispetto a quello che percepisce.

Per chi ha esigenze di sicurezza o compliance, esiste anche la Claude Enterprise Analytics API, pensata per l’adozione a livello organizzativo su tutti i prodotti Claude (chat, progetti, Claude Code), non solo sul singolo strumento da terminale.

3. E se hai solo il piano Pro? Misurare la produttività senza dashboard di team

Proseguiamo nello spiegare Come Misurare l’Utilità di Claude Code specialmente per i piccoli team. Tutto quello visto finora (dashboard di analytics, Contribution metrics, Analytics API) richiede un piano Team, Enterprise, oppure l’accesso alla Console con una Admin API key. Un sviluppatore singolo o una piccola software house sul piano Pro ($20/mese) o Max ($100-200/mese) non ha nulla di tutto questo: la dashboard di claude.ai/analytics/claude-code semplicemente non è disponibile per gli account individuali, e questa è oggi una delle lamentele più ricorrenti tra chi lavora da freelance o in team piccoli che non vogliono passare a un piano organizzativo solo per vedere qualche grafico.

La buona notizia è che i dati esistono comunque, solo che restano sul disco locale invece che in una dashboard cloud. Ogni sessione di Claude Cod, indipendentemente dal piano, Pro, Max o API, viene scritta come file JSONL in ~/.claude/projects/, con il dettaglio completo di token di input, output, scrittura e lettura cache, modello usato e timestamp per ogni singola chiamata. È lo stesso dato grezzo che alimenta le dashboard enterprise, solo che su Pro/Max tocca leggerlo da soli.

Per farlo senza scrivere script a mano, la community ha costruito diversi strumenti open source che leggono questi log locali e li trasformano in report leggibili:

• ccusage : CLI TypeScript senza installazione (si lancia con npx ccusage@latest), è probabilmente il tool più diffuso per questo scopo. Produce breakdown giornalieri, mensili, per sessione e per finestra di 5 ore, distinguendo token di cache creation e cache read. Funziona interamente offline, senza API key né account, perché legge solo i file locali.
• Claude Code Usage Monitor (cmonitor) : invece di un report storico, mostra una dashboard terminale in tempo reale con burn-rate del consumo token e una stima di quando esaurirai la finestra di utilizzo corrente, utile per non ritrovarsi bloccati a metà di un task importante.
• claude-usage : un dashboard locale (Python, zero dipendenze esterne) che scansiona gli stessi file JSONL, li salva in un database SQLite locale e serve un’interfaccia web su localhost con grafici, filtro per modello e intervallo di date — comodo per chi vuole qualcosa di più visuale della sola CLI.
• I comandi nativi /cost e /context, disponibili direttamente in sessione: il primo mostra una stima di token e costo per la sessione corrente, il secondo quanto si sta riempiendo la finestra di contesto, utile per capire quando conviene ripulire la conversazione prima che le prestazioni calino.

Vale un avviso pratico: questi strumenti sono di terze parti, non ufficiali Anthropic. Prima di installarli su una macchina aziendale conviene verificare cosa leggono esattamente (in genere solo i file JSONL locali, senza inviare nulla al di fuori della macchina) e valutarli come faresti con qualunque altra dipendenza open source nel tuo stack, controllando manutenzione, popolarità e codice sorgente.

Per un piccolo team senza budget enterprise, un buon compromesso è combinare più strumenti per rispondere a domande diverse: /cost e /context per il controllo immediato in sessione, ccusage per le tendenze storiche e il confronto tra progetti, e il Claude Code Usage Monitor per l’allarme in tempo reale quando ci si avvicina al limite del piano. Nessuno di questi però sostituisce le Contribution metrics: senza un piano Team/Enterprise e l’integrazione GitHub, collegare l’uso di Claude Code alle pull request effettivamente consegnate resta un lavoro manuale. Ad esempio filtrando i commit con l’header Co-Authored-By che Claude Code aggiunge automaticamente, e incrociandolo a mano con il proprio tracker di progetto.

4. Monitoring avanzato: OpenTelemetry, Prometheus e Grafana

Passiamo a raccontare Come Misurare l’Utilità di Claude Code per i team più grandi. Le dashboard native rispondono bene a “quanto lo stiamo usando e quanto costa”, ma non bastano se serve visibilità in tempo reale, correlazione con altri sistemi, o alert automatici su una spesa anomala durante uno sprint. Qui entra in gioco OpenTelemetry (OTel), il protocollo di osservabilità che Claude Code supporta nativamente per esportare metriche, log ed eventi verso il proprio stack.

L’attivazione è una manciata di variabili d’ambiente:

# Abilita l'esportazione della telemetria
export CLAUDE_CODE_ENABLE_TELEMETRY=1

# Scegli gli exporter (metriche ed eventi)
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp

# Configura l'endpoint del collector
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

# In debug puoi ridurre gli intervalli di export
export OTEL_METRIC_EXPORT_INTERVAL=10000
export OTEL_LOGS_EXPORT_INTERVAL=5000

Da qui i dati possono finire su Prometheus + Grafana, su stack gestiti come SigNoz, o su piattaforme enterprise come Elastic. Le metriche coprono token consumati (input, output, cache), tempo attivo (i periodi di inattività, cioè l’idle time, vengono esclusi dal conteggio), latenza delle richieste API e decisioni di accept/reject sui tool. Gli eventi, invece, tracciano ogni prompt e ogni esecuzione di tool con un prompt.id condiviso, utile per ricostruire l’intera catena di un’azione, fondamentale se il tuo team di sicurezza deve rispondere alla domanda “cosa ha fatto l’agente esattamente, e perché”.

Un punto da tenere a mente: per default il contenuto dei prompt non viene esportato, solo la loro lunghezza. Va abilitato esplicitamente con OTEL_LOG_USER_PROMPTS=1, una scelta di design che protegge la privacy degli sviluppatori mentre offre comunque dati di adozione aggregati.

5. Le trappole delle metriche: cosa NON ti dicono i numeri

Qui arriva la parte che nessuna dashboard mostra da sola. La metrica più esposta di default, le righe di codice accettate, è anche la più fraintesa. Con un agente che lavora in autonomia, ogni riga prodotta durante una sessione viene contata come “accettata” anche se poi il team scarta l’intero output perché il piano era sbagliato: il contatore non si aggiusta mai al ribasso. Diversi team che hanno provato a costruire report interni sono arrivati alla stessa conclusione, orientandosi verso metriche basate sui commit effettivamente uniti piuttosto che sul volume di righe generate, proprio perché rappresentano lavoro realmente consegnato.

Anche il tasso di accettazione dei suggerimenti è ingannevole se preso da solo: uno sviluppatore che accetta il 70% delle proposte può avere lo stesso tempo di ciclo di uno che ne accetta il 15%. L’accettazione misura l’interazione con lo strumento, non se quell’interazione si traduca in consegne più veloci o più solide. Per questo Anthropic stessa consiglia di affiancare le metriche di contribuzione a indicatori di ingegneria già esistenti come le metriche DORA o la velocity di sprint, invece di trattarle come un numero isolato.

6. Caso pratico: misurare l’impatto su un team di 12 sviluppatori

Immagina un team di piattaforma, dodici sviluppatori, un backend Node/TypeScript e un backlog cronico di refactoring rimandato da mesi. Claude Code viene adottato in un mese di prova: nessuna dashboard, solo percezione soggettiva. Alla fine del mese, il team lead prova a fare un report per il suo direttore e si accorge di avere in mano solo aneddoti: “sembra che scriviamo test più in fretta”, senza un solo numero verificabile.

Nel mese due, il team abilita la dashboard su claude.ai/analytics/claude-code e collega l’integrazione GitHub. Dopo 24 ore iniziano ad arrivare i primi dati: sessioni giornaliere, tasso di accettazione, PR marcate claude-code-assisted. Il team lead nota subito un’anomalia: tre sviluppatori senior generano l’80% delle sessioni, mentre altri quattro non hanno praticamente adottato lo strumento. Non è un problema di licenze, è un problema di formazione: chi non lo usa non sa come scrivere un buon CLAUDE.md o come strutturare un prompt efficace.

Nel mese tre, per rispondere alla domanda del direttore su costi e ROI, il team aggiunge OpenTelemetry con export verso Grafana, così può incrociare il costo giornaliero in token con i giorni di sprint più intensi, e verificare che la spesa non stia scappando di mano durante le sessioni notturne di un singolo agente autonomo lasciato acceso. Il risultato finale non è “Claude Code ci fa risparmiare il 40%”: è un report con numeri difendibili, un piano di formazione per chi è rimasto indietro, e un alert configurato per non farsi sorprendere dalla fattura.

7. Implementazione: come collegare Claude Code al tuo stack di osservabilità

Per uno sviluppatore che deve mettere in piedi il monitoraggio, il percorso minimo è questo:

Passo 1: Analytics nativa (5 minuti, nessuna infrastruttura). Un Owner dell’organizzazione naviga su claude.ai/admin-settings/claude-code e abilita la funzione “Claude Code analytics”. Per le metriche di contribuzione serve anche installare la Claude GitHub App su github.com/apps/claude e attivare il toggle “GitHub analytics”. I primi dati arrivano entro 24 ore.

Passo 2: Accesso programmatico via API. Per chi vuole costruire report custom o esportare verso un data warehouse:

curl "https://api.anthropic.com/v1/organizations/usage_report/claude_code?starting_at=2026-07-01" \
  --header "anthropic-version: 2023-06-01" \
  --header "x-api-key: $ADMIN_API_KEY"

Passo 3: Osservabilità in tempo reale con OTel. Per team che vogliono correlare Claude Code con il resto dello stack di monitoring, si distribuisce la configurazione centralizzata via file di managed settings (utile con MDM come Jamf o Intune):

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://il-tuo-collector:443",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer il-tuo-token"
  }
}

Da qui i dati fluiscono in un Collector OpenTelemetry, poi verso Prometheus (metriche) e un backend di log come Loki o Elastic (eventi), con Grafana come livello di visualizzazione finale. Esistono stack già pronti e open source (docker-compose con collector, Prometheus e Grafana preconfigurati) che accorciano di parecchio il tempo di setup rispetto a costruire tutto da zero.

Passo 4: Collegare i dati al business. L’ultimo passo, spesso saltato, è portare questi numeri fuori dal mondo degli sviluppatori: un report mensile che incrocia sessioni, costo e PR consegnate con le metriche di sprint già usate dal project management, non una dashboard tecnica che solo il team platform sa leggere.

8. Cosa dicono davvero gli sviluppatori: un giro su Reddit

Fare una ricerca su r/ClaudeCode, r/ClaudeAI e community affini restituisce un quadro utile, e non sempre allineato al marketing ufficiale. Il sentiment più ricorrente riguarda proprio la metrica delle righe di codice: diversi sviluppatori la considerano fuorviante nell’era degli agenti autonomi, perché due persone che risolvono lo stesso task producono volumi di codice molto diversi, e uno strumento che scrive in autonomia gonfia il contatore anche quando buona parte del lavoro viene poi scartata. Il paragone con la celebre battuta di Bill Gates sul misurare il progresso di un aereo dal suo peso torna spesso nelle discussioni tecniche più critiche.

Un secondo filone riguarda i costi e i limiti di utilizzo: alcuni sviluppatori enterprise raccontano di consumare diversi miliardi di token al mese solo per generazione di codice, un volume a cui il prezzo per singolo seat perde di significato e conta solo la spesa API aggregata. Sul fronte individuale, invece, la discussione più accesa dell’ultimo anno ha riguardato l’introduzione di tetti settimanali di utilizzo oltre alle finestre di reset di 5 ore, con molti abbonati ai piani più costosi che segnalavano di raggiungere il limite prima della fine della settimana lavorativa.

Infine, un tema più maturo emerge dalle community tecniche più orientate all’ingegneria: la preferenza per metriche basate sui commit realmente uniti, spesso tracciati tramite l’header Co-Authored-By che Claude Code aggiunge automaticamente ai commit, invece che sulle righe generate, proprio perché più difficili da gonfiare artificialmente e più vicine a “cosa è stato davvero consegnato”.

9. Conclusioni: governare la complessità nascosta

Misurare l’utilità di Claude Code non è installare una dashboard e leggere un numero verde. È costruire, strato dopo strato, una pipeline di dati che va dalla singola sessione di uno sviluppatore fino al report che finisce sul tavolo di chi decide il budget, passando per scelte tecniche non banali su cosa esportare, come attribuire il codice, e come evitare che un dato aggregato racconti una storia sbagliata.

Ogni strumento AI che entra in produzione porta con sé questo tipo di complessità nascosta: sembra semplice dall’esterno (“basta installarlo e usarlo”), ma governarlo bene,capirne le metriche, i limiti di attribuzione, le implicazioni di privacy, i costi reali, richiede competenze che raramente un team acquisisce da solo lavorando di fretta tra uno sprint e l’altro. È la differenza tra “lo usiamo” e “sappiamo cosa ci sta restituendo”.

Vuoi che il tuo team misuri davvero l’impatto di Claude Code, non solo che lo “senta”?

Il Corso Claude Code per Sviluppatori di Innovaformazione è pensato proprio per portare i team IT aziendali oltre l’uso da principianti: prompting efficace, governance dello strumento, e come visto in questo articolo, impostazione (su richiesta) corretta di analytics e monitoraggio per misurare l’impatto reale sul progetto.

Il corso è attivato su richiesta, con calendario da concordare e preventivo dedicato sulle esigenze della tua azienda. Innovaformazione può inoltre seguirti nella costruzione del piano formativo finanziato, ad esempio tramite Fondimpresa o altri fondi interprofessionali dedicati alla formazione in ambito AI.

• Scopri il corso Claude Code per Sviluppatori

Contatti

📧 info@innovaformazione.net 📞 347 1012275 — Dario Carrassi

(fonte) (fonte) (fonte) (fonte)