Linus Torvalds utilizza Claude Code per il kernel Linux

Linus Torvalds, il creatore di Linux, ha scritto con Claude Code, l'assistente di programmazione di Anthropic, una serie di patch per il kernel Linux. Nel messaggio del commit principale, pubblicato nel branch noref-filemap-read-with-llm del repository ufficiale, dichiara che codice, programmi di test, revisione e prima bozza del testo sono stati prodotti con l'assistente "sotto la mia direzione" e che le misure di prestazione sono state fatte "sulla mia macchina".

A notare il nuovo ramo è stato Michael Larabel di Phoronix, mentre aspettava l'uscita di Linux 7.3-rc7. Nel repository di Torvalds gira di solito il solo ramo master, quindi un branch con la sigla LLM in coda al nome non passa inosservato. Il codice, per ora, non è stato integrato nel kernel.

Che cosa cambia nella lettura dei file

Il problema che la serie affronta è noto a chi lavora sulla gestione della memoria. Quando molti thread leggono piccoli pezzi dello stesso file (16 byte alla volta, nel test), ogni lettura deve incrementare e poi decrementare un contatore di riferimenti sul folio, cioè l'unità con cui il kernel amministra le pagine della page cache. Tutte le CPU martellano la stessa linea di cache e il tempo se ne va ad aspettarsi a vicenda invece di copiare dati.

La patch toglie quel contatore dal percorso di lettura. Le letture avvengono dentro una sezione critica RCU (read-copy-update, il meccanismo con cui il kernel lascia scorrere molti lettori senza bloccarli) e la memoria dei folio viene liberata solo dopo un periodo di grazia RCU. Stando alla ricostruzione di Startup Fortune, esiste anche una valvola di sicurezza: se in coda per la liberazione finiscono più di 1.024 pagine per CPU, il kernel forza un periodo di grazia accelerato, così la memoria non si accumula.

Per il lettore non specialista basta tenere a mente una cosa. Il kernel passa la vita a leggere file già in memoria, quindi ogni ciclo risparmiato su quel percorso si moltiplica per un numero enorme di chiamate.

I numeri, con una cautela

Le cifre circolate finora arrivano da Startup Fortune, che a sua volta le attribuisce a Hardware Busters. Fotografano un solo portatile con processore Core i7-8565U, otto thread e letture da 16 byte.

• Misura: Prima / Dopo
• Cicli di kernel per lettura (8 thread): circa 2.950 / circa 725
• Load HITM (contesa sulla linea di cache): 30.538 / 101
• Letture al secondo: circa 10 milioni / circa 33 milioni
• Lettura singola, un solo thread (pagina non mappata): circa 4.150 cicli / circa 6.550 cicli

La riga più interessante è l'ultima. Con un solo thread la nuova strada costa di più (circa 6.550 cicli contro 4.150), un compromesso prevedibile per un percorso pensato per la contesa, che paga qualcosa quando la contesa non c'è. Il guadagno compare nei carichi con molti lettori sullo stesso file. Lì il salto è netto. Un HITM, per chi non lo mastica, è un accesso che trova la linea di cache già modificata da un altro core; è la spia del rimpallo che la patch vuole eliminare.

Le misure vanno prese come preliminari. Girano su una sola macchina, dichiarata da Torvalds stesso. Al momento non risultano riprove indipendenti su hardware diverso.

Una patch con una storia alle spalle

Chi seguiva le liste di sviluppo ricorda che il tema non nasce oggi. Nell'ottobre 2025 Kiryl Shutsemau aveva proposto mm/filemap: Implement fast short reads, una scorciatoia per le letture brevi basata su un contatore di sequenza. Nel thread su LKML David Hildenbrand osservava che il codice doveva garantire di leggere da un folio non riutilizzato nel frattempo e chiedeva di accantonare l'ottimizzazione a favore di una liberazione dei folio ritardata con RCU. Torvalds, dal canto suo, faceva notare che la page cache ha già "tutto il balletto di foliotryget()" e che la liberazione, di fatto, non era ritardata con RCU, motivo per cui il kernel incrementa il riferimento sotto RCU e controlla dopo.

