Linus Torvalds afferma che l'IA ha reso normali gli enormi aggiornamenti del kernel Linux

Linus Torvalds ha accettato una nuova e difficile realtà: le revisioni assistite dall'IA stanno producendo più correzioni per il kernel Linux di quante i manutentori abbiano tradizionalmente gestito nelle fasi finali di un ciclo di rilascio. Il cambiamento è tornato visibile durante i test di Linux 7.2, dove aggiornamenti insolitamente ampi sono proseguiti fino al sesto e al settimo release candidate.

La storia che si sta diffondendo su Google News non riguarda semplicemente il fatto che l'IA abbia trovato bug in Linux. Gli strumenti di IA hanno cambiato il volume e la tempistica delle correzioni proposte, creando un conflitto tra una più ampia individuazione dei bug e un'ingegneria di rilascio controllata.

Questo conflitto conta perché Linux è alla base di piattaforme cloud, dispositivi Android, server, apparati di rete, ambienti di sviluppo e sistemi embedded. Un maggior numero di difetti individuati può migliorare questi sistemi, ma ogni modifica accettata crea anche un'altra opportunità di regressione.

Torvalds non sta quindi adottando né una posizione anti-IA né quella dell'automazione senza limiti. La sua regola emergente è più impegnativa: usare l'IA, comprenderne le rilevazioni, inviare contributi utili e preservare la responsabilità umana durante l'intero processo.

Linux 7.2 ha reso visibile il nuovo carico di lavoro

Le dimensioni dei release candidate tardivi di Linux 7.2 mostrano che la revisione assistita dall'IA è diventata una questione operativa, non un dibattito sul futuro.

Nel suo aggiornamento del 2 agosto, Torvalds ha definito Linux 7.2-rc6 “enorme”. Ha affermato che, misurato in base al numero di commit, sembrava essere il più grande sesto release candidate degli ultimi anni.

Un release candidate, o RC, è una versione di test pubblicata prima di una release stabile del kernel. Normalmente, i candidati più tardivi dovrebbero restringere il lavoro rimanente a regressioni e difetti gravi.

Il volume non è tornato ai livelli consueti una settimana dopo. Nel messaggio che annunciava Linux 7.2-rc7, Torvalds ha detto di non essere entusiasta delle sue dimensioni.

Ciononostante, ha descritto l'aggiornamento come la “nuova normalità”, con molte correzioni risultanti da revisioni effettuate da vari strumenti di IA. Il report su Linux 7.2 ha inoltre rilevato che le correzioni erano distribuite tra driver, filesystem, rete e codice specifico dell'architettura.

La maggior parte delle modifiche era di piccole dimensioni. Torvalds ha identificato tre aree più ampie riguardanti il supporto crittografico s390, l'infrastruttura Btrfs e gli IP set di Netfilter, ma non ha descritto il candidato come pericoloso.

Questa distinzione è importante. Un ampio insieme di patch non è automaticamente un cattivo insieme di patch, e un difetto scoperto dall'IA non è automaticamente una riparazione scritta dall'IA.

La preoccupazione immediata è il rischio cumulativo. Centinaia di modifiche singolarmente modeste possono richiedere un esteso lavoro di revisione, test, instradamento e follow-up.

Lo sviluppo Linux distribuisce questo onere tra i manutentori dei sottosistemi. Questi manutentori conoscono aree specifiche, raccolgono patch, le valutano e inviano pull request verso il kernel mainline.

L'IA può accelerare la scoperta senza espandere questa struttura di revisione umana allo stesso ritmo. Può produrre segnalazioni ininterrottamente, mentre i manutentori dispongono ancora di attenzione limitata e scadenze di rilascio.

Torvalds non ha ritenuto le modifiche di Linux 7.2 abbastanza gravi da giustificare un rinvio. Si aspettava che la release stabile arrivasse nel fine settimana successivo, salvo l'emergere di un nuovo problema significativo.

Quella decisione separa il volume dalla gravità. Linux 7.2 era ampio, ma le sue modifiche note restavano sufficientemente gestibili per il processo di rilascio consolidato.

Trasforma inoltre la release in un test utile. Se un candidato ampio e influenzato dall'IA viene distribuito senza regressioni gravi, i sostenitori ottengono prove che il flusso di lavoro può assorbire più segnalazioni.

