Linus Torvalds sull'AI nel coding: "sta aiutando Linux, ma crea anche nuovi problemi"

Il “re pinguino” non usa mezzi termini quando parla di intelligenza artificiale applicata allo sviluppo software: secondo Linus Torvalds gli strumenti AI stanno accelerando il lavoro sul kernel Linux, ma stanno anche creando nuovi problemi operativi e sociali che molti maintainer iniziano a percepire come un peso concreto. Dal palco dell’Open Source Summit North America della Linux Foundation, Torvalds ha descritto una situazione che esula dal mero entusiasmo per il coding assistito. Il kernel Linux riceve più patch, più segnalazioni e più contributi rispetto al passato; allo stesso tempo, però, aumenta il rumore di fondo, crescono le duplicazioni e si complicano le attività legate alla gestione dei problemi di sicurezza.

La questione interessa un settore enorme. Linux alimenta la maggior parte dei server cloud pubblici, domina il mondo embedded, gira nei container Docker, sostiene Android e governa infrastrutture critiche in ambito industriale e telecomunicazioni. Quando l’ideatore del kernel Linux parla di un aumento del 20% nei commit in appena due release consecutive, significa che gli strumenti AI stanno pesantemente modificando il flusso di lavoro di migliaia di sviluppatori distribuiti in tutto il mondo.

L’aumento dei commit e il nuovo ritmo dello sviluppo Linux

Linus Torvalds ha ricordato che il modello organizzativo del kernel era rimasto sorprendentemente stabile per circa 20 anni, soprattutto dopo l’introduzione di Git nel 2005. Va ricordato che Git nacque proprio per gestire lo sviluppo del kernel Linux: da allora il processo di merge, revisione e integrazione delle patch ha mantenuto una struttura relativamente costante. Il punto è che l’arrivo di strumenti come GitHub Copilot, Cursor, Claude Code, OpenAI Codex e i LLM (Large Language Models) integrati negli IDE ha alterato rapidamente il volume delle modifiche prodotte.

Il numero uno del progetto kernel Linux ha spiegato che inizialmente attribuiva l’incremento delle patch all’avvicinarsi di Linux 7.0. In realtà, secondo lui, la vera causa è un’altra: gli strumenti AI sono finalmente maturati abbastanza da risultare utili a una larga fascia di sviluppatori.

In pratica, la barriera d’ingresso si abbassa. Uno sviluppatore alle prime armi può usare rapidamente strumenti automatici per generare il codice di base di un progetto, scrivere versioni iniziali dei driver, creare le prime patch correttive o analizzare le chiamate alle API del kernel, cioè le interfacce usate dal sistema operativo Linux per comunicare con i vari componenti software, senza dover conoscere in dettaglio sottosistemi molto complessi come il VFS (Virtual File System, che gestisce l’accesso ai file), lo stack di rete o il sistema di gestione della memoria. L’AI accelera soprattutto i lavori ripetitivi: conversione di strutture dati, adattamento alle nuove API interne, refactoring meccanici, aggiornamenti di macro e verifica di errori sintattici.

Il problema di fondo è che una patch apparentemente corretta può introdurre deadlock, race condition o regressioni di performance visibili solo sotto carichi reali. I LLM generano codice plausibile; il kernel Linux richiede invece codice logicamente coerente e conforme a regole interne molto rigorose, necessarie per garantire il corretto funzionamento del sistema.

Il problema delle segnalazioni duplicate nell’ambito della sicurezza su Linux

La parte più delicata dell’intervento di Torvalds riguarda la sicurezza: secondo il creatore di Linux, le mailing list riservate dedicate alle vulnerabilità hanno iniziato a ricevere un numero crescente di report duplicati generati tramite AI.

Il fenomeno non sorprende chi lavora nella ricerca di nuove vulnerabilità: i LLM, combinati con strumenti di analisi statica, symbolic execution e fuzzing automatico, permettono di individuare pattern vulnerabili con una velocità molto superiore rispetto al passato. Un ricercatore può chiedere a un modello di esaminare un driver, identificare possibili use-after-free, buffer overflow o integer overflow e produrre rapidamente proof-of-concept preliminari.

