Il networking di Linux è sotto una pioggia di patch scritte da AI, e i maintainer iniziano a correre ai ripari. Dopo che il responsabile del sottosistema WiFi ha annunciato una regola di “revisione di tre secondi” per cestinare le contribuzioni palesemente generate da un LLM, la notizia si allarga: l’intero sottosistema networking sta annegando in codice prodotto da modelli linguistici. Non è un problema di poco conto. Il codice che gestisce i pacchetti a livello kernel è il tessuto connettivo di qualsiasi server, e quando si parla di deployment on-premise di Large Language Models, la rete diventa il sistema nervoso su cui viaggiano token, pesi e comunicazioni tra nodi.

Il fenomeno non è nuovo, ma la portata sta diventando strutturale. Patch inviate con nomi di variabili in stile “foo” e “bar”, errori logici mascherati da codice formalmente corretto, promesse di “pulizia” che introducono regressioni: il pattern è riconoscibile. Il maintainer del WiFi l’ha messa in chiaro: se una patch non mostra un reale ragionamento umano dietro, verrà respinta in pochi secondi, senza appello. Questo approccio drastico segnala una presa di posizione che va oltre il singolo sottosistema: la community open-source sta alzando un argine contro l’automazione senza controllo.

Per chi fa self-hosting di modelli LLM, la faccenda non è un semplice rumore di fondo da mailing list kernel. Immaginate un cluster di GPU A100 o H100, interconnesso tramite InfiniBand o anche solo TCP/IP su Ethernet, che serve inference a bassa latenza per applicazioni interne. Se una patch accettata con troppa leggerezza altera il comportamento dello stack TCP o introduce un deadlock nel driver di rete, l’intero servizio di inference può degradarsi in modo subdolo: throughput che cala senza motivo apparente, timeout inaspettati, peggio ancora, vulnerabilità sfruttabili da remoto. E quando i dati sono sensibili – si pensi a un’applicazione sanitaria o finanziaria ospitata on-premise proprio per garantire la sovranità dei dati – un buco del genere potrebbe vanificare l’investimento in isolamento e conformità.

C’è una tesi più profonda: l’ondata di patch AI scritte senza revisione umana non è solo un problema di QA del kernel, ma un campanello d’allarme per l’intera industria che costruisce stack AI locali. Il modello di sviluppo di Linux, basato sulla fiducia distribuita, si sta scontrando con la facilità con cui un LLM può produrre contribuzioni sintatticamente plausibili ma semanticamente fragili. È lo stesso identico trade-off che i team di ML affrontano quando usano il codice generato da AI per accelerare lo sviluppo del software di serving: la velocità iniziale si scontra con la robustezza a lungo termine. Senza un processo di validazione stringente, si rischia di iniettare debito tecnico nel cuore dell’infrastruttura.

La reazione dei maintainer di Linux Networking potrebbe fare scuola. Per le organizzazioni che gestiscono pipeline di inference self-hosted, il messaggio è netto: l’automazione va governata con policy chiare, review umane obbligatorie e test di regressione che vadano oltre la superficie. Non basta più fidarsi ciecamente di un diff che supera i controlli automatici. Serve un’analisi del contesto, proprio come quella che il “three second review” promuove: occhio allenato, conoscenza del dominio e diffidenza verso ciò che sembra troppo pulito per essere vero.

La posta in gioco è alta anche sul fronte del TCO. Un bug di rete introdotto da una patch AI, se non intercettato, può tradursi in ore di debug, fermi macchina e persino perdita di dati. In un deployment on-premise dove ogni GPU conta e l’efficienza energetica è monitorata al centesimo, un’interruzione della rete significa moltiplicare i costi operativi. E non è solo questione di soldi: è la credibilità dell’infrastruttura locale rispetto alla comodità del cloud. Se il self-hosting diventa sinonimo di instabilità perché il software di base è inquinato da contributi non verificati, l’attrattiva del modello on-prem rischia di sgonfiarsi, nonostante i vantaggi in termini di sovranità e controllo.

La vicenda Linux ci ricorda che l’AI non è solo una leva per accelerare lo sviluppo, ma anche un amplificatore di rischi sistemici quando viene applicata senza discernimento. Chi sceglie di portare gli LLM dentro casa propria, lontano dai data center dei grandi provider, deve includere nel calcolo dei rischi anche la qualità del codice che fa funzionare la rete. Non è fantascienza: è la stessa supply chain del software su cui poggia ogni server di inference. E se il custode del networking mainline dice basta, forse è il caso di ascoltarlo.