Statistiche sugli assistenti di codifica AI.

Gli assistenti di codifica AI non sono più un esperimento secondario per sviluppatori curiosi. Entro il 2026, la domanda migliore è che tipo di adozione si intende: utilizzo del sondaggio, abitudine quotidiana, posti a pagamento, implementazione aziendale, suggerimenti di codice accettati, prestazioni di benchmark o codice revisionato che viene effettivamente spedito.

Questa distinzione è importante perché i numeri principali sono grandi. Stack Overflow afferma che l’84% degli intervistati utilizza o prevede di utilizzare strumenti AI nel proprio processo di sviluppo, mentre il 50,6% degli sviluppatori professionisti li utilizza quotidianamente. JetBrains afferma che il 90% degli sviluppatori professionisti nel suo sondaggio AI Pulse di gennaio 2026 ha utilizzato regolarmente almeno uno strumento AI al lavoro e il 74% ha adottato strumenti di sviluppo AI specializzati. Microsoft afferma che GitHub Copilot ha oltre 4,7 milioni di abbonati a pagamento ed è utilizzato da quasi 140.000 organizzazioni.

Ma i grandi numeri possono ingannare quando vengono inseriti nel contenitore sbagliato. Un punteggio di benchmark non è un conteggio di utenti. Un abbonato a pagamento non è uno sviluppatore attivo quotidianamente. Una riga di codice generata non è un software revisionato, sicuro e distribuito. La vera storia del 2026 è che gli strumenti di codifica AI sono mainstream, commerciali e sempre più agentici, mentre il duro lavoro si è spostato a valle nella revisione, nella governance, nella tracciabilità e nella misurazione se i team spediscono software migliore.

Assistenti di codifica AI a colpo d’occhio

I numeri principali utilizzano denominatori diversi, quindi leggili come segnali separati di sondaggio, commerciali, di capacità e di governance, piuttosto che come un’unica cifra.

Leggere attentamente i numeri di adozione

Il modo più sicuro per leggere le statistiche sugli assistenti di codifica AI è come una scala. In cima ci sono ampi segnali di sondaggio: se gli sviluppatori hanno provato strumenti AI, li usano quotidianamente o intendono usarli presto. La cifra dell’84% “usa o intende usare” di Stack Overflow è un forte segnale di adozione, ma non è la stessa metrica della sua cifra del 50,6% di uso quotidiano tra gli sviluppatori professionisti.

Il gradino successivo è l’utilizzo specifico del lavoro. L’AI Pulse di JetBrains di gennaio 2026 è utile perché separa gli strumenti AI generici dagli strumenti di sviluppo specializzati. Riporta il 90% di utilizzo regolare di strumenti AI al lavoro per la codifica e lo sviluppo, e il 74% di adozione di strumenti di sviluppo AI specializzati. Questa è ancora una prova da sondaggio, ma è più vicina al flusso di lavoro professionale rispetto a un sondaggio generico “gli sviluppatori amano l’AI”.

La scala commerciale è un gradino diverso. Microsoft fornisce numeri pubblici per gli utenti, gli abbonati a pagamento e le organizzazioni di GitHub Copilot: oltre 26 milioni di utenti, oltre 4,7 milioni di abbonati a pagamento e quasi 140.000 organizzazioni. Questi sono tra i più forti indicatori pubblici per un assistente di codifica AI nominato, ma ognuno risponde a una domanda diversa.

Sotto ci sono le metriche di interazione con il prodotto. La documentazione sulle metriche di utilizzo di GitHub definisce un utente Copilot attivo in base al conteggio delle interazioni avviate dall’utente e definisce il tasso di accettazione del completamento del codice come attività di codice accettato divisa per attività di generazione. Queste definizioni fermano un errore comune: un suggerimento accettato non è la stessa cosa di una pull request unita, e una pull request unita non è la stessa cosa di un software di produzione affidabile.

I benchmark si trovano su un ramo separato. Le 500 istanze convalidate da umani di SWE-bench Verified aiutano a confrontare gli agenti di codifica su attività di ingegneria del software, e la più ampia famiglia SWE-bench è utile per comprendere i progressi delle capacità. Ma i tassi di superamento dei benchmark non sono conteggi di utenti, conteggi di clienti o ROI aziendale.

Adozione da parte degli sviluppatori: l’AI è diventata una parte normale del flusso di lavoro