Se i problemi emergeranno in seguito, il dibattito si sposterà verso controlli più rigidi su tempistiche e ammissione. La domanda centrale non è più se l'IA appartenga allo sviluppo del kernel. È dove il lavoro generato dall'IA debba collocarsi all'interno del calendario di rilascio.

Perché le revisioni IA stanno creando più modifiche al kernel

L'IA cambia l'economia dell'individuazione di codice sospetto, ma non elimina il costoso lavoro necessario per convalidare e integrare una correzione.

In precedenza, uno sviluppatore doveva dedicare molto tempo a ispezionare codice non familiare, seguire il flusso di controllo e cercare casi limite trascurati. Ora uno strumento di IA può suggerire condizioni problematiche in una base di codice molto più ampia.

Alcuni sistemi si comportano come assistenti per la revisione del codice. Altri combinano modelli linguistici con il fuzzing, un metodo di test che invia input inattesi al software per esporre crash o errori di memoria.

Questi strumenti sono particolarmente adatti a trovare piccole incongruenze. Possono rilevare controlli mancanti, percorsi di errore insoliti, schemi ripetuti e presupposti non corrispondenti tra funzioni correlate.

Linux contiene molte di queste opportunità perché supporta una straordinaria varietà di hardware e carichi di lavoro. I suoi driver, filesystem, componenti di rete e codice specifico dei processori riflettono decenni di decisioni ingegneristiche.

L'IA non ha bisogno di inventare un nuovo sottosistema per aumentare il volume delle patch. Basta trovare una condizione trascurata in ciascuno di molti componenti esistenti.

Questo meccanismo spiega perché l'aggiornamento attuale possa essere al tempo stesso enorme e composto soprattutto da piccole correzioni. L'automazione amplia la superficie di ricerca, quindi invia più potenziali difetti nei flussi di lavoro umani consolidati.

Greg Kroah-Hartman, manutentore del kernel stabile Linux, ha fornito un esempio concreto. Secondo quanto riportato, il suo cacciatore di bug assistito dall'IA e gestito localmente ha contribuito a quasi due dozzine di patch integrate a partire da aprile.

Il sistema funzionava su un desktop Framework dotato di processore AMD Ryzen AI Max+. Secondo una ricostruzione del cacciatore di bug locale, testava localmente i componenti del kernel anziché inviare codice a un servizio cloud.

Questa modalità di distribuzione conta per i progetti che gestiscono codice sensibile o non pubblicato. I modelli locali possono ridurre l'esposizione dei dati, anche se non risolvono le questioni relative ai dati di addestramento, alle licenze o alla qualità dell'output.

Il flusso di lavoro di Kroah-Hartman illustra anche la divisione del lavoro. Secondo quanto riportato, lo strumento ha trovato problemi candidati, mentre lui ha esaminato i risultati, preparato le correzioni e assunto la responsabilità delle segnalazioni.

Le sue dichiarazioni sulle patch utilizzavano un tag “Assisted-by”. Quel tag registra il coinvolgimento dell'automazione senza fingere che il software possa assumersi le conseguenze di una modifica sbagliata.

L'approccio è ben lontano dal chiedere a un chatbot di generare una patch e inoltrarne la risposta senza modifiche. Tratta l'IA come uno strumento di test insolitamente produttivo.

Questa distinzione spesso scompare nei titoli di Google News sulla programmazione IA. “Codice generato dall'IA” può descrivere diverse attività con profili di rischio molto differenti.

Un modello può riassumere una patch, segnalare codice sospetto, produrre un riproduttore, proporre una riparazione o scrivere gran parte di un nuovo componente. Riunire queste attività sotto un'unica etichetta oscura gli effettivi controlli ingegneristici.

Per Linux, il caso d'uso iniziale più solido sembra essere l'assistenza circoscritta. Un manutentore sceglie un obiettivo, esegue uno strumento, esamina le prove, scrive o verifica la riparazione e la invia attraverso la normale revisione.

Il caso d'uso più debole è la scoperta estemporanea. Una persona punta un modello generico al codice pubblico, inoltra qualunque cosa segnali e lascia ai manutentori il compito di stabilire se il problema sia reale.

Entrambi i flussi di lavoro aumentano il numero di messaggi. Solo uno aggiunge con coerenza il contesto e la responsabilità necessari per trasformare un'osservazione della macchina in software affidabile.

La capacità dei manutentori è ora il vero collo di bottiglia

Il principale vincolo si è spostato dall'individuazione di potenziali difetti alla decisione su quali rilevazioni meritino la scarsa attenzione dei manutentori.

