Il kernel Linux è da tempo uno dei bersagli preferiti per chi sperimenta con la generazione automatica di codice. Patch firmate da esseri umani, patch firmate da pseudonimi e, sempre più spesso, patch prodotte da agenti LLM finiscono nelle mailing list dei manutentori. Oggi, però, arriva un segnale diverso: un patch set propone di aggiungere al repository un file AGENTS.md, un documento Markdown pensato per dare istruzioni agli agenti LLM. Finora il kernel non lo aveva, nonostante il volume di contributi generati da intelligenza artificiale sia cresciuto in modo evidente.

La differenza rispetto a un semplice filtro anti-spam è la direzione del controllo. Invece di limitarsi a scartare le patch di bassa qualità, chi mantiene il kernel inizierebbe a definire le regole con cui un agente dovrebbe preparare e proporre il proprio contributo. Un AGENTS.md non forza nessuno a rispettare le istruzioni, ma crea un punto di riferimento verificabile: se un agente ignora il file, i manutentori possono chiudere la patch con meno discussione; se lo segue, la parte meccanica del lavoro diventa più prevedibile. È un passaggio da una moderazione reattiva a una specifica di comportamento.

Questa mossa ha implicazioni che vanno oltre la burocrazia del kernel. Linux è un progetto che sopravvive grazie a un equilibrio delicato tra fiducia, reputazione e controllo. Quando gli agenti LLM producono codice, il confine tra autore e strumento si sfoca. Un file AGENTS.md non risolve il problema dell'attribuzione, ma introduce un contratto minimo per chi usa modelli per contribuire a infrastrutture critiche. Chi lavora in ambienti self-hosted, dove il codice generato da modelli locali non lascia i propri server, può vedere in questa proposta un precedente: le policy di sviluppo andrebbero esplicitate anche per i sistemi automatici interni, non solo per i collaboratori umani.

Per i manutentori del kernel il beneficio immediato è una base più solida per respingere contributi automatici mal formati. Per gli sviluppatori che usano LLM in buona fede, il file abbassa il costo di capire come partecipare. Per chi produce patch a basso sforzo, invece, l'esistenza di istruzioni esplicite rende più difficile nascondersi dietro l'ambiguità. Non è un caso che la proposta arrivi in un momento in cui la qualità delle patch generate da agenti LLM è sotto osservazione in molti progetti aperti.

La domanda non è più se gli agenti LLM parteciperanno allo sviluppo del kernel, ma con quali regole saranno tenuti a farlo. Per chi osserva le architetture on-prem e locali, è un promemoria che la governance non riguarda solo i modelli, ma anche gli artefatti che quei modelli producono.