“L’AI non deve scrivere Linux”: Linus Torvalds spiega dove l’intelligenza artificiale funziona davvero

Nel dibattito sull’intelligenza artificiale applicata allo sviluppo software, Linus Torvalds ha assunto una posizione netta. Non c’è entusiasmo cieco né un rifiuto ideologico. C’è piuttosto una valutazione pratica, maturata osservando cosa funziona davvero nel contesto più complesso e delicato dell’open source: il kernel Linux. Linus Torvalds si definisce apertamente un sostenitore dell’uso dell’AI, ma con una precisazione fondamentale: il suo interesse non riguarda la generazione automatica di codice complesso, bensì il supporto alla manutenzione. In altre parole, l’AI è utile quando aiuta a gestire il rumore, non quando pretende di sostituire il giudizio umano.

Linus Torvalds: l’AI è un valido aiuto per i maintainer software

Secondo Torvalds, il vero collo di bottiglia nel kernel moderno non è la scrittura del codice, ma la sua valutazione. Ogni ciclo di sviluppo produce decine di migliaia di commit, distribuiti su sottosistemi estremamente eterogenei, con interdipendenze spesso non evidenti nemmeno agli sviluppatori più esperti. A questo si aggiunge il fatto che l’intero processo di revisione avviene principalmente via mailing list, in particolare sulla Linux Kernel Mailing List, dove le informazioni utili sono immerse in un flusso continuo di patch, risposte, follow-up e discussioni incrociate.

In questo contesto, Torvalds considera l’AI come un moltiplicatore di attenzione. Un modello AI è capace di analizzare una patch e confrontarla automaticamente con migliaia di modifiche storiche, riuscendo a individuare potenziali regressioni, violazioni di pattern consolidati o effetti collaterali su architetture diverse da quella di riferimento. Sebbene questo tipo di analisi preventiva non sostituisca la revisione umana, riduce drasticamente il numero di patch che arrivano sulla scrivania del maintainer senza alcun valore aggiunto.

Torvalds ha sottolineato che il kernel non soffre di mancanza di contributori, ma di scarsità di revisori esperti. L’AI, se usata correttamente, agisce proprio su questo squilibrio strutturale, filtrando il rumore prima che diventi debito cognitivo. L’idea che un sistema automatico possa “scrivere il kernel” rimane invece, dal suo punto di vista, tecnicamente infondata e pericolosa, data la complessità delle invarianti interne e delle assunzioni non documentate che governano il codice.

Modelli AI: non autori, ma amplificatori di attenzione

Nel pensiero di Torvalds, i modelli linguistici vanno interpretati come l’evoluzione naturale degli strumenti di sviluppo. Non sono programmatori, ma amplificatori di attenzione. Possono leggere tutto, ricordare tutto e confrontare tutto, qualità che diventano decisive in un progetto che vive di continuità storica e memoria collettiva.

La visione del “re pinguino” si riflette anche nel modo in cui l’AI è già utilizzata nella pratica. Sistemi basati su modelli linguistici sonno impiegati per riassumere thread complessi, confrontare patch con precedenti storici, segnalare similitudini semantiche e ridurre drasticamente il tempo necessario per l’analisi iniziale. Torvalds osserva che, in questo ruolo, l’AI assomiglia molto più a un compilatore avanzato o a un linter intelligente (il linter è uno strumento che analizza il codice sorgente per individuare errori, cattive pratiche e potenziali problemi, senza eseguirlo) che a un collega umano.

Uno degli esempi più concreti di integrazione dell’AI nel kernel arriva dal lavoro di Sasha Levin, maintainer del ramo stable. Il sistema AUTOSEL, usato per individuare quali patch debbano essere retroportate nelle versioni stabili, è stato riprogettato usando embeddings semantici:

• Ogni commit è rappresentato come un punto in uno spazio semantico.
• I Large Language Model (LLM) cercano similarità con patch storicamente retroportate.
• Più modelli “votano”.
• L’elenco finale viene sempre validato da un umano.

Il risultato non è l’automazione della decisione, ma la riduzione drastica del rumore cognitivo. In un progetto che genera migliaia di patch, questo approccio rende sostenibile un lavoro che altrimenti porterebbe inevitabilmente al burnout.

Il caso delle patch generate dall’AI e il tema della trasparenza

Quando l’AI passa dal supporto alla generazione diretta di codice, la posizione di Torvalds diventa significativamente più prudente. L’inventore di Linux cita il caso emblematico di una patch inclusa nel kernel che modificava una struttura hash, interamente prodotta da un modello linguistico, completa di commit message e test automatici. La modifica era corretta dal punto di vista funzionale, compilava senza errori e superava i test previsti.

Tuttavia, un’analisi successiva ha evidenziato la rimozione involontaria dell’attributo __read_mostly, un supporto considerato fondamentale per l’ottimizzazione delle cache line su architetture SMP (significa disporre i dati in memoria in modo che più CPU condividano le cache senza rallentarsi a vicenda su sistemi multicore). L’impatto non era immediatamente visibile, ma poteva tradursi in un degrado prestazionale su carichi specifici. Per Torvalds, questo episodio ha messo in luce un limite strutturale dell’AI: la difficoltà nel preservare semantiche implicite che non emergono direttamente dal contesto locale del codice.

Torvalds ha dichiarato apertamente che avrebbe applicato un livello di scrutinio più elevato se avesse saputo che la patch era stata generata interamente da uno strumento automatico. Da qui nasce l’esigenza di introdurre un meccanismo di disclosure esplicito per il codice derivato da AI. Non si tratta di sfiducia verso la tecnologia, ma di adeguare il processo di revisione alla natura dello strumento utilizzato, preservando l’integrità del modello di sviluppo collaborativo del kernel.

Responsabilità umana come principio non negoziabile

Un punto su cui Torvalds è inflessibile riguarda la responsabilità. Qualunque strumento venga usato, la responsabilità finale resta sempre dello sviluppatore e del maintainer che approva una modifica. L’AI non firma patch, non risponde di regressioni e non gestisce le conseguenze di un errore in produzione.

Si tratta di un’impostazione che distingue nettamente l’approccio usato per il kernel Linux da molte narrazioni commerciali sull’AI. Non c’è l’idea di delegare decisioni critiche, ma di rendere sostenibile un carico di lavoro che, senza supporti intelligenti, rischia di diventare ingestibile e di portare al burnout di figure chiave del progetto.

Tra evoluzione degli strumenti e rischi sistemici

Un altro aspetto su cui Torvalds insiste riguarda la sostenibilità a lungo termine degli strumenti basati su AI. Parla dell’utilizzo di modelli proprietari, con costi, licenze e vincoli operativi che sfuggono al controllo della comunità open source. Affidare processi critici come il triage delle patch, la revisione preliminare o l’analisi di regressioni a piattaforme non sostituibili introduce un rischio sistemico.

Torvalds ha richiamato esplicitamente l’esperienza di BitKeeper, il sistema di versionamento utilizzato per il kernel nei primi anni 2000. Quando il cambio di licenza rese impossibile il suo utilizzo, l’intero progetto si trovò improvvisamente senza infrastruttura. La nascita di Git fu una risposta brillante, ma anche il risultato di una crisi evitabile. Per questo motivo, Torvalds vede con favore l’uso dell’AI solo se incapsulata in strumenti che possano essere sostituiti, replicati o reimplementati, senza compromettere il flusso di sviluppo.