Le prove più solide dei sondaggi puntano nella stessa direzione: l’assistenza AI è ora normale nello sviluppo software. Il sondaggio 2025 di Stack Overflow riporta il 47,1% di utilizzo quotidiano di strumenti AI tra tutti gli intervistati, il 17,7% settimanale, il 13,7% mensile o infrequente, il 5,3% che prevede di utilizzare presto e il 16,2% senza alcun piano di utilizzo. Tra gli sviluppatori professionisti, la cifra di utilizzo quotidiano sale al 50,6%.

JetBrains racconta una storia simile con un design di sondaggio diverso. Il suo rapporto Developer Ecosystem 2025 si basa su 24.534 sviluppatori dopo la pulizia dei dati, con ponderazione per geografia, impiego, lingue e utilizzo del prodotto, oltre a un’esplicita avvertenza che gli utenti JetBrains potrebbero essere più propensi a rispondere. In questo contesto, JetBrains riporta l’85% di utilizzo regolare dell’AI per la codifica e il 62% di dipendenza da almeno un assistente di codifica AI, agente o editor di codice.

L’aggiornamento AI Pulse di gennaio 2026 rende la mappa di mercato più granulare. Ha coperto oltre 10.000 sviluppatori professionisti in tutto il mondo, localizzato in otto lingue, ponderato per allinearsi alle distribuzioni di Developer Ecosystem 2025. In quel sondaggio, il 90% ha utilizzato regolarmente almeno uno strumento AI al lavoro, il 74% ha adottato strumenti di sviluppo AI specializzati, GitHub Copilot è stato utilizzato al lavoro dal 29% e Cursor e Claude Code sono stati utilizzati ciascuno dal 18%.

DORA aggiunge una lente sull’organizzazione tecnologica. Il riepilogo DORA 2025 di Google afferma che il rapporto si è basato su quasi 5.000 professionisti della tecnologia a livello globale, con il 90% che ha segnalato l’uso dell’AI al lavoro e una media di due ore al giorno trascorse a lavorare con l’AI. DORA afferma anche che il 65% si affida molto all’AI per lo sviluppo software e oltre l’80% segnala guadagni di produttività.

L’avvertenza è che queste non sono popolazioni identiche. Stack Overflow intervista una vasta comunità di sviluppatori. JetBrains intervista sviluppatori e fornisce dettagli sulla ponderazione. DORA intervista professionisti della tecnologia e studia i sistemi di team, non solo gli assistenti di codifica. Il fatto che tutti e tre indichino un’elevata adozione è significativo; il fatto che utilizzino denominatori diversi è il motivo per cui non dovrebbero essere collassati in un unico numero.

GitHub Copilot è il più chiaro ancoraggio di adozione a pagamento

GitHub Copilot non è l’intero mercato degli assistenti di codifica AI, ma è l’ancoraggio commerciale meglio documentato. Microsoft ha dichiarato nel FY26 Q1 che GitHub Copilot aveva “ora oltre 26 milioni di utenti” e che GitHub stesso aveva oltre 180 milioni di sviluppatori. La stessa chiamata ha affermato che l’80% dei nuovi sviluppatori su GitHub inizia con Copilot entro la prima settimana e che oltre 500 milioni di pull request erano state unite nell’anno precedente.

Il numero a pagamento è più chiaro del numero di utenti. Nel FY26 Q2, Microsoft ha dichiarato che Copilot aveva oltre 4,7 milioni di abbonati a pagamento, in aumento del 75% anno su anno, e che gli abbonamenti Copilot Pro+ per sviluppatori individuali sono aumentati del 77% trimestre su trimestre. Microsoft ha anche citato Siemens che ha adottato GitHub in modo ampio dopo un’implementazione di Copilot per oltre 30.000 sviluppatori, un esempio aziendale concreto che non dovrebbe essere generalizzato a ogni cliente.

Entro il FY26 Q3, Microsoft ha dichiarato che quasi 140.000 organizzazioni utilizzano GitHub Copilot, gli abbonati aziendali erano quasi triplicati anno su anno, la maggior parte degli utenti utilizza più modelli e l’utilizzo di Copilot CLI è quasi raddoppiato mese su mese. Microsoft ha anche dichiarato che stava spostando Copilot verso una tariffazione basata sull’utilizzo per allineare i prezzi all’utilizzo e ai costi.

Anche il prodotto stesso sta cambiando. GitHub è andato oltre l’autocompletamento e la chat in un agente di codifica che lavora da problemi e rami, e Agent HQ, che GitHub posiziona come uno strato organizzativo per gli agenti di codifica. Ha anche aggiunto la scelta del modello tra i modelli OpenAI, Anthropic e Google. Nel 2026, “assistente di codifica AI” significa sempre più un ecosistema di modelli, politiche, agenti e superfici di revisione — non solo una casella di autocompletamento.

