Alcuni ricercatori di Microsoft, negli Stati Uniti, hanno pubblicato uno studio sull’uso degli strumenti di programmazione basati sull’IA che funzionano da riga di comando e sui loro effetti sulla produttività. La ricerca ha coinvolto decine di migliaia di ingegneri del software dell’azienda e ha preso in esame Claude Code di Anthropic e Copilot CLI di GitHub. Lo studio è durato circa quattro mesi, dal 5 gennaio al 29 aprile 2026. Secondo i risultati, nella prima settimana dall’introduzione gli ingegneri che hanno usato gli strumenti hanno registrato in media il 24% di pull request integrate in più rispetto a chi non li ha utilizzati.
Distribuire gli strumenti non basta: il primo passo parte dal collega accanto
Molti dirigenti e manager potrebbero immaginare che, una volta messi a disposizione di tutta l’azienda, gli strumenti di IA vengano usati da tutti già dal giorno successivo. Lo studio, però, mostra che a determinare se qualcuno li prova per la prima volta sono i rapporti con i colleghi, più delle spiegazioni sulle funzionalità o degli annunci.
La probabilità che una persona iniziasse a usare lo strumento aumentava se lo utilizzavano i colleghi con cui condivideva abitualmente il codice o il suo superiore diretto. I numeri sono specifici. Quando, nelle due settimane precedenti, li aveva usati oltre un quarto dei colleghi che condividevano il capo del proprio capo, le odds di provare lo strumento aumentavano fino al 216%. L’aumento era dell’82% se lo usava il superiore diretto e del 54% quando lo utilizzava oltre un quarto delle persone con cui si facevano abitualmente revisioni del codice.
L’aumento delle odds e l’aumento della «probabilità» non sono la stessa cosa
È importante chiarire il significato della parola «odds». Le odds esprimono la probabilità che un evento si verifichi in rapporto a quella che non si verifichi. Un aumento del 216% può far pensare che il numero di persone che usa lo strumento sia più che triplicato, ma non significa che la quota di utilizzatori sia cresciuta del 216%. Quando il tasso di utilizzo iniziale è basso, le differenze possono apparire più ampie; l’aumento effettivo degli utenti è inferiore a quanto suggerisca quel dato.
Resta comunque chiaro che il comportamento di superiori e colleghi può dare una spinta. Spesso si comincia a usare un nuovo strumento non leggendo le istruzioni, ma pensando: «Se lo usa quella persona, proverò anch’io». A mio avviso, è una dinamica riconoscibile in molti luoghi di lavoro, non solo nei team di sviluppo. Un superiore che prova per primo lo strumento e ne mostra l’uso durante una revisione potrebbe ottenere più risultati, con questo gesto semplice, che con i materiali di formazione.
A decidere se si continua a usarli è il flusso di lavoro quotidiano
Che chi prova lo strumento continui poi a usarlo è un’altra questione. Dallo studio emerge che l’uso continuativo era correlato al volume abituale di attività di programmazione. Gli ingegneri più impegnati, che scrivono molto codice e inviano spesso pull request, tendevano a rendersi conto più facilmente dei benefici dell’IA e a integrare stabilmente lo strumento nel proprio lavoro.
Una pull request è una richiesta di integrare nel progetto principale il codice modificato. Chi ne invia spesso è anche una persona che può affidare all’IA una quantità maggiore di attività. Più si lavora direttamente sul codice, più è facile percepire l’effetto dello strumento.
Un ambiente già familiare può diventare un ostacolo all’adozione di un nuovo strumento
Dallo studio è emerso anche che chi già utilizzava strumenti di IA esistenti in un altro ambiente di sviluppo provava i nuovi strumenti, ma tendeva meno a usarli con continuità. È possibile che molte persone si trovino più a proprio agio nell’ambiente a cui sono abituate.
È un po’ come passare a un nuovo smartphone. Anche se le funzionalità sono migliori, quando ci si è abituati alla disposizione delle app e alle modalità d’uso, viene voglia di tornare al vecchio dispositivo. Chi introduce un nuovo strumento di IA dovrebbe quindi considerare non solo le prestazioni, ma anche come inserirlo nel flusso di lavoro che gli utenti hanno già costruito.
Come interpretare l’aumento del 24% delle pull request
L’impatto sulla produttività è stato misurato contando le pull request integrate, usate come indicatore del numero di attività completate. Nella prima settimana dall’introduzione, gli ingegneri che hanno usato gli strumenti ne hanno registrate in media il 24% in più rispetto a chi non li ha utilizzati. Secondo quanto riportato, il risultato non era un effetto temporaneo dell’entusiasmo iniziale, ma è rimasto stabile per tutti i quattro mesi dello studio.
La produttività in questione è però misurata con un solo indicatore: il numero di pull request. Il dato non dimostra che siano migliorati nella stessa proporzione la qualità del codice, il tempo necessario per ciascuna pull request o il carico di lavoro del team. È bene distinguere l’aumento del numero di richieste dalla sensazione che il lavoro nel suo complesso sia diventato più facile.
Claude Code: +11,4%; Copilot CLI: +24,9%
Se si guardano i singoli strumenti, il numero di pull request è aumentato dell’11,4% per gli utenti di Claude Code e del 24,9% per quelli di Copilot CLI, rispetto alle settimane in cui non li utilizzavano. La differenza è circa doppia, ma sarebbe affrettato interpretare questi dati come una misura diretta della superiorità di uno strumento sull’altro. Copilot CLI è fornito da GitHub, società controllata da Microsoft, e i contesti d’uso interni e le tipologie di utenti potrebbero non essere uguali per i due strumenti.
Eppure sono pochi gli studi che, per quattro mesi, abbiano seguito sia la diffusione dell’uso sia i risultati in contesti di sviluppo reali su scala di decine di migliaia di persone. Mentre il dibattito sulla programmazione con l’IA tende a concentrarsi su «quale modello sia più intelligente», questi risultati mostrano la realtà dell’adozione: chi comincia a usare questi strumenti e chi continua a farlo. Forse stiamo entrando in un’epoca in cui, tanto quanto la scelta degli strumenti, a determinare i risultati è la capacità di progettare il modo in cui si diffondono sul posto di lavoro.
コメント