Il ramo stabile Linux 7.3 non è ancora stato pubblicato — mancano circa tre settimane — ma una parte delle correzioni di rete è già stata dirottata alla versione 7.4. Il motivo non è tecnico nel senso tradizionale: i manutentori del sottosistema networking del kernel si dicono "completamente sopraffatti" dall'attività di patch e dalle segnalazioni di bug generate da agenti AI/LLM, oltre a dover respingere patch di bassa qualità definite "slop".

Il networking nel kernel Linux è un territorio vasto: driver cablati e wireless, protocolli, code path critici. Per un agente LLM è un'area ideale per produrre analisi e proposte, perché c'è tanto codice e tanta storia. Ma la quantità non equivale a qualità. Una patch che sembra plausibile può nascondere regressioni sottili, e verificarla richiede tempo e contesto che non si automatizza.

Il vero collo di bottiglia è la revisione umana

Qui sta il punto strutturale. Gli LLM hanno abbassato il costo marginale della generazione di contributi quasi a zero. Il costo marginale della revisione umana, invece, resta alto e legato a persone esperte che sono poche. È un disequilibrio: più agenti producono, più i manutentori filtrano, e meno tempo resta per le correzioni legittime. Il risultato è che fix veri vengono spostati in avanti, non perché non siano pronti, ma perché il canale di ingresso è intasato.

Per chi gestisce infrastrutture self-hosted — nodi Kubernetes, stack di inference locale, storage collegato in rete — la stabilità del kernel networking non è un dettaglio. È il tessuto che tiene insieme container, CNI e traffico est-ovest. Se l'overhead di triage rallenta l'integrazione delle correzioni, i tempi di esposizione a bug e vulnerabilità possono allungarsi. Non è una previsione, ma una conseguenza diretta del collo di bottiglia descritto dai manutentori. In questo senso la vicenda segnala un rischio operativo per chi fa deployment on-premise, dove la sovranità e il controllo passano anche dalla capacità di applicare patch tempestive.

Chi ci perde sono innanzitutto i manutentori, figure già scarse. Ci perde anche la qualità percepita del processo: una patch AI non revisionata può erodere fiducia e spingere a filtri più aggressivi. Chi può guadagnare, paradossalmente, sono i fornitori di piattaforme e strumenti di triage che aiutano a classificare e scartare il rumore. Ma il punto non è schierarsi contro gli LLM; è che il kernel Linux sta diventando un caso di studio su come un progetto critico assorbe un'ondata di contributi generati artificialmente. La risposta non è solo tecnica, è di governance del processo.