Linux 7.4-rc1: il valore dell’AI si misura prima della stabilizzazione

Quasi ventimila commit in due settimane. È il numero che accompagna Linux 7.4-rc1, annunciato da Linus Torvalds il 1° novembre 2026. Un numero enorme, facile da trasformare in un titolo sull’intelligenza artificiale che ormai scriverebbe il kernel al posto degli sviluppatori. Peccato che la notizia interessante sia un’altra: quando arriva il lavoro prodotto o innescato dall’AI, e in quale fase qualcuno deve verificarlo.

Nel messaggio originale alla Linux Kernel Mailing List, Torvalds si dice più soddisfatto di vedere le correzioni legate all’AI entrare nella normale finestra di integrazione anziché concentrarsi nel periodo delle release candidate. Non è un’approvazione indiscriminata del codice generato. È un’osservazione sul funzionamento di un processo di sviluppo, con una cautela importante: bisognerà vedere come andranno le prossime -rc.

La merge window non è la stabilizzazione

Per capire perché questa distinzione conti, bisogna separare due momenti che spesso vengono messi nello stesso calderone. Dopo una release stabile, la merge window è la finestra nella quale confluiscono le modifiche preparate dai vari sottosistemi: nuove funzionalità, aggiornamenti, pulizie e correzioni già passate attraverso i rispettivi maintainer. Con la prima release candidate, -rc1, quella finestra si chiude e inizia la fase nella quale l’obiettivo principale è stabilizzare il risultato.

Non significa che dopo -rc1 non si tocchi più nulla. Si correggono regressioni, si valutano fix e si risolvono problemi emersi dai test. Ma il contesto cambia: il codice integrato deve convergere verso una release affidabile. Una correzione che arriva tardi può essere necessaria, eppure introduce un nuovo elemento da comprendere e verificare quando il margine temporale è più stretto.

È qui che la lettura di Torvalds diventa interessante. Se strumenti automatici trovano problemi prima, e quei problemi entrano nel normale percorso di sviluppo, il progetto può distribuirne la valutazione lungo una fase già organizzata per integrare cambiamenti. Se invece una massa di fix arriva durante la stabilizzazione, anche un lavoro tecnicamente valido può trasformarsi in pressione aggiuntiva sulla review. Questa è la logica del suo giudizio, non una misura già dimostrata di quanto l’AI abbia migliorato la qualità del kernel.

AI-triggered non significa AI-merged

C’è una differenza sostanziale fra un difetto individuato con l’aiuto di un modello, una patch proposta da un modello e una modifica integrata nel repository. Sono tre passaggi diversi, con responsabilità diverse. Torvalds osserva che in questo ciclo ci sono molte correzioni di problemi trovati tramite AI e che, sempre più spesso, anche le patch vengono suggerite da AI. Aggiunge però che quelle proposte vengono frequentemente riscritte.

Quella riscrittura non è un dettaglio imbarazzante da nascondere nel comunicato. È parte del lavoro. Il codice deve rispettare invarianti che non emergono da un singolo test, convenzioni del sottosistema, interazioni con altri componenti e una storia di decisioni che un suggerimento automatico non può dare per scontata. Il maintainer non è il correttore ortografico di una pull request: è il soggetto che si assume il rischio dell’integrazione.

In un altro contesto avevo già affrontato il tema degli agenti che trovano bug e devono portare test eseguibili. Qui c’è un livello ulteriore: anche quando il test dimostra un problema reale, bisogna decidere in quale ciclo e con quali garanzie far entrare la correzione. La prova del difetto è necessaria; non è ancora la prova che una patch sia pronta per la release.

Il valore di una correzione non dipende soltanto dal fatto che funzioni. Dipende anche da quanto è verificabile, da chi se ne assume la responsabilità e dal momento in cui entra nel sistema.

Ventimila commit non sono ventimila patch scritte dall’AI

Torvalds parla di quasi 20.000 commit nella merge window di Linux 7.4, contro una quantità abituale vicina a 15.000. Sono numeri di attività complessiva, non un censimento delle modifiche generate da modelli. Il feed di LWN quantifica inoltre 18.591 changeset non-merge: è un conteggio con un perimetro differente, che non va mescolato a quello arrotondato del messaggio di Torvalds.

C’è un secondo equivoco. Il diff è molto grande, ma secondo Torvalds circa un terzo della sua dimensione deriva da header con offset e maschere dei registri AMD GPU. Non significa che un terzo dei commit riguardi quelle righe, né che un terzo delle funzionalità del kernel sia dedicato alle GPU. Commit, righe modificate e lavoro di revisione non sono la stessa unità di misura. Un file generato può occupare molto spazio e richiedere un tipo di controllo completamente diverso da una piccola modifica alla gestione della memoria.

