Il supporto di Linus Torvalds alla programmazione con AI incontra il problema dei maintainer di Linux
Il supporto di Linus Torvalds alla programmazione con AI oggi appare insolitamente entusiasta, nonostante il crescente conflitto sui contributi generati dalle macchine nel software open source. In un keynote del 9 ottobre, il creatore di Linux ha dichiarato che ora “gli piace davvero usare l'AI”, dopo aver in passato giudicato poco impressionante la programmazione con AI.
Quell'approvazione non era un'autorizzazione a inviare codice non verificato. Torvalds ha definito l'AI uno strumento utile per rendere la programmazione piacevole, soprattutto per i principianti e i progetti personali. Ha inoltre avvertito gli sviluppatori di essere “molto prudenti” nell'usarla per lavori seri.
La distinzione è importante perché il kernel Linux ha già incontrato entrambi gli aspetti dello sviluppo assistito dall'AI. Gli strumenti automatizzati possono individuare difetti reali e aiutare gli sviluppatori a lavorare al di fuori dei linguaggi che conoscono meglio. Possono anche sommergere i maintainer di segnalazioni duplicate, patch superficiali e lavoro che gli esseri umani devono verificare.
Linux pone quindi una questione più ardua del semplice stabilire se l'AI scriva codice accettabile. La sfida consiste nel decidere chi sostiene il costo della convalida di quel codice. La risposta emergente combina un uso permissivo degli strumenti con trasparenza, revisione umana e responsabilità personale.
I commenti di Linus Torvalds sulla programmazione con AI tracciano un confine netto
Torvalds sostiene l'AI come strumento di programmazione, ma il suo sostegno termina dove iniziano gli output non verificati.
Torvalds ha parlato dell'AI durante una conversazione con Dirk Hohndel all'Open Source Summit Europe di Praga. La Linux Foundation ha programmato la sessione per il 9 ottobre nell'ambito del programma per il 35° anniversario del progetto. Il programma della conferenza ha collocato la loro conversazione accanto a percorsi dedicati a Linux, open AI, fiducia digitale e software safety-critical.
La sua posizione segnava un cambiamento nell'esperienza personale. Torvalds ha detto che un tempo riteneva che la programmazione con AI “non fosse affatto molto buona”. Da allora è arrivato al punto di apprezzarne l'uso e di considerarla uno strumento prezioso se gestito correttamente.
Questo cambiamento non lo ha trasformato in un sostenitore della generazione di software senza supervisione. Torvalds ha sottolineato di essere soprattutto il maintainer e punto di raccolta del kernel, piuttosto che qualcuno che ne scrive la maggior parte del codice. I suoi esperimenti personali rientrano in una categoria di rischio diversa dall'accettare modifiche nell'infrastruttura usata in tutto il mondo.
Ha descritto l'AI come particolarmente utile per compiti al di fuori della sua competenza consolidata. Un esempio riguardava un progetto personale di pedale per chitarra. Torvalds poteva realizzare il firmware in C, ma l'interfaccia aveva un aspetto datato. Ha quindi usato l'AI per produrre un'implementazione Java, un linguaggio che normalmente non utilizza.
Il risultato non è stato presentato come ingegneria Java di livello esperto. Gli ha mostrato come la sua familiare implementazione in C si traducesse in un altro linguaggio e ha dato al progetto un'interfaccia funzionale. L'esperimento illustra un caso d'uso delimitato, nel quale lo sviluppatore comprende il comportamento previsto e può ispezionare il risultato.
Torvalds ha anche collegato l'AI all'esperienza di imparare a programmare. Quando iniziò a scrivere codice nel 1981, anche programmi semplici potevano sembrare significativi perché il software commerciale era meno rifinito. Oggi i nuovi sviluppatori confrontano i loro primi progetti con applicazioni mature create da grandi team.
L'AI può abbassare quella barriera psicologica. Può aiutare i principianti a trasformare una piccola idea in qualcosa di visibile prima che abbiano padroneggiato ogni componente. Torvalds ha definito quel processo un modo per trovare gioia nella programmazione e ha persino chiamato l'AI una “droga d'ingresso” nel settore.
L'avvertimento relativo al lavoro serio cambia il significato di queste osservazioni. Un'interfaccia hobbistica generata che si comporta male crea un inconveniente. Una patch difettosa del kernel può introdurre crash, perdita di dati, vulnerabilità di sicurezza o problemi di manutenzione difficili da individuare.
Torvalds ha quindi attribuito la responsabilità alla persona che utilizza lo strumento. Uno sviluppatore deve comprendere ciò che il software dovrebbe fare e confermare che l'implementazione generata lo faccia davvero. La sola abilità nel formulare prompt non sostituisce il giudizio tecnico.
Questo è il limite centrale del supporto di Linus Torvalds alla programmazione con AI. L'AI può ridurre lo sforzo necessario per ottenere un risultato iniziale. Non elimina il lavoro richiesto per stabilire se quel risultato appartenga a una codebase critica.
La sua posizione non è né un'approvazione indiscriminata né un rifiuto ideologico. Tratta l'AI come gli altri strumenti di sviluppo, riconoscendo però che il suo output fluente può nascondere errori in modo più convincente degli strumenti tradizionali.
Questa posizione pratica di compromesso coincide strettamente con le regole in evoluzione del kernel per i contributi. Il progetto accetta l'assistenza dei sistemi automatizzati, ma non consente a un agente AI di assumere le responsabilità legali o tecniche di un contributore.
Il kernel Linux consente assistenza, non automazione anonima
Le regole del kernel si concentrano sui contributori responsabili, poiché il codice generato non può certificare autonomamente la propria origine, licenza o correttezza.
Il kernel Linux pubblica ora specifiche linee guida per gli assistenti AI rivolte ai contributori. Queste indirizzano il lavoro assistito dall'AI attraverso lo stesso processo di sviluppo, gli stessi standard di codifica, requisiti di licenza e aspettative di revisione applicabili alle patch scritte da esseri umani.
Questa continuità è importante. Linux accetta da tempo codice modellato da compilatori, analizzatori statici, generatori di codice, sistemi di refactoring automatizzato e script. Un contributo non diventa accettabile semplicemente perché una persona ha digitato ogni carattere.
Al contrario, un contributo non diventa inaccettabile solo perché uno strumento ne ha prodotto una parte. I revisori si preoccupano del comportamento, della manutenibilità, della licenza e del fatto che chi lo invia sappia difendere la modifica.
I sistemi generativi complicano questo modello consolidato perché possono produrre codice, spiegazioni, messaggi di commit e commenti di revisione attraverso un'unica interfaccia. I loro output possono sembrare completi anche quando il ragionamento è errato o la provenienza resta incerta.
Le linee guida del kernel affrontano questa incertezza attraverso la responsabilità umana. Gli agenti AI non devono aggiungere un tag Signed-off-by. Quel tag appartiene a una persona che possa fornire la certificazione richiesta dal Developer Certificate of Origin, comunemente chiamato DCO.
Nell'ambito del processo DCO del kernel, il firmatario conferma che il contributo ha un'origine accettabile e può essere distribuito con la licenza del progetto. Un modello linguistico non può fornire tale dichiarazione legale.
La persona che invia un lavoro assistito dall'AI deve rivedere il codice generato, garantirne la conformità alle licenze, aggiungere la propria firma e accettarne la piena responsabilità. Ciò significa che “l'ha scritto il modello” non può servire come difesa quando i revisori trovano un problema.
Le linee guida introducono inoltre un tag Assisted-by per dichiarare un coinvolgimento significativo di LLM. I contributori possono identificare l'uso di un LLM e di altri strumenti di analisi specializzati. Il tag offre ai maintainer un contesto utile senza fingere che lo strumento sia un contributore legale.
Regole separate sui contenuti generati estendono il principio oltre i file sorgente. Possono riguardare messaggi di commit, lettere di accompagnamento, documentazione e traduzioni quando contenuti generati entrano materialmente in un invio.
Queste regole incoraggiano i contributori a spiegare quali strumenti hanno usato e, quando utile, quali input hanno prodotto il lavoro. Lo scopo non è richiedere una trascrizione di ogni suggerimento di autocompletamento. È rendere visibile l'automazione sostanziale che può influire sulla revisione, sulla provenienza o sulla responsabilità.
La trasparenza diventa più importante man mano che l'assistenza AI diventa meno visibile. Una patch generata può essere riscritta a mano. Una patch scritta da un umano può ricevere una descrizione generata dall'AI. Un modello potrebbe individuare un difetto mentre la correzione finale proviene da un maintainer.
L'approccio del kernel riconosce questi flussi di lavoro misti. Evita il compito irrealistico di classificare ogni carattere come creato da un essere umano o da una macchina. Chiede invece se uno strumento abbia dato un contributo significativo e se un essere umano sia pronto ad assumersi la responsabilità dell'invio finale.
Questo modello offre alle aziende e ad altri progetti open source un precedente utile. I team non devono scegliere tra vietare ogni strumento AI e accettare output opaco degli agenti. Possono definire soglie di trasparenza, preservare la firma umana e richiedere le normali evidenze di test.
Tuttavia, le regole sull'attribuzione risolvono solo una parte del problema. Identificano la responsabilità dopo che qualcuno ha creato un invio. Non impediscono all'AI di aumentare il numero di segnalazioni e patch che i maintainer devono ispezionare.
Questo problema di volume è il punto in cui la posizione permissiva di Linux affronta il suo test più difficile.
L'AI rende economico contribuire, mentre la revisione resta costosa
Il conflitto non è tra codice umano e codice macchina. È tra output generato abbondante e scarsa attenzione dei maintainer.
Torvalds ha riconosciuto che l'analisi assistita dall'AI sta individuando problemi di valore nel kernel. Ha anche descritto un flusso di patch casuali che coprono qualsiasi cosa, da gravi falle di sicurezza a driver che nessuno tocca da 20 anni.
Un sistema automatizzato non comprende naturalmente quale difetto meriti una scarsa attenzione umana. Se gli viene chiesto di cercare perdite di memoria, può produrre segnalazioni ovunque la sua analisi rilevi uno schema sospetto. Non gli importa se il componente interessato è ampiamente distribuito, obsoleto o già in fase di riparazione.
Questa mancanza di prioritizzazione trasferisce il lavoro ai maintainer. Qualcuno deve stabilire se una segnalazione è valida, determinare se duplica un lavoro precedente, trovare il responsabile del sottosistema appropriato, ispezionare la correzione proposta e valutarne le conseguenze più ampie.
Una segnalazione plausibile ma falsa può consumare più tempo di una palesemente debole. I maintainer devono esaminare abbastanza contesto per smentirla. La persona che ha generato la segnalazione potrebbe aver trascorso soltanto pochi minuti a formulare prompt per un modello.
Torvalds aveva già avvertito che un afflusso di segnalazioni AI stava rendendo difficile gestire la lista di sicurezza del kernel. Le scoperte duplicate aggravavano il carico perché utenti diversi potevano eseguire strumenti simili sullo stesso codice e segnalare in modo indipendente lo stesso problema.
All'evento di Praga, ha affermato che l'AI stava migliorando complessivamente la codebase. Questa valutazione favorevole era accompagnata da un avvertimento altrettanto diretto: stava mettendo sotto pressione i maintainer “al punto da diventare un problema”.
La portata della preoccupazione era visibile nell'incontro associato dei maintainer. Secondo Torvalds, circa tre quarti delle discussioni riguardavano il rendere gli strumenti AI per la generazione e revisione del codice meno stressanti e più utili.
Questo dettaglio colloca il dibattito oltre la preferenza personale. I maintainer non stanno semplicemente discutendo se il codice generato sembri autentico. Stanno riprogettando i flussi di lavoro attorno a un cambiamento produttivo già arrivato.
L'AI abbassa contemporaneamente diverse barriere. Consente agli sviluppatori meno esperti di abbozzare patch, aiuta i ricercatori a esaminare sottosistemi sconosciuti e trasforma un problema sospetto in una segnalazione rifinita. Queste capacità possono ampliare la base dei contributori e mettere in luce bug che altrimenti resterebbero inosservati.
Tuttavia, la stessa comodità incoraggia una partecipazione occasionale. Una persona può inviare una segnalazione senza comprendere il codice circostante, poi sparire quando un maintainer chiede passaggi di riproduzione, test o una correzione più completa.
L’attrito tradizionale nel contribuire un tempo filtrava parte di questi comportamenti. Preparare una patch, scrivere una spiegazione coerente e rispondere alla revisione richiedeva uno sforzo sufficiente a segnalare impegno. Gli strumenti generativi possono imitare questi segnali prima che l’utente abbia sviluppato conoscenze equivalenti.
La divulgazione non può ripristinare completamente quel segnale perduto. Un tag Assisted-by comunica a chi effettua la revisione che ha partecipato l’automazione. Non rivela però se chi invia il contributo comprende il sottosistema o se continuerà a essere coinvolto dopo la prima risposta.
Il kernel necessita quindi di filtri operativi oltre all’attribuzione. I maintainer hanno bisogno di modi per raggruppare segnalazioni duplicate, classificare l’impatto concreto, verificare automaticamente le affermazioni e individuare chi contribuisce ripetutamente con lavori utilizzabili.
Devono inoltre poter respingere rapidamente output di scarso valore. Trattare ogni segnalazione AI ben formulata come un contributo completo trasformerebbe il volume generato in un obbligo per revisori non retribuiti o già sovraccarichi.
Questa preoccupazione riguarda i progetti più piccoli in modo ancora più marcato. Linux dispone di una vasta rete di contributori e di maintainer impiegati dalle principali aziende tecnologiche. Una libreria gestita da uno o due volontari ha una capacità molto minore di assorbire segnalazioni automatizzate.
Questo squilibrio spiega perché i progetti open source abbiano adottato regole diverse sugli LLM. Un divieto può essere una decisione di gestione delle risorse, anziché l’affermazione che tutto il codice generato sia difettoso. Una politica permissiva può funzionare quando un progetto dispone di infrastrutture di test e di revisori sufficienti per far rispettare i propri standard.
Linux occupa una posizione insolita. Può beneficiare dell’analisi AI su una base di codice vastissima, ma ogni modifica accettata incide su infrastrutture critiche. La sua scala crea sia la ragione più forte per usare l’automazione sia la ragione più forte per limitarla.
Il vero compromesso è tra accesso e responsabilità
L’AI può invitare più persone a programmare, mentre un contributo responsabile richiede comunque competenza, costanza e assunzione di responsabilità.
L’aspetto più convincente dell’argomentazione di Torvalds riguarda l’accesso. Esplorare la programmazione diventa più facile quando un principiante può descrivere un’idea, ricevere una bozza funzionante e modificarla attraverso una conversazione.
Quel ciclo di feedback può mantenere coinvolto chi sta imparando. Invece di trascorrere la prima sessione a risolvere problemi di installazione o a memorizzare sintassi, la persona può vedere un risultato e ispezionare gradualmente il suo funzionamento.
Per gli sviluppatori esperti, gli stessi strumenti possono colmare lacune di conoscenza più circoscritte. Un programmatore del kernel potrebbe aver bisogno di un’interfaccia utente, di un test harness o di uno script in un linguaggio poco familiare. L’AI può offrire un punto di partenza senza richiedere settimane di specializzazione non correlata.
Si tratta di un legittimo guadagno di produttività. È anche diverso dall’affidare a un modello un’intera modifica sensibile per la sicurezza. Lo sviluppatore del primo scenario comprende già il sistema desiderato e può porre limiti al componente che non conosce.
La distinzione si indebolisce quando gli utenti non possono valutare l’output. Un principiante potrebbe credere che un programma funzioni perché supera un solo test visibile. Un ingegnere esperto potrebbe non rilevare un errore al di fuori della propria specializzazione perché la spiegazione generata sembra credibile.
Ecco perché “human in the loop” può diventare una rassicurazione vuota. Una persona che approva un output non garantisce una supervisione significativa. Il revisore deve disporre di contesto, tempo e autorità sufficienti per rilevare un fallimento.
La regola del kernel sulla firma umana definisce chi risponde delle conseguenze, ma non può creare competenza dal nulla. Chi invia un contributo può firmare una patch che non comprende davvero. I maintainer hanno comunque bisogno di prove tecniche e di una partecipazione reattiva.
Il codice generato solleva anche questioni irrisolte sulla provenienza. I modelli possono riprodurre schemi familiari senza fornire una storia chiara per uno specifico output. I contributori devono assicurarsi che il lavoro inviato soddisfi i requisiti di licenza GPL-2.0-only del kernel, anche quando il modello non può spiegare ogni influenza derivante dall’addestramento.
La politica di Linux non pretende di risolvere discussioni più ampie sui dati di addestramento o sul copyright. Stabilisce un confine per i contributi: chi li invia deve essere in grado di fornire la certificazione legale già esistente.
La sicurezza introduce un’altra incertezza. I sistemi AI possono scoprire bug lungo percorsi di codice dimenticati, a vantaggio del progetto. Possono anche creare una pipeline efficiente per produrre segnalazioni superficiali di vulnerabilità su una scala che sovraccarica i canali di segnalazione privati.
La segnalazione pubblica crea rischi diversi. Una divulgazione immediata può esporre gli utenti prima che i maintainer possano preparare e distribuire una correzione. La segnalazione privata protegge il coordinamento, ma diventa inefficace se i suoi canali si riempiono di segnalazioni duplicate o fabbricate.
I commenti di Torvalds suggeriscono che Linux non risolverà questa tensione respingendo l’AI in blocco. All’inizio del 2026, ha sostenuto che Linux non fosse un progetto anti-AI e che gli strumenti dovessero aiutare i maintainer invece di creare loro problemi.
Questo standard mette sotto pressione chi sviluppa questi strumenti. Il successo non può essere misurato solo dal numero di difetti individuati, patch prodotte o commenti di revisione generati. Un sistema utile deve ridurre lo sforzo umano totale necessario per arrivare a una decisione corretta.
Per un agente che trova bug, ciò significa riproduzioni, valutazione dell’impatto, rilevamento dei duplicati e prove collegate a percorsi di codice specifici. Per un generatore di patch, significa modifiche mirate, test e spiegazioni che resistano alla revisione degli esperti.
Per gli agenti di revisione, l’utilità significa identificare difetti rilevanti senza sommergere i maintainer di avvisi speculativi. Precisione e priorità contano più di un elevato numero di commenti.
La stessa lezione si applica all’interno delle aziende che adottano sistemi AI per la programmazione. Misurare le righe generate o i suggerimenti accettati può premiare il volume senza rivelare il costo di manutenzione. I team devono monitorare tempi di revisione, regressioni, rilavorazioni, tassi di incidenti e responsabilità a lungo termine.
L’entusiasmo personale di Torvalds non invalida queste preoccupazioni. Le rende più nette. Se uno sviluppatore che comprende i rischi del kernel trova comunque l’AI piacevole e utile, un rifiuto totale lascerebbe sul tavolo vantaggi significativi.
Se Linux accettasse tutto l’output generato senza controlli aggiuntivi, trasferirebbe i costi nascosti della tecnologia ai maintainer. La direzione attuale del progetto cerca di preservare la sperimentazione rifiutando al contempo questo trasferimento.
Cosa deve dimostrare ora la comunità Linux
La politica AI di Linux avrà successo solo se i contributi generati diventeranno più facili da verificare, prioritizzare e mantenere rispetto all’attuale flusso in arrivo.
Il primo segnale da osservare è il modo in cui il kernel applica le proprie regole di divulgazione nella revisione ordinaria. La documentazione formale è importante, ma la pratica coerente determinerà se i contributori capiscono quando usare Assisted-by e quali informazioni si aspettano i revisori.
Una divulgazione troppo ampia potrebbe produrre metadati ripetitivi di scarso valore. Una divulgazione debole potrebbe nascondere un’automazione significativa e privare i revisori del contesto. L’equilibrio utile emergerà attraverso invii reali, feedback dei maintainer e revisioni delle linee guida.
Il secondo segnale è se l’automazione della revisione riduce il carico creato dalla generazione. Torvalds ha osservato che i progetti stanno già usando l’AI per revisionare patch assistite dall’AI, creando talvolta l’impressione di bot che parlano con bot.
Questo ciclo non è automaticamente assurdo. L’analisi statica controlla già codice generato dalle macchine e codice scritto da esseri umani. Un revisore AI può svolgere un ruolo simile se le sue rilevazioni sono precise, riproducibili e subordinate a maintainer responsabili.
Il pericolo emerge quando un sistema incerto convalida un altro sistema incerto e gli esseri umani trattano l’accordo come una prova. Più modelli possono ripetere la stessa ipotesi errata. Le pipeline di revisione devono basarsi su test, risultati di build, comportamento a runtime e analisi del codice tracciabile, anziché sul consenso dei modelli.
Osservate gli strumenti che allegano una verifica concreta a ogni rilevazione. Una segnalazione che include un riproduttore, la configurazione interessata, il risultato del test e una patch minima è più preziosa di un paragrafo sicuro di sé che descrive un possibile difetto.
Il terzo segnale è il carico di lavoro dei maintainer. Se le segnalazioni di sicurezza duplicate diminuiscono, le patch di scarso valore ricevono un triage più rapido e i contributori utili restano coinvolti durante la revisione, il modello di accettazione controllata di Linux apparirà sostenibile.
Se le code continuano a crescere e i maintainer esperti si esauriscono, i progetti avranno ragioni più forti per imporre limiti più severi. L’esito rilevante non è quanto codice generato dall’AI entri nell’albero. È se la comunità riesce a preservare la qualità della revisione senza esaurire le persone responsabili.
I fornitori di strumenti dovrebbero considerare questo esito un requisito di prodotto. Un agente che produce dieci patch creando venti ore di lavoro di revisione non ha fornito dieci unità di produttività.
Anche gli sviluppatori dovrebbero distinguere tra sperimentazione e contributo. Il vibe coding, ovvero la programmazione iterativa attraverso prompt in linguaggio naturale, può funzionare bene per un prototipo usa e getta. Portare codice upstream richiede comprenderne comportamento, storia, test e conseguenze di manutenzione.
È in questa transizione che il supporto di Linus Torvalds alla programmazione AI diventa più utile come guida. Iniziate con un compito delimitato. Usate l’AI dove è utile. Ispezionate ciò che crea. Testate il risultato, spiegatelo con parole vostre e assumetevene la responsabilità prima di chiedere a un’altra persona di revisionarlo.
I principianti non dovrebbero interpretare la cautela come un motivo per evitare l’AI. La metafora della “gateway drug” di Torvalds riconosce che strumenti accessibili possono creare la motivazione necessaria per imparare. Il passo successivo consiste nel trasformare un successo generato in una comprensione autentica.
Gli ingegneri esperti non dovrebbero interpretare la propria competenza come un’immunità dagli errori. La fluidità può incoraggiare un’eccessiva fiducia, in particolare quando un modello produce codice plausibile in un dominio non familiare. I sistemi seri richiedono una verifica indipendente anche quando il primo risultato appare rifinito.
I maintainer, nel frattempo, hanno bisogno dell’autorità per definire quale assistenza aiuti davvero il loro progetto. Linux può supportare l’AI senza obbligare ogni responsabile di sottosistema ad accettare lavoro generato dalle macchine senza limiti.
Il modello emergente del kernel è esigente ma coerente. Gli strumenti possono partecipare. Gli esseri umani devono dichiarare l’assistenza sostanziale, soddisfare le regole di licenza, comprendere i propri invii e restare responsabili delle conseguenze.
Questo approccio non porrà fine al dibattito open source sui contenuti generati dagli LLM. I diversi progetti affrontano rischi e capacità di revisione differenti. Tuttavia, sposta il dibattito dall’identità alle operazioni.
I prossimi mesi dovrebbero rivelare se Linux riuscirà a trasformare questo principio in un flusso di lavoro gestibile. Gli sviluppatori possono contribuire a rispondere alla domanda già ora: prima di inviare lavoro assistito dall’AI, verificate che faccia risparmiare tempo ai maintainer anziché limitarsi a far risparmiare tempo alla persona che lo ha generato.