Torvalds osserva però che molte segnalazioni arrivano incomplete, scarsamente verificate oppure si riferiscono a problemi già noti. Tanto che la security list del kernel Linux è stata letteralmente sommersa da report ridondanti: ed è una situazione particolarmente critica perché la lista è gestita da poche persone e opera sotto embargo per evitare divulgazioni premature.

Storicamente, il team Linux gestiva molte vulnerabilità in modo relativamente silenzioso. I maintainer informavano in anticipo i gestori delle principali distribuzioni – Red Hat, SUSE, Canonical, Debian e altre – consentendo il rilascio coordinato degli aggiornamenti. Oggi la situazione cambia drasticamente: una semplice patch pubblicata nel repository Git può essere analizzata automaticamente da sistemi AI che ricostruiscono in poche ore l’impatto reale della vulnerabilità.

Torvalds ha citato un episodio emblematico: una correzione pubblicata e, appena 3 ore dopo, un post online che spiegava già le implicazioni di sicurezza della modifica. Di certo si riferisce alle diverse problematiche emerse in un solo mese in Linux: Copy Fail (CVE-2026-31431), Dirty Frag, Fragnesia (CVE-2026-46300) e ssh-keysign-pwn (CVE-2026-46333).

Perché una vulnerabilità trovata con AI va considerata pubblica

Uno dei passaggi più interessanti riguarda la nuova linea guida proposta da Torvalds: se una vulnerabilità viene riportata avvalendosi di strumenti AI, bisogna considerarla praticamente già pubblica.

Se un modello riesce a identificare automaticamente un bug partendo dal codice sorgente disponibile pubblicamente, altri cento ricercatori possono ottenere lo stesso risultato in tempi brevissimi.

Linux espone milioni di righe di codice accessibili a chiunque; i modelli AI possono effettuare correlazioni trasversali fra CVE precedenti, commit storici, pattern di vulnerabilità e modifiche recenti. Uno scenario del genere riduce drasticamente la finestra temporale disponibile per preparare patch coordinate.

Torvalds ha comunque distinto tra divulgazione tecnica e pubblicazione irresponsabile di exploit funzionanti. Secondo lui, pubblicare codice exploit completo per ottenere visibilità personale resta un comportamento dannoso, soprattutto quando colpisce infrastrutture critiche o aziende che non hanno ancora distribuito gli aggiornamenti correttivi.

Open source contro closed source: l’illusione della protezione

Una parte importante del discorso riguarda il software proprietario: Torvalds sostiene che chi pensa di risolvere il problema chiudendo il codice sorgente rischia una brutta sorpresa.

I modelli AI, infatti, non dipendono esclusivamente dalla disponibilità del sorgente: reverse engineering, decompilazione automatica, analisi binaria assistita da LLM e strumenti come Ghidra, IDA Pro o Binary Ninja permettono già oggi di ricostruire logica applicativa piuttosto complessa.

Inoltre il software closed source soffre di un problema aggiuntivo: la comunità non può collaborare facilmente alla correzione: se un’AI trova una vulnerabilità in un componente proprietario, gli utenti restano dipendenti dal vendor per il rilascio della patch.

Torvalds ha collegato questo aspetto anche all’aumento delle vulnerabilità corrette da Microsoft: Dustin Childs della Zero Day Initiative di Trend Micro ha recentemente osservato che Microsoft ha corretto oltre 1.100 CVE nel 2025. Il dato suggerisce che gli strumenti automatizzati stanno aumentando la capacità di individuare difetti anche nel software commerciale.

Va detto però che il numero di CVE non misura automaticamente una minore sicurezza: in molti casi indica una capacità di rilevamento più efficace. Il vero problema emerge quando il volume delle vulnerabilità supera la capacità operativa dei team di manutenzione.

Burnout dei maintainer e pressione sulle comunità di sviluppo