Linux utilizza da tempo un processo di revisione gerarchico perché nessuna singola persona può valutare ogni modifica. I contributori lavorano con i manutentori dei sottosistemi, che filtrano e consolidano le patch prima che Torvalds le riceva.

L'IA può generare rilevazioni più rapidamente di quanto quella gerarchia possa reclutare revisori esperti. Il conseguente squilibrio mette pressione sui manutentori anziché sui modelli che producono l'output iniziale.

La pressione diventa più visibile nelle fasi finali di un ciclo di rilascio. Lo sviluppo del kernel normalmente si apre con una merge window per il lavoro pianificato, seguita da release candidate sempre più focalizzati sulla stabilizzazione.

Una correzione valida ma non urgente può essere comunque inappropriata durante un candidato tardivo. Modificare codice stabile per affrontare un caso limite di lunga data può introdurre una regressione poco prima del rilascio.

Torvalds ha sottolineato questo punto durante lo sviluppo di Linux 7.1. Dopo un quinto candidato insolitamente grande, ha affermato che sarebbe diventato più selettivo riguardo alle pull request contenenti correzioni a bassa priorità.

Diverse serie di patch erano state attivate dalla revisione IA. La sua preoccupazione non era che i difetti identificati fossero immaginari, ma che la loro tempistica creasse un'inutile turbolenza.

L'avvertimento sulle fasi finali del ciclo ha sottolineato che persino le correzioni banali comportano un rischio diverso da zero. Torvalds voleva che i manutentori distinguessero le regressioni dai problemi più vecchi che potevano attendere un'altra merge window.

Si tratta di ingegneria di rilascio convenzionale applicata a un aumento non convenzionale delle scoperte. La risposta corretta non è necessariamente un minor numero di correzioni. È una pianificazione migliore.

Lo stesso principio dovrebbe contare per i team di ingegneria aziendale che adottano la revisione IA. La capacità di uno strumento di trovare problemi aggiuntivi non significa che ogni risultato appartenga alla release corrente.

I team hanno bisogno di soglie di gravità, regole di responsabilità, deduplicazione e scadenze per le modifiche non critiche. Senza questi controlli, tassi di scoperta più elevati possono indebolire la prevedibilità delle consegne.

I fornitori di IA spesso valutano gli strumenti di programmazione attraverso misure di completamento dei compiti. I manutentori devono affrontare un diverso insieme di risultati: tempo di revisione, falsi positivi, lavoro duplicato, regressioni e follow-up irrisolti.

Queste misure operative determinano se un revisore IA fornisca valore netto. Uno strumento che identifica dieci difetti reali consumando settimane di attenzione di esperti può avere prestazioni peggiori di un sistema più circoscritto.

L'esperienza Linux mette inoltre in discussione l'ipotesi che la produttività della programmazione IA appartenga ai singoli sviluppatori. La velocità locale conta meno quando la coda di integrazione condivisa viene sovraccaricata.

Un contributore può generare più patch, ma il progetto ha ancora bisogno di qualcuno di fiducia che le ispezioni. Il guadagno di produttività diventa reale solo dopo che l'intero sistema di revisione ha elaborato il lavoro.

Questo crea un difficile problema di incentivi. La persona che invia un report automatizzato riceve il merito visibile della scoperta, mentre i manutentori assorbono gran parte del costo di verifica.

I progetti potrebbero rispondere richiedendo segnalazioni più solide. Un report utile potrebbe necessitare di un riproduttore, versioni interessate, analisi tecnica, una patch proposta e prove che il segnalante abbia verificato la presenza di duplicati.

L'IA può assistere anche in questi compiti. Il requisito importante è che chi invia la segnalazione resti coinvolto anziché trasferire un output della macchina non elaborato ai volontari.

Per i lettori che seguono l'argomento attraverso Google News, “più correzioni” suona come un miglioramento senza riserve. All'interno di un progetto software maturo, più correzioni significano anche più decisioni su rischio, tempistiche e responsabilità.

Il titolo di Google News nasconde una politica sull'IA a due facce

Torvalds accetta l'AI come utile strumento ingegneristico, ma respinge flussi di lavoro che scaricano sui manutentori i suoi errori e le sue duplicazioni.

La sua posizione può apparire incoerente se osservata attraverso dichiarazioni isolate. Ha criticato il rumore generato dall'AI, difeso il diritto di usarla e riconosciuto che la revisione automatizzata ha individuato difetti reali.

