Linus Torvalds difende l'AI su Linux, ma detta una condizione

Linus Torvalds ha chiarito senza mezzi termini la posizione del progetto Linux sull’intelligenza artificiale: parlando del kernel Linux, non vi è alcuna contrarierà rispetto all’uso dei Large Language Model (LLM) e il “re pinguino” non intende certo impedire agli sviluppatori di usarli come strumenti di supporto. Nessuno sarà obbligato ad affidarsi a un assistente generativo, ma neppure chi sceglie di farlo dovrà subire divieti fondati su un rifiuto ideologico della tecnologia.

Il messaggio dell’ideatore di Linux arriva mentre la comunità open source discute sempre più animatamente di codice generato, revisioni automatiche, responsabilità degli autori e carico aggiuntivo imposto ai maintainer.

Il kernel ha sempre fatto largo uso di automazione: compilatori, analizzatori statici, fuzzing, test automatici, bot per la verifica delle patch e sistemi come syzbot cercano errori che una normale revisione umana potrebbe non intercettare. I LLM introducono però una differenza importante: non si limitano ad applicare regole deterministiche, ma producono valutazioni probabilistiche, spiegazioni e perfino modifiche al codice. Possono individuare problemi complessi, ma anche generare segnalazioni convincenti che – allo stesso tempo – risulteranno poi completamente sbagliate.

Torvalds: l’AI è uno strumento, non una scelta obbligatoria

La presa di posizione di Torvalds nasce dalla risposta a un messaggio che descriveva le raccomandazioni della Software Freedom Conservancy come generalmente ostili ai LLM.

Il creatore di Linux ha riconosciuto che alcuni sviluppatori nutrono una forte avversione verso l’intelligenza artificiale, ma ha escluso che tale orientamento possa trasformarsi nella linea ufficiale del kernel.

Il concetto centrale è semplice: l’AI va trattata come un “utensile tecnico“, alla stessa maniera di molti altri strumenti impiegati nello sviluppo. Torvalds non propone di sostituire i revisori umani, né di richiedere l’uso di modelli linguistici per contribuire. Sostiene però che l’utilità dei modelli AI non possa più essere liquidata come un’ipotesi puramente promozionale.

Va detto però che l’affermazione non concede un lasciapassare al codice generato. Nel kernel Linux qualsiasi patch deve ancora rispettare requisiti molto severi: correttezza, leggibilità, compatibilità con le API interne, assenza di regressioni, motivazione tecnica e disponibilità dell’autore a difenderla sulla mailing list. Il punto è che la provenienza di un suggerimento non determina da sola il suo valore. Conta la qualità del risultato e, soprattutto, la responsabilità di chi lo presenta.

Torvalds riconosce anche l’altro lato della questione. Gli strumenti basati su LLM possono aumentare il lavoro dei maintainer, sia perché trovano difetti imbarazzanti già presenti nel codice, sia perché producono rapporti inconsistenti che qualcuno dovrà comunque verificare. La risposta, secondo lui, non consiste nel rifiutare la tecnologia: bisogna progettare processi nei quali l’automazione aiuti davvero chi revisiona.

Sashiko mostra cosa può fare una revisione agentica

Sashiko rappresenta uno degli esempi più avanzati dell’impostazione dipinta da Torvalds. Il progetto, ospitato dalla Linux Foundation e distribuito con licenza Apache 2.0, controlla le mailing list pubbliche e analizza le patch inviate per l’integrazione nel kernel. L’istanza pubblica che segue la Linux Kernel Mailing List utilizza risorse di calcolo e token messi a disposizione da Google.

Il sistema divide l’analisi in più fasi: dapprima esamina l’obiettivo generale della modifica e la coerenza tra messaggio di commit e implementazione; ricostruisce poi i flussi di esecuzione, gli error path e la gestione delle risorse. Altri controlli cercano errori come l’uso di memoria già liberata, la doppia liberazione della stessa area, la violazione delle regole RCU per l’accesso concorrente ai dati, i deadlock tra processi o thread, gli accessi oltre i limiti della memoria, le race condition di tipo TOCTOU, in cui un dato cambia tra il controllo e il suo utilizzo, e i problemi legati al DMA, ai registri hardware e alle barriere di memoria che regolano l’ordine delle operazioni.

Le osservazioni raccolte attraversano ulteriori fasi di consolidamento, deduplicazione e verifica. Solo alla fine, Sashiko genera una risposta nel formato tipico, con commenti associati alle righe interessate. In pratica, tenta di imitare un gruppo di revisori con specializzazioni differenti invece di affidare l’intero compito a una singola interrogazione generica.

Il risultato resta probabilistico. Eseguendo due volte la stessa analisi, il sistema potrebbe evidenziare difetti diversi oppure non riprodurre una segnalazione precedente.

Il problema reale è il costo imposto ai maintainer

Un rapporto generato automaticamente può richiedere ore per chi deve controllarlo. Qui emerge la principale asimmetria introdotta dai LLM: un utente può analizzare migliaia di file e produrre indicazioni su decine di presunte vulnerabilità in pochi minuti; il maintainer, invece, deve ricostruire ogni percorso di esecuzione, verificare le condizioni necessarie e stabilire se il problema esiste davvero.

La comunità Linux ha già sperimentato gli effetti di questo squilibrio. Torvalds aveva criticato la quantità di segnalazioni AI duplicate o prive di validazione recapitate ai canali di sicurezza.

Per trasformare un’osservazione in un contributo utile servono almeno una riproduzione affidabile, una spiegazione comprensibile e, quando possibile, una patch verificata.

Inviare direttamente l’output di un chatbot sposta il rischio e il lavoro sul destinatario. Ed è proprio ciò che strumenti come Sashiko cercano di evitare introducendo controlli successivi, deduplicazione e stima della severità. Resta comunque necessario un filtro umano.

La responsabilità resta umana

La posizione di Torvalds appare, come al solito, molto pragmatica: i LLM possono trovare bug, chiarire codice poco leggibile, proporre test e assistere nella revisione. Possono anche “inventarsi” funzioni inesistenti (le cosiddette allucinazioni), ignorare vincoli architetturali e suggerire correzioni peggiori del problema rilevato.

Accettarli come strumenti non significa considerarli autorità tecniche. Nel modello Linux, il contributore resta responsabile della patch e il maintainer conserva il potere di respingerla. L’automazione può ampliare la capacità di analisi, ma non sostituisce la conoscenza del sottosistema, l’esecuzione dei test e il confronto pubblico sulla mailing list.

Il messaggio di Torvalds separa due piani che spesso finiscono per essere confusi: da una parte c’è il diritto a non usare strumenti AI; dall’altra, il tentativo di impedire che li utilizzino gli altri. Linux proteggerà il primo punto, ma non sembra disposto ad accettare il secondo come principio generale.

La sfida ora consiste nel rendere gli strumenti di sviluppo basati su modelli AI abbastanza precisi da ridurre il carico invece di aumentarlo.

Sashiko dimostra che una revisione strutturata può già intercettare errori sfuggiti agli esseri umani. Non dimostra, almeno per ora, che il problema della qualità e dei falsi positivi sia risolto. Non bisogna quindi stabilire se l’AI debba entrare o meno nello sviluppo del kernel, perché in parte è già entrata, ma decidere come usarla senza scaricarne i costi su chi mantiene Linux.