Il merge window del kernel Linux 7.3 si è chiuso con un paradosso che riguarda meno il codice e più l'economia della manutenzione open source. Il sottosistema di networking ha incassato aggiornamenti per reti cablate e wireless, ma insieme alle modifiche rilevanti è arrivata una quantità enorme di correzioni marginali. La provenienza è nota: molti di questi fix sono stati generati da agenti basati su LLM. I manutentori del networking non usano giri di parole: si dicono «completamente sommersi» dal churn di codice prodotto da questi modelli.

La dinamica è semplice da descrivere ma difficile da assorbire. Generare una patch con un LLM ha un costo marginale quasi nullo, mentre revisionarla richiede tempo, contesto e attenzione da parte di persone che sono già il collo di bottiglia del kernel. Il risultato è un trasferimento di costo: chi produce le patch con un agente automatico scarica sui maintainer il lavoro di verifica. Non si tratta di un problema di spam generico, ma di una forma di inquinamento del flusso di contribuzione che colpisce un'infrastruttura critica.

Per chi gestisce stack on-premise per inference o training, il punto non è astratto. Il kernel Linux è la base su cui girano container, driver di rete, storage distribuito e i runtime che servono modelli locali. Se i manutentori del networking devono dedicare più tempo a filtrare fix marginali, l'attenzione disponibile per le vulnerabilità serie e per le regressioni di performance si riduce. Il rischio non è un singolo bug, ma l'erosione della capacità di revisione umana su un componente che regola il traffico tra GPU, nodi e storage in un cluster self-hosted.

C'è anche un effetto di secondo ordine sul modello di fiducia. I manutentori potrebbero rispondere alzando le barriere: richieste di provenienza, test automatici più severi, o rifiuto di patch che non dimostrano un'analisi umana. Questo può rendere più difficile la vita ai contributori legittimi, mentre gli attori che producono patch in serie continuano a trovare modi per aggirare i filtri. È una corsa agli armamenti tra generazione automatica e revisione umana, con il codice del kernel come terreno di scontro.

Il segnale strutturale va oltre Linux. L'arrivo degli LLM sposta il collo di bottiglia dalla scrittura del codice alla sua verifica. In un contesto on-premise, dove il controllo della filiera software è parte del valore, questa asimmetria diventa un costo operativo: non basta più aggiornare il kernel, serve anche capire se il flusso di patch è sostenibile. Per chi valuta deployment on-premise, esistono trade-off tra controllo e manutenzione: su AI-RADAR la sezione /llm-onpremise offre strumenti analitici per pesarli.