Nel loro insieme, queste affermazioni delineano una politica coerente. Il valore tecnico conta più del fatto che un problema sia stato notato per primo da una persona o da una macchina, ma i contributori umani restano responsabili di ciò che arriva nel progetto.

A maggio, Torvalds ha dichiarato che un'ondata di segnalazioni di sicurezza generate dall'AI aveva reso quasi ingestibile la mailing list privata del kernel dedicata alla sicurezza. Più persone individuavano gli stessi problemi usando strumenti simili.

Le segnalazioni duplicate producono più del semplice disordine nella casella di posta. Qualcuno deve confrontarle, individuare le discussioni precedenti, identificare il sottosistema corretto e stabilire se esiste già una correzione.

Torvalds ha sostenuto che molti bug rilevati dall'AI non dovrebbero confluire automaticamente in un canale privato. Se diversi strumenti pubblici possono trovare lo stesso problema, trattare ogni risultato come segreto può impedire ai segnalatori di vedere il lavoro già svolto.

La sua critica era rivolta direttamente all'assenza di valore aggiunto. Il sovraccarico delle segnalazioni di sicurezza lo ha mostrato mentre chiedeva ai contributori di comprendere la documentazione, creare patch e sviluppare il risultato automatizzato.

Due mesi dopo, ha tracciato un confine altrettanto netto contro l'opposizione indiscriminata. Torvalds ha affermato che Linux non era un progetto anti-AI e ha detto agli obiettori che l'open source consentiva loro di fare un fork del codice.

Ha descritto l'AI come uno strumento, sebbene possa creare difficoltà per i manutentori e portare alla luce bug imbarazzanti. La soluzione, a suo avviso, è fare in modo che gli strumenti aiutino i manutentori.

Questo non è un sostegno allo sviluppo autonomo del kernel. È un sostegno all'uso dell'automazione nel rispetto degli standard tecnici del progetto.

Il conflitto principale è quindi tra automazione utile e automazione senza responsabilità. L'origine di una scoperta conta meno della qualità delle prove e della responsabilità che la accompagna.

Questo quadro ricorda il modo in cui il kernel tratta altri strumenti. Compilatori, analizzatori statici, fuzzers, suite di test e trasformazioni mediante script possono tutti generare o influenzare modifiche.

Nessuno di essi diventa un manutentore. Una persona identificata continua a inviare la patch, spiegarla, rispondere alle critiche, rivedere il codice e affrontare i problemi successivi.

I modelli linguistici complicano questo assetto perché il loro output può sembrare convincente senza essere fondato sul comportamento reale del codice. Possono inoltre generare spiegazioni su una scala tale da sovraccaricare i revisori.

La divulgazione aiuta, ma da sola non può garantire la qualità. Un tag “Assisted-by” informa i revisori che uno strumento ha partecipato; non dimostra che il contributore abbia compreso il risultato.

I divieti presentano il problema opposto. Un progetto può proibire l'assistenza dell'AI, ma individuare l'uso non dichiarato resta difficile. Divieti rigidi possono incoraggiare l'occultamento senza ridurre gli invii di bassa qualità.

Torvalds ha già sostenuto che la documentazione del kernel dovrebbe concentrarsi sui contributori responsabili invece di trasformarsi in una dichiarazione politica sull'AI. La controversia sulla documentazione ha mostrato la sua preferenza per trattare l'AI come un altro strumento, applicando al contempo gli standard esistenti.

Questa posizione evita un test irrisolvibile sull'attribuzione della paternità. I revisori possono invece porre domande che già conoscono: la patch è corretta, necessaria, testata, spiegata chiaramente e inviata al momento giusto?

La politica resta esigente perché l'AI riduce il costo di produrre risposte plausibili a queste domande. I manutentori avranno bisogno di prove, non di prosa raffinata.

Un riproduttore, un caso di test, un benchmark o una traccia hanno più peso di una spiegazione sicura di sé. I contributori assistiti da strumenti devono mostrare come hanno verificato le proprie affermazioni.

Questa è la sfumatura che un breve riepilogo di Google News può trascurare. Torvalds non sta né consegnando lo sviluppo di Linux ai modelli né proteggendolo da ogni coinvolgimento dell'AI.

Sta consentendo all'automazione di ampliare la visione del progetto, insistendo però affinché gli esseri umani continuino a sostenerne il giudizio.

Più correzioni non significano automaticamente un kernel più sicuro