L’annuncio cita aggiornamenti ai driver, alle architetture, ai filesystem, agli strumenti di performance e ai selftest, oltre a componenti centrali come networking, Rust, BPF e memory management. Non è quindi corretto raccontare 7.4-rc1 come una release fatta esclusivamente di patch AI. È un ciclo ampio, con contributi di natura molto diversa. E la possibile futura classificazione di Linux 7.4 come LTS è, al momento, un’aspettativa richiamata da Torvalds, non una designazione ufficiale già acquisita.

Il costo di una patch cambia a seconda di quando la presenti

Immaginiamo due correzioni tecnicamente identiche. La prima arriva con una serie di test riproducibili, durante il lavoro ordinario del sottosistema, e viene discussa insieme alle altre modifiche previste. La seconda arriva quando la release candidate è già in stabilizzazione, dopo che altri componenti hanno iniziato a testare il comportamento integrato. Non è detto che la seconda sia sbagliata: potrebbe correggere una regressione grave. Ma il costo della sua verifica può essere diverso, perché bisogna anche chiedersi che cosa rischi di disturbare in una fase in cui si cerca di ridurre le variabili.

Questo ragionamento vale oltre Linux. Un sistema che automatizza la scoperta di problemi senza progettare il percorso successivo può spostare il collo di bottiglia dall’analisi alla decisione. Se le segnalazioni arrivano con priorità, riproduzione, ambito del cambiamento e test di regressione, diventano più facili da trattare. Se arrivano soltanto come output voluminosi, la velocità della macchina può trasformarsi in lavoro aggiuntivo per chi mantiene il software.

C’è anche un precedente utile sullo stesso kernel: nell’analisi del caso Linux e Claude Code sul contatore nella page cache, il punto tecnico era capire un collo di bottiglia specifico, non celebrare lo strumento che aveva aiutato a individuarlo. Qui cambia la scala: il problema non è un singolo contatore, ma il modo in cui migliaia di interventi entrano in una macchina organizzativa fatta di maintainer, rami e finestre di rilascio.

Come capire se il modello è davvero più sano

La frase più prudente del messaggio di Torvalds è quella rivolta al futuro: bisognerà vedere come si comporteranno le release candidate. È la differenza fra un segnale promettente e una conclusione. Se il lavoro è stato assorbito meglio nella merge window, ci si può aspettare, come ipotesi da verificare, meno correzioni tardive inattese e un percorso di stabilizzazione più ordinato. Ma il numero di commit di -rc1, da solo, non lo dimostra.

Le osservazioni che contano più del totale dei commit

• Regressioni emerse dopo -rc1: quali comportamenti si rompono davvero nei test dei sottosistemi e nell’uso reale, e quanto tempo serve per correggerli?
• Qualità delle segnalazioni: i problemi arrivano con un caso riproducibile, una spiegazione del rischio e test che possono essere rieseguiti?
• Pressione sulle fasi finali: le successive -rc ricevono correzioni ordinarie e mirate oppure continuano a caricarsi di cambiamenti difficili da valutare?
• Responsabilità della modifica: chi ha controllato gli effetti collaterali, chi mantiene il codice e quali verifiche hanno accompagnato l’integrazione?

Non sono indicatori che possano essere letti tutti in un unico grafico pubblico, né una classifica automatica fra release. Sono domande operative. Evitano però di scambiare un aumento dell’output per un miglioramento del processo. La stabilità non si ottiene contando righe, e la qualità della review non si deduce dal numero di prompt inviati a un modello.

La vera maturità dell’AI è stare dentro un processo

La notizia di Linux 7.4-rc1 non è che Torvalds abbia consegnato il kernel all’intelligenza artificiale. Non lo ha fatto. Ha osservato che il lavoro innescato dall’AI sembra arrivare più spesso nel punto del ciclo in cui può essere gestito come sviluppo ordinario, e ha detto di considerarlo un segnale positivo. Ha anche ricordato che molte patch vengono riscritte, che il volume ha cause concorrenti e che la verifica vera arriverà con le prossime release candidate.

È una lezione meno appariscente di un benchmark, ma più utile a chi costruisce software: non basta aumentare la capacità di produrre analisi, codice o correzioni. Devi sapere dove farle entrare, come verificarle, quando fermarle e chi risponde del risultato. Se manca questa parte, hai accelerato un pezzo della catena e lasciato il resto a rincorrerlo. Se funziona, l’AI smette di essere un evento eccezionale e diventa uno strumento che il sistema sa governare.