TL;DR: un agente AI di coding non si valuta contando prompt, token o righe generate. Serve un pilot con una baseline, un gruppo ristretto di persone, compiti reali e quattro famiglie di metriche: adozione, flusso di consegna, qualità e costo. Uno studio Microsoft pubblicato il 1° luglio 2026 ha rilevato circa il 24% di pull request unite in più tra gli adottanti, ma gli stessi autori chiariscono che una pull request non equivale al valore prodotto. Per una PMI la domanda corretta è più severa: l’agente riduce il costo di una modifica verificata senza aumentare rework e incidenti?

Gli agenti di coding sono usciti dalla fase della demo. Possono leggere un repository, modificare più file, eseguire test e preparare una pull request. Il problema, per un’azienda, non è più capire se riescono a scrivere codice. È capire se il loro uso migliora il lavoro del team oppure sposta il tempo dalla scrittura alla revisione.

La risposta non arriva da una classifica dei modelli. Arriva da un esperimento progettato bene. In questa guida propongo un pilot di 30 giorni per un team piccolo: abbastanza lungo da vedere se l’uso continua dopo l’entusiasmo iniziale, abbastanza corto da fermare costi e abitudini sbagliate.

Cosa ci dice il caso Microsoft, e cosa non ci dice

Lo studio sul rollout di Claude Code e GitHub Copilot CLI in Microsoft ha seguito decine di migliaia di ingegneri nei primi mesi del 2026. Gli autori separano due domande che spesso vengono confuse: chi prova lo strumento e chi continua a usarlo. Definiscono la retention iniziale come uso in almeno 5 dei 14 giorni successivi al primo accesso.

Nel gruppo analizzato, gli adottanti hanno unito circa il 24% di pull request in più rispetto alla stima controfattuale. L’intervallo osservato copre circa quattro mesi e l’aumento non risulta un semplice picco della prima settimana. Il dato è interessante perché misura attività reale, non soltanto la produttività percepita in un questionario.

Va letto con due cautele. La prima è dichiarata dagli autori: una pull request unita è un proxy di output, non una misura del valore consegnato. La seconda è il contesto. Lo studio riguarda Microsoft, un’organizzazione grande, con processi e strumenti interni che una PMI non replica. Gli autori lavorano inoltre per Microsoft, che possiede GitHub e vende Copilot; indicano esplicitamente questo possibile limite nell’interpretazione.

La lezione utile non è quindi “compra un agente e otterrai il 24%”. È un’altra: adozione, retention e impatto sono fenomeni distinti. Se li metti nello stesso numero, non capisci perché un pilot funziona o fallisce.

Definisci il perimetro prima di scegliere il tool

Un pilot serio parte dai lavori ammessi. Per un team WordPress sceglierei tre categorie con rischio controllabile:

  • test automatici, documentazione tecnica e piccoli refactoring senza modifica del comportamento;
  • correzioni su plugin o tema in un ambiente di staging, con ticket e criteri di accettazione già scritti;
  • analisi di log, errori PHP e regressioni frontend, con output iniziale in forma di diagnosi o patch da rivedere.

Escluderei invece deploy in produzione, modifiche a utenti e ruoli, lettura di file con credenziali, aggiornamenti massivi del database e operazioni senza rollback. Il perimetro tecnico deve essere applicato da permessi, branch protection e sandbox. Scrivere “non toccare la produzione” nel prompt non è un controllo.

Questo principio è lo stesso che uso per le automazioni AI read-only in WordPress: prima dimostri che il sistema sa lavorare dentro un confine stretto, poi allarghi una capacità alla volta.

Costruisci la baseline con dati che hai già

Prima del giorno uno recupera almeno quattro settimane di dati dal sistema di versionamento, dalla CI e dal ticketing. Non servono dashboard elaborate. Servono definizioni stabili.

Per il flusso di consegna, DORA distingue throughput e instabilità. Le metriche DORA includono lead time della modifica, frequenza di deploy, tempo di recupero da un deploy fallito, change fail rate e deployment rework rate. In un pilot piccolo puoi usarne un sottoinsieme, purché non misuri soltanto la velocità.

La baseline minima che adotterei contiene:

  • tempo mediano da ticket pronto a pull request pronta per la review;
  • tempo mediano dalla prima review al merge;
  • percentuale di pull request che richiedono più di un ciclo di correzioni sostanziali;
  • bug o rollback collegati alle modifiche entro una finestra concordata;
  • ore di revisione umana e costo degli strumenti per modifica accettata.

Non cambiare definizioni durante il test. Se prima conti una patch CSS come pull request e dopo raggruppi cinque patch in un solo ticket, il confronto perde senso.

Il protocollo di 30 giorni

Giorni 1-3: setup e prova a vuoto

Configura repository, permessi e logging. L’agente lavora su un branch dedicato, non può approvare o unire il proprio codice e non dispone di credenziali di produzione. I test obbligatori, il lint e l’analisi statica devono scattare anche sulle sue modifiche.

La documentazione di GitHub sui rischi del cloud agent applica controlli utili come branch limitato, protezioni del repository, log di sessione e review umana prima del merge. Non serve usare lo stesso prodotto per copiare il modello di controllo.

Esegui due o tre task già conclusi, senza usare l’output in produzione. Conosci il risultato corretto e puoi verificare se l’agente legge le istruzioni del repository, esegue i test giusti e produce una diff comprensibile.

Giorni 4-10: due persone, compiti ripetibili

