In questo articolo Indice dei contenuti 3 sezioni
Gli aggiornamenti del kernel Linux stanno diventando sempre più corposi e la spiegazione arriva direttamente da Linus Torvalds, che punta il dito su un fattore inaspettato: gli strumenti di intelligenza artificiale usati per revisionare il codice. Più software analizza i sorgenti, più difetti emergono, più correzioni finiscono nelle ultime fasi del ciclo di sviluppo. Torvalds la chiama una specie di nuova normalità, e con Linux 7.2 il fenomeno è diventato difficile da ignorare.
Vale la pena ricordare come funziona la macchina. Linux nasce nel 1991 e da oltre trent’anni cresce grazie a un processo distribuito, con sviluppatori e maintainer che passano al setaccio patch, regressioni e problemi prima di dare il via libera a una versione stabile. Oggi una fetta consistente di quel lavoro di analisi si appoggia a modelli generativi, analizzatori automatici e agenti capaci di scandagliare quantità enormi di codice in tempi che nessun essere umano potrebbe reggere.
Le release candidate di Linux 7.2 fuori misura
Il primo segnale forte è arrivato con Linux 7.2 rc6, pubblicata il 2 agosto 2026. Torvalds ha notato che si trattava probabilmente della rc6 con il maggior numero di commit vista da anni. Il dettaglio interessante è che le statistiche non mostravano un unico punto critico: poco meno del 60% delle modifiche riguardava i driver, circa il 20% il networking, il resto si spalmava tra architetture, filesystem, strumenti e altre aree.
Niente correzioni monumentali, quindi, ma una valanga di interventi piccoli. Tra i driver comparivano modifiche a GPU, rete, audio, SPI e ATA. Sul fronte networking pesava anche un arretrato che Torvalds ha ricollegato in parte al calendario delle conferenze e a come i maintainer avevano organizzato il lavoro. Il numero rende bene l’idea: tra rc5 e rc6 sono entrati 537 commit, un volume che avrebbe dovuto svuotare la coda per le uscite successive.
Non è andata così. La rc7, pubblicata il 9 agosto, non ha invertito la rotta. Torvalds ha ammesso di non essere entusiasta delle dimensioni complessive, aggiungendo però il passaggio chiave: buona parte dei fix nasce dalle revisioni condotte con vari strumenti di intelligenza artificiale.
Le regole del kernel per gli assistenti AI
Attenzione a non fraintendere: questo non significa che Linux 7.2 sia pieno di codice generato in automatico. Gli strumenti AI intervengono in fasi diverse, analizzano i sorgenti, individuano pattern sospetti, confrontano percorsi di esecuzione, suggeriscono condizioni limite e aiutano a circoscrivere errori che poi una persona verifica e corregge.
La comunità del kernel non ha vietato nulla. Al contrario, la documentazione ufficiale contiene ormai una sezione dedicata agli AI Coding Assistants, con regole piuttosto ruvide. Un agente non può presentare una modifica e assumersene la responsabilità, perché quella resta prerogativa di un maintainer in carne e ossa. Il responsabile deve controllare il codice, verificare la compatibilità con la licenza GPL 2.0 e con le regole di licensing, aggiungere personalmente l’indicazione Signed off by e prendersi la responsabilità della patch. È previsto anche un tag Assisted by per dichiarare l’uso di un agente e, dove possibile, il modello impiegato.
Sulla caccia ai bug la procedura è ancora più stringente. Per i problemi non banali serve tentare la creazione di un reproducer, preparare la correzione, compilare il kernel, rifare l’analisi e verificare che la patch risolva davvero il difetto. Se qualcosa non si riesce a testare, va dichiarato. Chiedere a un modello di trovare una vulnerabilità in un file e girare la risposta alla mailing list, insomma, non funziona.
Cosa preoccupa davvero Torvalds
Ogni versione stabile nasce dopo una merge window iniziale che accoglie le novità, poi arrivano le release candidate settimanali. Avvicinandosi al traguardo, numero e portata delle modifiche dovrebbero calare. Una rc7 gonfia non è ideale, perché ogni fix impone nuove compilazioni, test e controlli, e può a sua volta introdurre una regressione.
Nel caso della rc7, però, Torvalds ha detto di non aver visto nulla di allarmante. Tre blocchi risultavano più consistenti degli altri: s390 zcrypt, il sottosistema che sui mainframe IBM Z gestisce l’accelerazione crittografica hardware e gli adattatori per la cifratura, poi Btrfs, dove è rientrata parte dell’infrastruttura dei fixup worker, i thread che completano in modo differito alcune operazioni interne, e infine Netfilter ipset, il componente che permette al firewall di gestire insiemi di indirizzi IP, reti e porte senza lunghe sequenze di corrispondenze individuali. Tutto il resto sono correzioni minute e distribuite, senza un problema dominante capace di far slittare la versione stabile.
