Linus Torvalds: basta pull request tardive e fix generati dall'AI per il Kernel Linux

Linus Torvalds torna ad alzare i toni sullo sviluppo del kernel Linux e questa volta il bersaglio sono le pull request considerate inutili, tardive o generate con strumenti di Intelligenza Artificiale senza un reale controllo umano.

Il tema emerge durante la fase di rilascio di Linux 7.1, in particolare con la quinta release candidate, giudicata troppo grande e carica di modifiche marginali. Le sue parole arrivano in un momento delicato: l’adozione di tool AI per analisi statica, bug hunting e revisione del codice cresce rapidamente, ma molti maintainer segnalano problemi di qualità, duplicazioni e rumore operativo.

Il creatore del sistema operativo già in passato aveva dimostrato perplessità riguardo l’operato dell’AI, sia per quanto concerne il coding che nel contesto della sicurezza.

Patch tardive e qualità del codice

Durante il ciclo di sviluppo del kernel, Torvalds apre una merge window di circa due settimane in cui i maintainer inviano nuove funzionalità. Seguono le release candidate, identificate come rc1, rc2 e così via, dedicate alla correzione di bug e alla stabilizzazione. La critica riguarda proprio l’arrivo di modifiche non essenziali in questa fase avanzata: driver marginali, fix minori o patch che avrebbero potuto attendere il ciclo successivo.

Il problema non è la singola modifica, ma il cosiddetto “churn“: un’attività continua che aumenta la complessità del testing e rende più difficile garantire la stabilità finale. Anche una correzione apparentemente innocua può introdurre race condition o incompatibilità inattese. Torvalds ha dichiarato di voler diventare “più duro” nella gestione delle pull request tardive e non critiche, con l’obiettivo esplicito di ridurre il volume di cambiamenti nelle settimane che precedono il rilascio stabile.

Parte delle patch contestate deriva da sistemi AI usati per analizzare codice sorgente e suggerire fix automatici. Torvalds non attacca direttamente l’uso dell’AI, ma critica il modo in cui alcuni sviluppatori la impiegano: segnalazioni duplicate, modifiche senza priorità reale, patch inviate senza adeguata verifica tecnica. Negli ultimi mesi la mailing list dedicata alla sicurezza del kernel è diventata, a suo dire, “quasi ingestibile” a causa di questa duplicazione massiva: molti ricercatori usano gli stessi modelli AI sugli stessi repository, generando ondate di report identici su bug già corretti o vulnerabilità note.

Perché il kernel non perdona errori

Il kernel Linux non è un’applicazione tradizionale. Gestisce scheduling dei processi, memoria virtuale, networking, filesystem e comunicazione hardware a basso livello. Una regressione introdotta in un driver o in una API di un sottosistema può causare problemi al kernel, perdita di dati o criticità nel contesto della sicurezza difficili da tracciare. Per questo il processo di review prevede livelli multipli di verifica: maintainer di subsystem, test automatici, compilazioni cross-platform e revisione manuale.

Torvalds ha invitato gli sviluppatori a distinguere tra regressioni critiche e miglioramenti marginali: le prime richiedono intervento immediato, le seconde possono attendere il ciclo successivo. Gli LLM possono suggerire pattern sintatticamente corretti, ma spesso non comprendono vincoli architetturali complessi, dipendenze storiche o requisiti di compatibilità mantenuti da decenni. Una patch generata automaticamente rischia di apparire valida pur introducendo problemi invisibili ai test superficiali.