Greg Kroah-Hartman, il numero due del kernel Linux, ha tracciato una linea netta: l’area staging non accetterà più patch generate da large language model. Lo ha comunicato in risposta all’“assalto” di contributi di bassa qualità — prodotti da IA e spediti come pull request, quasi sempre inutili, spesso deleteri per il tempo già scarso dei maintainer. C’è però una finestra che resta aperta: le correzioni di sicurezza autentiche, quelle che chiudono vulnerabilità reali e verificabili.

La scelta non è un semplice aggiornamento di policy. Kroah-Hartman usa personalmente strumenti di intelligenza artificiale nella manutenzione del kernel, il che rende la decisione meno ideologica di quanto appaia. Il punto è lo scopo dell’area staging: un ambiente dove i nuovi arrivati imparano l’arte del kernel hacking attraverso la revisione e la scrittura di codice. Inondarlo di patch scritte da un LLM non solo vanifica quella funzione didattica, ma aumenta il rumore, minando la sostenibilità del processo. La mossa dice con chiarezza che il valore del contributo umano, con il suo carico di apprendimento e di responsabilità, non è rimpiazzabile da un generatore automatico, per quanto fluente.

L’eccezione per i fix di sicurezza è, in realtà, il dettaglio più rivelatore. Qui l’IA può essere un amplificatore: la capacità di scandagliare codice e segnalare pattern sospetti ha portato alla scoperta di bug che, convalidate manualmente, meritano integrazione immediata. Kroah-Hartman non cita numeri, ma la direzione è inequivocabile: quando la posta in gioco è la protezione da attacchi, un contributo validato diventa accettabile, indipendentemente dalla sua origine algoritmica. Non è un lasciapassare automatico. La verifica umana rimane la condizione, e il modello è semmai un detective, non un autore a cui delegare la scrittura.

Chiunque segua le architetture on-premise e la governance dei dati riconoscerà in questa manovra un principio trasversale. In un’organizzazione che decide di auto-ospitare LLM per accelerare lo sviluppo o la security, il valore dell’output dipende esattamente dallo stesso anello: la verifica strutturata da parte di esperti. Il kernel Linux, con la sua community e il suo workflow trasparente, è un banco di prova estremo. Nei contesti enterprise che operano su infrastrutture locali per ragioni di sovranità o di TCO, la fiducia in un LLM non si compra con una licenza, ma si costruisce con pipeline di revisione che ricordano molto la strategia di Kroah-Hartman: accogliere le segnalazioni che superano l’esame, scartare senza pietà il resto.

L’annuncio segnala anche una maturità più ampia nel mercato. Non è un rifiuto dell’IA, ma un rifiuto dell’IA usata senza criterio. Mentre fioccano tool che promettono commit automatici e refactoring miracolosi, il kernel fissa il paletto: il codice critico esige uno sguardo umano, e l’intelligenza artificiale può affiancarlo, non sostituirlo. Per chi sviluppa in ambienti air-gapped o regolati, questa postura è un promemoria: il deployment on-premise di un LLM per attività di security scanning o sviluppo ha senso se accompagnato da un framework di validazione altrettanto solido. L’eccezione per il fix di sicurezza è la prova che il gioco vale la candela solo quando il controllo rimane ferreo.