Lorenzo Stoakes ridurrà il proprio lavoro di revisione del kernel Linux perché il volume di serie di patch generate con l’intelligenza artificiale ha superato il tempo che può dedicarvi. L’ingegnere principale del software di Arm non lascia il progetto: manterrà i propri incarichi di manutenzione e limiterà le revisioni generali alle aree di sua diretta responsabilità.
La decisione è stata formalizzata in una serie di quattro patch inviata alla mailing list del kernel il 10 novembre. In essa, Stoakes propone di lasciare gli incarichi di revisione in diverse aree della gestione della memoria, ridistribuendoli tra altri responsabili. Come ha spiegato, il volume attuale di serie generate dall’IA non gli lascia la capacità di offrire revisioni generali al di fuori delle aree di cui si occupa.
“Given the current throughput in the kernel resulting from AI-generated series, I unfortunately lack the bandwidth to generally be able to offer review except in those areas I maintain.”
— Lorenzo Stoakes, ingegnere principale del software di Arm
Un ritiro parziale, non un’uscita dal progetto
Il cambiamento riguarda gli incarichi di revisione, non le responsabilità di manutenzione che Stoakes mantiene. In dichiarazioni a The Register, ha chiarito che non intende rinunciare a tali responsabilità: vuole ridurre il carico della propria casella di posta e smettere di revisionare in generale al di fuori dei sottosistemi di cui si occupa.
La distinzione è importante, perché revisionare e mantenere non sono attività intercambiabili. Nel suo curriculum, Stoakes indica quattro aree di manutenzione legate alla gestione della memoria: il memory mapping, il relativo locking, l’interfaccia madvise e il reverse mapping tra memoria fisica e virtuale. Come spiega nel suo messaggio, questa modifica gli permette di concentrare il lavoro su tali aree, anziché garantire un’ampia disponibilità per revisionare altri contributi.
La serie inviata alla mailing list suddivide per area le revisioni che lascia e le assegna a David Hildenbrand, Andrew Morton e Alice Ryhl insieme a Danilo Krummrich. Include anche una voce in CREDITS per il suo lavoro di manutenzione di THP, le huge page trasparenti. Stoakes spiega che, dopo la nomina di Zi a co-maintainer, non si aspetta più di dover intervenire in quell’ambito.
Più proposte, la stessa capacità di revisione
Il problema segnalato da Stoakes è una questione di scala: produrre patch è diventato più facile, ma il numero di persone disponibili a verificarle non è aumentato allo stesso ritmo. Una proposta deve arrivare a qualcuno che conosca l’area, valuti le modifiche e decida se sono adatte. L’IA può accelerare la generazione del codice, ma non elimina questo lavoro di valutazione.
Stoakes ha descritto a The Register una progressione evidente: i contributi assistiti dall’IA sono passati da uno alla settimana ad arrivi quotidiani e ora, secondo la sua stima, rappresentano la metà di ciò che vede durante le revisioni. Ha aggiunto che l’impatto riguarda nel complesso la gestione della memoria. Ha anche raccontato che spesso finisce per lavorare di notte e nei fine settimana, una routine che associa al rischio di esaurimento.
Per i responsabili di un progetto, la conseguenza immediata non è soltanto una coda più lunga. Se un revisore riduce la propria disponibilità, il lavoro deve essere distribuito tra altre persone oppure attendere; in questo caso, Stoakes stesso ha suddiviso le patch per area affinché altri maintainer possano occuparsene. La decisione evita di presentare la revisione come un obbligo illimitato a carico di una sola persona, ma mette anche in luce che il collo di bottiglia è la disponibilità di competenze specialistiche, non la quantità di codice generabile.
Greg Kroah-Hartman, citato da The Register dopo una sessione di domande all’Open Source Summit del mese precedente, ha espresso una preoccupazione simile: ha detto che non ci sono abbastanza persone per revisionare tutte le patch generate dagli LLM e che i maintainer sono esausti da anni. Il suo commento colloca il caso di Stoakes in una tensione più ampia nella manutenzione del kernel: l’aumento delle proposte arriva in una comunità che, secondo Kroah-Hartman, non dispone già di revisori sufficienti.
Il contrasto con le correzioni assistite dall’IA
Il carico di revisione coincide con un altro segnale, di segno più positivo. Linuxiac riferisce che Linus Torvalds ha sottolineato il crescente ricorso a correzioni assistite dall’IA in Linux 7.4-rc2. Nel suo annuncio dell’8 novembre ha scritto che gran parte del recente lavoro di manutenzione vi aveva fatto ricorso e che forse avrebbe smesso di menzionarlo, perché potrebbe diventare una pratica abituale.
Torvalds ha citato anche il maintainer di BPF, Alexei Starovoitov, il quale ha osservato che in quel sottosistema il ritmo delle correzioni supera ormai quello delle nuove segnalazioni di bug. Torvalds ha avvertito che nella maggior parte delle altre aree non accade lo stesso: lo ha presentato come un possibile segnale di progresso in BPF, non come un miglioramento generale del kernel. Linuxiac segnala inoltre che non ha identificato gli strumenti utilizzati per produrre le correzioni né le patch specifiche generate dall’IA.
Coesistono così due effetti: gli strumenti possono aiutare a individuare e correggere gli errori, ma aumentano anche il flusso di materiale che qualcuno deve revisionare. Più correzioni non significano meno lavoro di revisione se ogni proposta richiede comunque una valutazione umana e il numero di revisori non cresce allo stesso ritmo. È importante anche la differenza tra i due casi: il commento di Torvalds riguarda le correzioni che entrano nello sviluppo; Stoakes parla del carico rappresentato dall’insieme delle serie che riceve per la revisione.
Cosa cambia per chi mantiene il software
L’episodio rende evidente un limite organizzativo per le aziende che dipendono da Linux: un progetto può ricevere più contributi senza acquisire la capacità necessaria per integrarli. Nel caso di Stoakes, la risposta consiste nel circoscrivere la propria disponibilità e distribuire le responsabilità, non nell’abbandonare i sottosistemi di cui si occupa.
Per chi invia modifiche, questo contesto aumenta il costo di una proposta non sufficientemente preparata: assorbe tempo di revisione anche se poi non viene integrata. Hardware Upgrade riporta lo stesso problema in altri progetti open source e menziona le preoccupazioni degli sviluppatori di Godot per i contributi generati dall’IA. L’esempio non trasforma il caso di Linux in un divieto generale; mostra che ogni comunità deve decidere come gestire un volume che i suoi revisori potrebbero non riuscire ad assorbire.
La decisione di Stoakes definisce anche ciò che ci si può aspettare da una persona con diverse responsabilità: occuparsi della manutenzione di un’area non significa revisionare l’intero kernel. Formalizzando la rinuncia a determinati incarichi e riassegnando le serie, rende esplicito quale lavoro può continuare a offrire. La domanda pratica per i progetti e le aziende che li utilizzano è come sostenere la revisione quando generare proposte costa sempre meno, ma il giudizio di chi conosce il codice resta una risorsa limitata.
Stoakes non ha rinunciato ai propri incarichi di manutenzione e vuole rendere più gestibile la propria casella di posta. Le quattro modifiche inviate alla mailing list traducono questa decisione in cambiamenti concreti delle responsabilità.
Fonti: theregister, Hardware Upgrade, Linuxiac, Linux kernel mailing list (post originale di Lorenzo Stoakes), Tom's Hardware