Il mercato è più ampio di Copilot

La mappa di mercato più sicura è per superficie di flusso di lavoro, non per quota di mercato inventata. GitHub Copilot è il più grande ancoraggio a pagamento documentato pubblicamente, ma il sondaggio 2026 di JetBrains mostra sviluppatori che utilizzano uno stack multi-strumento: Copilot aveva il 76% di consapevolezza e il 29% di adozione sul lavoro; Cursor aveva il 69% di consapevolezza e il 18% di adozione; Claude Code ha raggiunto il 18% di adozione (24% negli Stati Uniti e in Canada); OpenAI Codex aveva il 27% di consapevolezza e il 3% di adozione all’interno della finestra del sondaggio; e Google Antigravity ha raggiunto il 6% dopo il lancio a novembre.

Quel sondaggio mostra anche che le interfacce di chat generiche contano ancora: il 28% degli sviluppatori usa ChatGPT al lavoro per la codifica, l’8% usa Gemini e il 7% usa il chatbot di Claude. La sezione degli strumenti agente di Stack Overflow mostra in modo simile ChatGPT e GitHub Copilot come strumenti comuni pronti all’uso tra gli intervistati che usano o costruiscono agenti, con Claude Code, Google Gemini, Microsoft Copilot, Replit, Tabnine, Amazon CodeWhisperer, Cody e Devin nella coda lunga.

Per i fondatori, questa mappa è più utile di una classifica falsa. Vendere “un altro assistente di codifica” è una posizione debole a meno che il prodotto non possieda uno strato specifico: contesto del repository, revisione della sicurezza, generazione di test, migrazione, ricerca di codice, onboarding della codebase, automazione del terminale, esecuzione cloud, policy, valutazioni, fatturazione o orchestrazione degli agenti.

Produttività: la creazione di codice più veloce è reale, ma non è un ROI automatico

Lo studio sulla produttività positiva più citato è l’esperimento controllato di GitHub sulle attività di Copilot. Gli sviluppatori che utilizzano Copilot hanno completato un’attività di server HTTP JavaScript il 55% più velocemente, impiegando in media 1 ora e 11 minuti contro 2 ore e 41 minuti senza Copilot. Questo è un risultato reale, ma è un’unica impostazione di attività — supporta “Copilot può accelerare determinate attività di codifica”, non “ogni sviluppatore è il 55% più veloce”.

Le prove dei sondaggi mostrano che gli sviluppatori sentono il beneficio. JetBrains afferma che quasi nove sviluppatori su dieci che usano l’AI per la codifica risparmiano almeno un’ora a settimana, e uno su cinque risparmia otto ore o più. DORA afferma che oltre l’80% crede che l’AI abbia aumentato la produttività e il 59% riporta un’influenza positiva sulla qualità del codice. GitLab afferma che il 78% riporta un output di codice più veloce e il 73% afferma che la qualità complessiva del codice è migliorata dall’adozione di strumenti di codifica AI.

Il problema non è se l’AI può far apparire il codice più velocemente. Può. Il problema è se la creazione di codice più veloce si traduce in una consegna più veloce e sicura. L’annuncio DORA 2025 afferma che l’adozione dell’AI ha una relazione positiva con il throughput e le prestazioni del prodotto, ma una relazione negativa con la stabilità della consegna del software. L’inquadramento più ampio di DORA è che l’AI amplifica il sistema che un team ha già: i team forti possono trarne beneficio, mentre i cicli di feedback deboli e i sistemi strettamente accoppiati vengono esposti.

Il sondaggio 2026 di GitLab rende concreto il collo di bottiglia a valle: l’85% concorda che l’AI ha spostato il collo di bottiglia dalla scrittura del codice alla sua revisione e convalida, l’84% concorda che la sfida più grande è la governance del codice generato dall’AI dopo la sua creazione e l’82% afferma che il codice generato dall’AI rischia un nuovo debito tecnico che la loro organizzazione non è preparata a gestire. Il precedente sondaggio di GitLab ha anche affermato che i team perdono 7 ore a settimana per membro a causa di processi inefficienti, il 49% utilizza più di cinque strumenti AI e solo il 37% si fiderebbe dell’AI per gestire le attività quotidiane senza revisione umana.

METR è il controesempio più netto perché ha misurato attività reali piuttosto che auto-dichiarazioni. Nel suo studio randomizzato controllato di inizio 2025, 16 sviluppatori open-source esperti hanno lavorato su 246 attività in repository maturi. Si aspettavano che l’AI riducesse il tempo di completamento del 24%, e in seguito credevano ancora che l’AI li avesse accelerati del 20% — ma il tempo di completamento misurato era il 19% più lungo quando l’AI era consentita (METR arXiv).

