Programmare senza un assistente di intelligenza artificiale e' ormai l'eccezione. Secondo un'indagine recente condotta su oltre 800 ingegneri del software e professionisti DevOps, il 97% dichiara di aver usato strumenti di IA per scrivere codice sul lavoro. Il problema non e' piu' l'adozione, praticamente totale, ma il fatto che la maggior parte delle aziende lo faccia senza regole: meno di un team su tre ha una governance completa su come questi strumenti vengono utilizzati.
Quali strumenti dominano
Il mercato e' affollato ma con leader chiari. GitHub Copilot e Claude Code di Anthropic risultano i piu' diffusi, usati rispettivamente dall'83% e dal 63% dei team, e quasi tutti usano piu' di un assistente in parallelo. Quando si guarda allo strumento principale, Claude Code (28%) e Cursor (24%) insieme superano la meta' delle preferenze: un dato notevole per Claude Code, sul mercato da meno di un anno. La fotografia e' quella di uno stack a piu' strumenti, non di una scelta esclusiva.
La produttivita' c'e', ma dipende dalle regole
Sui benefici i numeri sono netti: il 92% dei team attribuisce agli assistenti rilasci piu' rapidi e in media gli strumenti restituiscono agli sviluppatori circa otto ore a settimana. Ma il guadagno non e' uniforme. Dove l'uso dell'IA e' pienamente governato, il 90% riporta un forte aumento di efficienza; la media generale scende al 58% e crolla al 44% nei team senza alcuna governance. La lezione e' controintuitiva: non basta adottare gli strumenti, serve regolarne l'uso per coglierne davvero i frutti.
Il rischio: codice veloce, controllo lento
Qui sta il punto dolente per la sicurezza. Solo circa un terzo delle organizzazioni dichiara di avere un approccio pienamente governato all'uso dell'IA nello sviluppo. Significa codice generato in fretta e in grande quantita', ma spesso senza policy chiare su revisione, tracciabilita' delle dipendenze e verifica delle vulnerabilita'. In un mondo in cui gli assistenti producono codice piu' velocemente di quanto i team riescano a revisionarlo, il divario di governance diventa una superficie d'attacco.
Codice generato e fiducia: il paradosso
C'e' un secondo dato che attraversa molte indagini del settore e che spiega l'urgenza della governance: gli sviluppatori usano gli assistenti ovunque, ma non si fidano ciecamente del codice che producono. La velocita' di generazione e' tale che il collo di bottiglia si sposta sulla revisione umana: serve qualcuno che legga, capisca e validi cio' che l'IA ha scritto, soprattutto quando l'assistente introduce librerie esterne, gestisce input non fidati o tocca componenti critici. Quando questa fase salta, il rischio non e' solo un bug, ma l'ingresso di dipendenze vulnerabili o di pattern insicuri riprodotti su larga scala.
E' il motivo per cui molte aziende stanno spostando l'attenzione dalla domanda "possiamo usare l'IA?" a quella "come la usiamo in sicurezza?". Le pratiche che emergono come piu' efficaci sono concrete: definire quali strumenti sono approvati, imporre la revisione umana del codice generato prima del merge, tracciare le librerie introdotte dagli assistenti, far girare scanner di sicurezza sul codice prodotto e formare i team a riconoscere gli errori tipici dei modelli. Sono accorgimenti banali sulla carta, ma e' proprio la loro assenza che, secondo l'indagine, distingue i team che traggono pieno vantaggio dall'IA da quelli che ne raccolgono solo una parte.
Cosa significa per chi sviluppa
Il messaggio, anche per il tessuto produttivo italiano fatto di software house e team interni, e' che l'IA per il codice e' ormai "table stakes", un requisito di base e non piu' un fattore di differenziazione. Il vantaggio competitivo si sposta a valle: chi definisce regole su quali strumenti usare, come revisionare l'output, come tracciare le librerie introdotte e come testare la sicurezza ottiene gran parte del guadagno di produttivita'; chi lascia fare senza policy rischia di accumulare debito tecnico e falle. Non e' una questione di vietare o permettere l'IA - quella battaglia e' finita - ma di deciderne le regole d'ingaggio prima che lo faccia un incidente.