Torvalds ha insistito su un tema spesso sottovalutato: i progetti open source non soffrono principalmente per limiti tecnici, ma per problemi umani.

Il kernel Linux dispone di aziende sponsor, fondazioni, maintainer esperti e infrastrutture mature. Molti progetti minori invece dipendono da una o due persone che lavorano gratuitamente nel tempo libero. In questi casi un’ondata di report AI può diventare ingestibile.

Il maintainer si ritrova a leggere decine di segnalazioni generate automaticamente, verificare riproducibilità, chiedere dettagli tecnici e spesso non ricevere più alcuna risposta dal ricercatore che ha trasmesso il report. Torvalds ha descritto bene il fenomeno del “drive-by reporting” : qualcuno invia un report automatico e sparisce.

La situazione ricorda quanto accaduto anni fa con il fuzzing massivo. Strumenti come AFL, syzkaller e libFuzzer aumentarono enormemente il numero di bug individuati nel kernel. Syzkaller, sviluppato inizialmente da Google, continua ancora oggi a produrre crash report automatizzati su molte componenti Linux. La differenza è che ora i LLM aggiungono interpretazione semantica e generazione automatica di spiegazioni, rendendo il processo ancora più accessibile.

Per Torvals l’AI non può sostituire gli sviluppatori

Torvalds respinge con forza l’idea secondo cui l’AI sostituirà completamente i programmatori: una sua analogia con compilatori e assembler chiarisce bene il ragionamento.

All’inizio della sua carriera, Torvalds scriveva direttamente codice macchina: poi arrivarono assembler e compilatori, strumenti che aumentarono enormemente la produttività senza eliminare la necessità di comprendere il funzionamento reale del software.

Secondo l’inventore del kernel Linux, l’AI rappresenta semplicemente il passo successivo: non modifica i fondamenti dell’informatica bensì cambia il livello di astrazione con cui gli sviluppatori operano.

La stima fornita durante l’evento è significativa. I compilatori, a suo giudizio, aumentarono la produttività di circa 1.000 volte; l’AI potrebbe moltiplicarla per dieci. Una previsione importante perché ridimensiona molte narrative estreme circolate negli ultimi due anni.

Torvalds suggerisce che il valore dello sviluppatore continuerà a dipendere dalla capacità di comprendere sistemi complessi, debug, architetture, performance, concorrenza e manutenzione a lungo termine. Generare codice non basta.

Capire il codice resta indispensabile

Uno degli aspetti più interessanti del discorso riguarda il controllo del risultato finale. Torvalds ha spiegato che, anche quando usa strumenti AI nei propri progetti personali, continua a leggere il codice prodotto e persino l’assembly generato.

Nel kernel Linux piccoli dettagli implementativi possono fare enormi differenze: branch prediction, cache locality, barriere di memoria, ordinamento delle istruzioni, atomicità delle operazioni, comportamento NUMA o gestione delle interrupt.

Un modello AI può produrre codice corretto dal punto di vista funzionale ma inefficiente oppure fragile in condizioni di carico reale: il problema diventa ancora più serio nei sistemi che devono restare manutenibili per 10 o 15 anni.

Scrivere codice non equivale a mantenere software complesso nel tempo: gestire i progetti software più seri continua a richiedere competenze profonde, soprattutto nei progetti infrastrutturali.

Durante l’intervento, Torvalds ha criticato indirettamente le aziende che presentano l’AI come sostituto quasi totale dei programmatori: storicamente ogni avanzamento negli strumenti di sviluppo ha aumentato il numero di software creati e la complessità dei sistemi gestiti. Compilatori, framework, ambienti visuali e librerie non hanno eliminato gli sviluppatori; hanno ampliato ciò che era possibile costruire.

Torvalds vede l’AI nello stesso modo: un acceleratore operativo che sposta il lavoro umano verso revisione, architettura, verifica, sicurezza e coordinamento. Il software resta intrinsecamente complesso; i modelli generativi aiutano a gestire tale complessità, ma non sostituiscono il giudizio umano.