Ciò non dimostra che gli strumenti di codifica AI siano cattivi. La stessa pagina di METR ora avverte che il risultato di inizio 2025 è obsoleto, e il suo aggiornamento 2026 afferma che i dati più recenti sono difficili da interpretare perché gli sviluppatori optano sempre più spesso per lavori non consentiti dall’AI, scelgono le attività in modo diverso e utilizzano più agenti contemporaneamente. La lettura corretta è sfumata: la produttività dell’AI dipende dal tipo di attività, dalla familiarità con la codebase, dalla barra di qualità, dal carico di revisione e da quanto del flusso di lavoro attorno alla generazione di codice è stato riprogettato.

Offerta di codice, pull request e benchmark

Gli assistenti di codifica AI stanno cambiando l’offerta di codice. Microsoft ha dichiarato che decine di migliaia di sviluppatori AMD utilizzano Copilot e accettano centinaia di migliaia di righe di suggerimenti di codice ogni mese. La documentazione sulle metriche di utilizzo di GitHub definisce il tasso di accettazione del completamento del codice come attività di codice accettato divisa per attività di codice generato. Questi sono preziosi per i dashboard di implementazione interna, ma sono ancora metriche di interazione.

Lo strato successivo è il flusso di lavoro delle pull request. Microsoft ha dichiarato che oltre 500 milioni di pull request sono state unite su GitHub nell’anno precedente, nella stessa discussione sugli agenti di codifica AI e sull’adozione di Copilot. GitHub ha lanciato un agente di codifica Copilot che lavora da problemi e rami, e Agent HQ per la gestione di più agenti di codifica. Questo avvicina l’assistenza AI al sistema di consegna, ma non elimina la responsabilità di revisione.

I benchmark mostrano perché tutti stanno investendo negli agenti di codifica. SWE-bench Verified contiene 500 istanze convalidate da umani, progettate come un set di valutazione più affidabile per agenti di codifica e modelli linguistici. HumanEval rimane importante come benchmark di generazione di codice più vecchio, ma è un formato storico, non un proxy completo per il lavoro di software aziendale. La nota di OpenAI sul non utilizzare più SWE-bench Verified come valutazione primaria è un’utile cautela: i benchmark possono saturare o perdere potere discriminante man mano che i modelli e gli scaffold migliorano.

Fiducia, sicurezza e governance sono il nuovo centro del mercato

I numeri di adozione sono alti, ma la fiducia no. Il comunicato stampa 2025 di Stack Overflow afferma che il 46% degli sviluppatori non si fida dell’accuratezza dell’output AI, in aumento dal 31% nel 2024. Il sondaggio dettagliato afferma che il 66% cita soluzioni AI che sono “quasi giuste, ma non del tutto”, e il 45,2% cita il debug del codice generato dall’AI come dispendioso in termini di tempo.

Per gli agenti AI, la preoccupazione è più acuta. Stack Overflow afferma che l’87% è preoccupato per l’accuratezza delle informazioni provenienti dagli agenti AI, e l’81% ha preoccupazioni sulla sicurezza e la privacy dei dati quando utilizza gli agenti. Il paradosso della fiducia di DORA punta nella stessa direzione: solo il 24% riporta molta o grande fiducia nell’AI, mentre il 30% riporta poca o nessuna fiducia.

La governance è dove questo diventa un problema aziendale. Il sondaggio 2026 di GitLab afferma che il 43% non riesce a distinguere in modo affidabile il codice generato dall’AI da quello scritto da umani nella propria codebase, il 92% segnala qualche sfida di governance e l’80% concorda che la propria organizzazione ha adottato strumenti AI più velocemente di quanto abbia sviluppato politiche. GitLab afferma anche che l’87% è fiducioso di poter determinare entro 24 ore se il codice generato dall’AI ha contribuito a un incidente di produzione — ma il 34% delle organizzazioni che hanno avuto un incidente nell’ultimo anno non è riuscito a fare tale determinazione.

Gli studi sulla sicurezza spiegano perché la revisione non può scomparire. “Asleep at the Keyboard?” è uno studio più vecchio sui rischi della generazione di codice in stile Copilot. “Do Users Write More Insecure Code with AI Assistants?” è un altro importante studio storico sul comportamento degli utenti con l’assistenza alla codifica AI. L’opera più recente di USENIX Security 2025 continua a esaminare come il codice generato dall’AI cambia il profilo di rischio. I tassi esatti nei documenti più vecchi non dovrebbero essere applicati ciecamente agli strumenti del 2026, ma la lezione duratura rimane: il codice generato necessita di provenienza, revisione, test, policy e scansione di sicurezza.