La scoperta assistita dall'AI può migliorare la sicurezza, ma il solo volume di patch non può dimostrare che il kernel risultante sia più sicuro o più stabile.

Un bug scoperto è soltanto l'inizio di un processo di riparazione. Gli ingegneri devono confermare il comportamento, valutarne l'impatto, progettare una correzione, testare le configurazioni interessate ed esaminare se la modifica crea un altro problema.

Linux rende questo lavoro particolarmente difficile perché una patch può interessare molte architetture, compilatori, dispositivi e carichi di lavoro. Una correzione testata su una macchina può comportarsi diversamente altrove.

Anche piccole modifiche possono raggiungere percorsi di codice sensibili. La gestione degli errori, la proprietà della memoria, la concorrenza e le transizioni di stato dell'hardware producono spesso guasti che emergono solo in condizioni rare.

Gli strumenti AI possono identificare schemi che suggeriscono un difetto senza comprendere ogni vincolo di runtime. Le loro rilevazioni dovrebbero quindi essere trattate come ipotesi finché i test non le confermano.

I falsi positivi consumano tempo, ma la falsa sicurezza è il pericolo maggiore. Una patch plausibile può eliminare un sintomo lasciando intatta la causa principale.

L'automazione può anche creare errori correlati. Se molti ricercatori usano lo stesso modello o metodo di scansione, possono segnalare risultati identici e trascurare le stesse categorie di problemi.

Questa concentrazione riduce la diversità della revisione. Dieci segnalazioni automatizzate non offrono dieci prospettive indipendenti quando condividono le stesse ipotesi di base.

La divulgazione delle vulnerabilità aggiunge un'altra complicazione. Segnalare pubblicamente una vulnerabilità riproducibile prima che sia pronta una correzione può aiutare gli attaccanti oltre ai difensori.

Torvalds ha sostenuto che collocare automaticamente tutte le rilevazioni AI in una lista privata di sicurezza crea duplicazioni. Tuttavia, spostarle nei canali pubblici richiede un'attenta valutazione della sfruttabilità e degli utenti interessati.

Nessuna regola universale di instradamento funzionerà. I contributori devono avere competenze sufficienti per distinguere un innocuo problema di correttezza da una falla di sicurezza che richiede una gestione coordinata.

L'AI potrebbe in futuro assistere questo triage, ma automatizzare la fase di classificazione crea un ulteriore livello che i manutentori devono verificare. Il collo di bottiglia si sposta anziché scomparire.

Esistono inoltre poche prove pubbliche che colleghino le release candidate più grandi all'affidabilità nel lungo periodo. Torvalds ha attribuito molte correzioni alla revisione AI, ma tale osservazione non ne quantifica la gravità o il beneficio a valle.

Il numero di commit è un indicatore di carico di lavoro, non un punteggio di sicurezza. Una riparazione ad alto impatto può contare più di molte correzioni cosmetiche.

La stessa cautela vale per le affermazioni secondo cui l'AI sia diventata indispensabile. Gli strumenti producono rilevazioni utili, ma i loro costi complessivi includono hardware, funzionamento dei modelli, revisione umana, invii duplicati e rischio di regressioni.

Linux 7.2 offre un test nel mondo reale, anche se non un esperimento controllato. Gli sviluppatori possono osservare se la sua serie di candidate più ampia porta a gravi regressioni, correzioni d'emergenza o un carico insolito per il ramo stabile.

Dovrebbero inoltre esaminare quali modifiche assistite dall'AI superano la revisione. I tassi di rifiuto e la cronologia delle revisioni rivelerebbero più del numero grezzo di rilevazioni generate.

Una valutazione responsabile deve separare diverse domande. L'AI ha individuato un problema reale? Lo ha spiegato correttamente? Un essere umano ha creato la patch finale? I test hanno mostrato che la patch ha risolto il problema in sicurezza?

Ridurre questi passaggi a “l'AI ha corretto Linux” travisa il lavoro. Cancella inoltre i manutentori il cui giudizio trasforma l'output della macchina in codice accettato.

Le prove attuali supportano una conclusione più circoscritta. L'AI è diventata abbastanza valida da modificare il volume della revisione del kernel, ma non abbastanza affidabile da eliminare la supervisione degli esperti.

Cosa dovrebbero osservare ora sviluppatori e responsabili dell'ingegneria