Un anno dopo la strada indicata allora come alternativa, la liberazione rimandata con RCU, è quella che il suo branch mette in pratica. Che l'abbia scritta con l'aiuto di Claude Code (non a mano) è il dettaglio che ha fatto scattare la notizia.

Dall'AudioNoise al driver Intel Xe

Per Torvalds non è un fulmine a ciel sereno. A gennaio 2026 aveva ammesso nel README di AudioNoise, il suo progetto di effetti audio per pedali da chitarra, che il visualizzatore in Python era stato scritto in vibe coding con Google Antigravity, come riportò Phoronix.

Il 15 luglio, in un messaggio sulla lista del kernel, aveva messo i puntini sulle i. Linux, scrisse, non è uno di quei progetti anti-AI. Chi ha problemi può fare un fork o andarsene. Lo strumento "è chiaramente utile" e nessuno è obbligato a usarlo, ma lui ignorerà "a voce alta" chi prova a vietarlo agli altri. Ammetteva anche il rovescio, ossia che l'AI può essere "un po' dolorosa" per i maintainer perché continua a trovare bug imbarazzanti.

Il 21 agosto è arrivato il passaggio più concreto. Dopo una "sessione di debug dall'inferno" su una scheda Battlemage G21, Torvalds firmò un fix per il driver grafico Intel Xe e lasciò scritto nel commit che l'AI aveva fatto gran parte del lavoro di manovalanza. L'assistente, raccontò, più volte aveva dichiarato il problema impossibile e consigliato di scrivere un rapporto, ma continuava ad aggiungere codice di debug quando lui insisteva. Il risultato era un cambio da roundup() a rounddown(), preceduto da 24 patch di debug e 18 avvii del kernel, come racconta Phoronix. Quel fix è confluito in Linux 7.3.

Messe in fila, le quattro tappe disegnano un percorso lineare. Prima un hobby (AudioNoise), poi una posizione politica sulla lista del kernel, poi il debug di un driver e ora una funzione scritta per il cuore della memoria. È un salto di peso, perché la page cache non è un posto in cui si improvvisa.

Che cosa manca ancora

La patch non è nel kernel. Phoronix si limita a segnalare che Torvalds potrebbe portarla nella finestra di integrazione di Linux 7.4. Nella copertura che ho letto non compaiono reazioni dei maintainer del sottosistema di memoria, né una revisione pubblica dei numeri su hardware diverso. Per un cambiamento che tocca come il kernel libera le pagine è il capitolo decisivo, ben più dell'etichetta "scritto con un assistente".

Resta anche una questione di metodo. Il messaggio del commit attribuisce all'assistente test e revisione. Questo apre una domanda legittima su chi controlli chi quando test e codice nascono dalla stessa fonte. La risposta di Torvalds è nella formula "sotto la mia direzione", che riporta la responsabilità sul maintainer. Che cosa abbiano deciso il kernel e le distribuzioni sull'uso dell'AI lo avevamo ricostruito nella sintesi su Linux e IA nel 2026, mentre il lato dei maintainer sommersi dalle segnalazioni è nell'articolo sui bug hunter AI che travolgono i manutentori.

Sul fronte sicurezza gli assistenti hanno già lasciato il segno nel kernel, con esiti alterni. C'è stato il caso di Bad Epoll (CVE-2026-46242), un bug che l'AI di Anthropic non aveva visto. Usarli anche per scrivere codice (non solo per cercare difetti) è un passo ulteriore. La patch sulla page cache è il primo banco di prova pubblico firmato dal vertice del progetto.

Per capire come si guida un assistente di questo tipo vale la pena rileggere la guida ai migliori MCP per Claude Code, la novità di Claude Code Projects e il caso di Claude Opus 5.5 che decompila giochi, che mostra fin dove arriva lo stesso modello su codice altrui.

Domande frequenti (FAQ)

1. Quando entrerà nel kernel la patch di Torvalds?

Non c'è una data. Al momento è ancora in fase di revisione e test.