Linux, cambia la regola sull’AI: cosa succede alle patch del kernel

Il kernel Linux si prepara a rivedere il proprio approccio all’impiego dell’Intelligenza Artificiale nello sviluppo del codice.

Al centro del confronto c’è il tag Assisted-by, utilizzato per segnalare il contributo degli strumenti AI nella preparazione delle patch. La possibile eliminazione di questo obbligo rappresenta un cambiamento significativo nella gestione delle collaborazioni tra programmatori e sistemi generativi.

La discussione, riportata da Phoronix sulla base delle informazioni provenienti dalla comunità di sviluppo, evidenzia un’evoluzione nel modo in cui il progetto affronta l’integrazione di queste tecnologie. Il tema non riguarda soltanto la trasparenza nell’utilizzo degli strumenti, ma anche i criteri con cui valutare il lavoro proposto e le responsabilità di chi contribuisce al codice.

Perché il kernel Linux vuole rimuovere Assisted-by

La proposta di modifica è stata pubblicata sulla mailing list del kernel, dove sviluppatori e manutentori discutono gli interventi destinati al progetto. Durante il Linux Maintainers Summit tenutosi a Praga qualche giorno fa, sarebbe emerso un consenso tra i partecipanti sulla necessità di abbandonare questo requisito di attribuzione.

L’intervento proposto punta a eliminare la documentazione che descrive l’obbligo di inserire il tag nelle patch realizzate con il supporto di strumenti AI e modelli linguistici di grandi dimensioni (LLM). Non si tratta, quindi, di una semplice modifica estetica alle convenzioni di scrittura, ma di un ripensamento delle modalità con cui viene dichiarato il contributo degli strumenti automatici.

Il confronto, tuttavia, non è privo di divergenze. Nella mailing list sono emerse posizioni differenti: alcuni partecipanti sostengono la rimozione dell’etichetta, mentre altri ritengono utile conservare un’indicazione esplicita dell’assistenza ricevuta. Quest’ultima posizione riflette un’esigenza concreta di tracciabilità, soprattutto quando occorre comprendere come sia stato prodotto un cambiamento tecnico.

La proposta è dunque legata a una discussione ancora rilevante per le procedure di collaborazione. Come precisa la ricostruzione di Phoronix, l’orientamento dei manutentori lascia prevedere un possibile avanzamento dell’iniziativa, senza trasformare automaticamente il confronto in una decisione già definitiva.

Qualità del codice e responsabilità degli sviluppatori

Il significato più interessante di questa discussione riguarda il rapporto tra provenienza del codice e affidabilità del risultato. Un’etichetta può rendere visibile il ricorso a un assistente automatico, ma non dimostra, da sola, che una modifica sia corretta, sicura o coerente con l’architettura del progetto. Allo stesso modo, l’assenza di una dichiarazione non costituisce una garanzia sulla qualità del contributo.

Per un progetto aperto e complesso come Linux, diventa quindi centrale il modo in cui una patch viene esaminata, verificata e integrata. La revisione tecnica deve consentire di individuare errori, valutare gli effetti delle modifiche e stabilire se il codice soddisfi i requisiti richiesti. Il giudizio sul contributo non può dipendere esclusivamente dallo strumento utilizzato durante la sua preparazione.

Questa prospettiva non elimina l’importanza della trasparenza. Al contrario, invita a distinguere tra la dichiarazione del processo produttivo e la valutazione del prodotto finale. L’impiego dell’AI può rendere più rapido il lavoro preparatorio, ma non trasferisce automaticamente agli strumenti generativi l’autorità necessaria per decidere se una modifica debba essere accettata.

La questione apre inoltre una riflessione sulla governance dei progetti open source: le regole devono offrire informazioni utili senza introdurre formalità che perdano efficacia quando le pratiche quotidiane cambiano. La sfida consiste nel preservare fiducia, verificabilità e responsabilità umana, adattando le procedure a un ambiente di sviluppo in trasformazione.