Scegli due utilizzatori che lavorano già con continuità sul codice. Lo studio Microsoft ha trovato che l’uso dei colleghi è associato alla prima adozione, mentre la retention è legata più al comportamento di lavoro che alle caratteristiche anagrafiche o al ruolo. Per un team piccolo significa che una demo condivisa e un esempio riuscito valgono più di una licenza distribuita a tutti.

Assegna task simili per dimensione e rischio: aggiungere test a una funzione esistente, correggere warning WPCS, aggiornare documentazione collegata a una patch, preparare una diagnosi riproducibile. Registra dove interviene la persona: chiarimenti iniziali, correzioni del piano, errori nei comandi, test mancanti e modifiche manuali finali.

Giorni 11-20: lavoro reale con controllo del carico

Estendi il pilot soltanto se le patch dei primi giorni superano i controlli. Aggiungi task reali, ma mantieni un limite al numero di lavori concorrenti. Tre agenti attivi non rendono più veloce un reviewer che può controllare una sola diff alla volta.

Qui emerge il collo di bottiglia. Se il tempo per aprire una pull request scende ma il tempo di review sale, l’agente ha accelerato la produzione di codice e rallentato la consegna. È un risultato, non un fallimento del test: hai individuato il punto da correggere prima di scalare.

Giorni 21-30: confronto e decisione

Nell’ultima fase confronta i dati con la baseline e con task simili eseguiti senza agente. Non cercare una precisione statistica che un team di quattro persone non può offrire. Cerca segnali coerenti: lead time più basso, review stabile, meno lavoro ripetitivo, nessun aumento di bug e costo prevedibile.

Raccogli anche una breve nota qualitativa per ogni utilizzatore: quali task affiderebbe di nuovo all’agente, quali no e perché. Le osservazioni servono a spiegare i numeri, non a sostituirli.

La scorecard: quattro famiglie di metriche

1. Adozione e retention

Conta quante persone abilitate provano lo strumento e quante lo usano ancora dopo due settimane. Mantieni separate le due percentuali. Un picco di accessi dopo la demo segnala curiosità; l’uso ripetuto su task reali segnala utilità.

2. Flusso di consegna

Misura lead time, tempo di review e modifiche effettivamente unite. Non premiare il numero di branch o pull request aperte. Un agente può moltiplicare output intermedi senza aumentare ciò che arriva in produzione.

3. Qualità e rework

Registra test falliti, finding di sicurezza, cicli di correzione, rollback e bug successivi. Il NIST IR 8397 indica tra le verifiche minime threat modeling, test automatici, scansione statica, ricerca di segreti, test black-box e code review. L’agente non sostituisce questi controlli: deve attraversarli.

4. Costo per modifica verificata

Somma licenze, consumo variabile, minuti CI e tempo umano di supervisione. Dividi il totale per le modifiche accettate che hanno superato review e test. Il costo per token è utile per il budget del fornitore; il costo per modifica verificata è utile per decidere se il processo conviene.

Un esempio per un’agenzia WordPress

Immagina un’agenzia con tre sviluppatori e una persona che fa review e delivery. Il pilot copre un plugin interno e un tema custom in staging. Ogni ticket deve avere file coinvolti, comportamento atteso, test da eseguire e azioni vietate.

L’agente può preparare test PHPUnit, correggere escaping e sanitizzazione, individuare query non preparate, aggiornare commenti e documentazione, oppure proporre una patch CSS verificata su breakpoint definiti. Non può caricare ZIP, cambiare plugin sul sito live, leggere .env o usare credenziali cliente.

Per i primi dieci giorni le patch restano piccole. Dal giorno undici entra un task completo, per esempio correggere un errore di validazione in un form e aggiungere il test di regressione. Il successo non è la patch generata. È una patch unita, verificata e distribuita senza rework imprevisto.

Se vuoi governare anche la scelta tra lavoro umano e agente, il criterio del task crossover nelle PMI aiuta a capire quando il costo di preparazione e controllo supera il vantaggio dell’automazione.

Tre esiti possibili: scala, correggi o ferma

Scala se lead time e lavoro ripetitivo diminuiscono, qualità e rework restano almeno stabili, il costo è sostenibile e il team continua a usare lo strumento senza pressione.

Correggi il processo se le patch arrivano più in fretta ma si accumulano in review, le istruzioni del repository sono incomplete o i test non coprono i rischi reali. In questo caso non serve cambiare subito modello. Serve ridurre il perimetro, migliorare i criteri di accettazione e togliere attrito al controllo.

Ferma se aumentano bug, rollback, esposizione di dati, interventi manuali o costo per modifica verificata. Un pilot che si conclude con uno stop ha comunque prodotto valore: evita un rollout esteso basato su sensazioni.

La mia take: misura il costo della fiducia

La metrica più onesta non è quante righe scrive l’agente. È quanto costa rendere affidabile una sua modifica. Dentro quel costo ci sono contesto, review, test, correzioni, compute e responsabilità.

Se il team genera il 20% di pull request in più ma raddoppia il tempo di review, non hai guadagnato capacità. Hai creato una coda. Se invece consegna lo stesso numero di modifiche con meno lavoro ripetitivo e qualità stabile, il pilot può essere riuscito anche senza un grafico spettacolare.

Gli agenti di coding vanno trattati come una modifica al sistema di delivery, non come un abbonamento personale. Baseline, perimetro, controlli e una decisione scritta al giorno 30 trasformano una prova del tool in un esperimento aziendale.

Fonti