I fornitori stanno rispondendo passando dalla pura generazione ai controlli. GitHub sta costruendo dashboard di metriche, controlli aziendali, scelta del modello e Agent HQ. GitLab sta posizionando governance, tracciabilità e integrazione del ciclo di vita come lo strato successivo alla generazione di codice. JetBrains sta posizionando Air, Central, Junie e un’infrastruttura agentica aperta attorno all’orchestrazione, al contesto locale e alla scelta del modello.

Cosa significa questo per i leader dell’ingegneria e i fondatori

Per i leader dell’ingegneria, i numeri indicano un imbuto di implementazione. Inizia con l’accesso: chi può usare quali strumenti, con quali limiti di dati? Poi misura l’uso regolare: uso attivo quotidiano e settimanale, suggerimenti accettati, attività delegate, flussi di lavoro degli agenti. Poi passa ai risultati di consegna: tempo di ciclo delle pull request, tempo di revisione, qualità dei test, difetti sfuggiti, tasso di incidenti, soddisfazione degli sviluppatori e se l’AI cambia il collo di bottiglia.

Il dashboard sbagliato si ferma al volume del codice. La statistica di GitLab sul collo di bottiglia dell’85% di revisione e convalida avverte che una generazione più veloce può semplicemente spostare il lavoro a valle. L’inquadramento di DORA come “specchio e moltiplicatore” è la versione strategica: l’AI amplifica il sistema che la circonda. La difficoltà di misurazione di METR è la versione sperimentale: gli sviluppatori possono sentirsi più veloci anche quando un compito controllato dice il contrario.

Per i fondatori, il mercato è chiaramente reale, ma il posizionamento generico è debole. “Gli sviluppatori usano l’AI” non è più un elemento di differenziazione. I prodotti più forti si attaccano a un collo di bottiglia specifico: contesto della codebase, migrazione, test, revisione della sicurezza, aggiornamenti delle dipendenze, recupero della conoscenza, revisione delle PR, orchestrazione degli agenti, valutazioni, permessi o controllo dei costi. Le pagine ufficiali dei prodotti enfatizzano sempre più il packaging aziendale e il flusso di lavoro — piani GitHub Copilot e metriche, AWS Q Developer, Gemini Code Assist per le aziende, costi di Claude Code e licenze JetBrains AI — non solo il completamento del codice.

Per i team di approvvigionamento, i dati sconsigliano una classifica a strumento unico. GitHub Copilot ha l’ancoraggio di adozione a pagamento più forte divulgato, ma JetBrains mostra un ambiente multi-strumento, Stack Overflow mostra un ampio utilizzo di strumenti AI piuttosto che una quota specifica del fornitore, e GitLab mostra organizzazioni che già affrontano la proliferazione di strumenti. Un processo di acquisto realistico confronta l’adattamento all’IDE, l’accesso al repository, la scelta del modello, i controlli delle policy, l’auditabilità, la segnalazione dell’utilizzo, la conservazione dei dati, la revisione della sicurezza e se lo strumento supporta il percorso di revisione del codice esistente dell’azienda. I numeri di adozione dicono che c’è domanda; non dicono che ogni organizzazione dovrebbe standardizzare sulla stessa interfaccia.

I programmi più forti trattano l’adozione come un cambiamento ingegneristico gestito, non come un’implementazione di licenze software. Un team può implementare rapidamente le licenze e fallire comunque nel cambiare i risultati di consegna se gli sviluppatori utilizzano gli strumenti solo per frammenti isolati. Inizia con attività a basso rischio — documentazione, scaffolding di test, spiegazione del codice, refactoring semplici, strumenti interni — quindi passa a modifiche a rischio più elevato solo quando il team può osservare il tasso di accettazione, il carico di revisione, i risultati di sicurezza e l’impatto degli incidenti.

Trasformare questi numeri in decisioni

Tratta le statistiche più forti come un insieme di lenti, ognuna con il proprio ambito:

La conclusione duratura del 2026 è che gli assistenti di codifica AI sono mainstream, ma il mercato sta passando da “l’AI può scrivere codice?” a “i team possono gestire la consegna di software assistita dall’AI?”. I vincitori non saranno i team che generano più codice. Saranno i team che sanno quale codice proviene da dove, perché è cambiato, chi lo ha revisionato, quali test lo proteggono e se ha migliorato il prodotto senza aumentare il rischio nascosto.

Domande frequenti

Fonti e ulteriori letture