La prossima fase sarà misurata attraverso la stabilità delle release, la qualità degli invii e i cambiamenti nel flusso di lavoro dei manutentori, piuttosto che attraverso un'altra discussione sull'ideologia dell'AI.

Il primo segnale è il comportamento di Linux 7.2 dopo il rilascio. Correzioni nel ramo stabile, regressioni e revert urgenti mostreranno se la serie di candidate insolitamente ampia è rimasta sotto controllo.

Un normale periodo post-rilascio rafforzerebbe la tesi di Torvalds secondo cui insiemi più ampi di aggiornamenti influenzati dall'AI possono rientrare nello sviluppo di Linux. Un picco di regressioni sosterrebbe limiti più rigidi nelle fasi finali del ciclo.

Il secondo segnale è la qualità degli invii assistiti dall'AI. Tag di divulgazione, casi di test completi, riproduttori funzionanti e il seguito garantito dai contributori indicherebbero che gli utenti stanno adottando flussi di lavoro responsabili.

Segnalazioni duplicate prive di analisi indicherebbero la direzione opposta. Mostrerebbero che la scoperta resta più facile da automatizzare della partecipazione responsabile.

Il terzo segnale riguarda gli strumenti per i manutentori. I contributori Linux potrebbero sviluppare o adottare sistemi che deduplicano le rilevazioni, instradano le segnalazioni al sottosistema corretto, classificano la gravità probabile e riconoscono i difetti già corretti.

Questi sistemi richiedono progettazioni conservative. Un filtro che sopprime erroneamente un problema grave può essere più dannoso di una casella di posta sovraccarica.

Le imprese dovrebbero seguire questi sviluppi perché i loro repository interni affrontano lo stesso problema di capacità. Aggiungere la revisione AI senza modificare le regole di triage può sommergere i team di lavoro durante periodi critici di consegna.

Un'implementazione utile inizia con un ambito ristretto. I team possono scegliere un sottosistema, definire le prove accettate, monitorare i falsi positivi e assegnare un responsabile umano per ogni invio assistito dalla macchina.

Dovrebbero misurare l'intero percorso, dalla rilevazione alla riparazione verificata. Il risultato rilevante non è quanti commenti produce uno strumento, ma quante correzioni affidabili raggiungono la produzione senza aumentare le regressioni.

Le organizzazioni hanno bisogno anche di regole temporali. Le rilevazioni AI non critiche dovrebbero entrare nel normale backlog di sviluppo invece di interrompere una release candidate o un ciclo di patch d'emergenza.

I team di sicurezza dovrebbero stabilire procedure separate per le vulnerabilità sospette. Il livello di fiducia di un modello non dovrebbe mai determinare se una segnalazione resta privata.

Gli sviluppatori hanno bisogno di aspettative chiare in materia di responsabilità. Chiunque invii lavoro assistito dall'AI dovrebbe comprendere il codice, riprodurre il problema, difendere la modifica proposta e restare disponibile dopo l'integrazione.

La documentazione può sostenere questo comportamento, ma non può sostituire il giudizio. L'esperienza di Linux suggerisce che la progettazione del flusso di lavoro conta più di una semplice autorizzazione o proibizione.

La gestione della conoscenza diventa rilevante con l'aumento della revisione automatizzata. I team hanno bisogno di archivi ricercabili delle rilevazioni precedenti, delle segnalazioni respinte, delle decisioni sui sottosistemi e dei modelli di duplicazione noti.

Una base di conoscenza ingegneristica può contribuire a preservare tale contesto tra revisioni del codice, note tecniche e discussioni sulle release. L'obiettivo è evitare che ogni nuova esecuzione dello strumento riavvii la stessa indagine.

Google News continuerà a inquadrare il dibattito attraverso dichiarazioni memorabili di Torvalds. La storia più importante si svilupperà nelle mailing list, nelle cronologie delle patch e nei registri delle release stabili.

Osservate se i contributori assistiti dall'AI iniziano a fornire lavoro ingegneristico completo anziché osservazioni isolate. Osservate se i manutentori acquisiscono strumenti che riducono i costi di instradamento e duplicazione. Soprattutto, osservate se Linux assorbe un volume maggiore di modifiche senza indebolire la stabilità.

La comunità del kernel è già andata oltre il chiedersi se gli sviluppatori useranno l'IA. La questione più difficile ora riguarda ogni team software: la scoperta automatizzata può crescere più rapidamente della revisione umana senza trasformare risultati utili in cambiamenti incontrollati?