Sono tante e variegate le riflessioni condivise da Linus Torvalds all’Open Source Summit di Mumbai che si è svolto lo scorso 16 e 17 giugno e che sono state raccontate da ZDNet nell’articolo dal titolo ‘I’m not a programmer’ anymore: Linus Torvalds on the only two tools he uses now.

Le prime considerazioni sono in merito alla nuova release del Kernel, ossia la 7.1 che, come molte ultimamente, non è una release da effetto “wow”, ma molto solida, il che fa parte proprio degli obiettivi del progetto:

We don’t do releases that have big new splashy features, and I actually actively try to avoid that kind of model; we want to have this kind of incremental improvement and steady progress all the time.

Non facciamo release con grandi e appariscenti funzionalità nuove, e anzi cerco attivamente di evitare quel tipo di modello; vogliamo avere questo tipo di miglioramento incrementale e progresso costante in ogni momento.

Un dato interessante poi riguarda l’operatività del creatore di Linux: nel corso delle merge windows, cioè il tempo che passa tra una release e l’altra del Kernel e che si attesta di solito intorno al paio di settimane, effettua approssimativamente 200 merge.

Con questa mole di lavoro si capisce perché Torvalds non perda occasione per sottolineare la sua avversione per “le patch dell’ultimo momento“. Ne abbiamo parlato nell’ottobre del 2022: molti sviluppatori pur di rientrare in una specifica merge window effettuano le richieste di patch all’ultimo momento il che comporta ulteriore lavoro per Linus, il quale, giustamente, chiede comprensione e professionalità. Come sappiamo, volente o nolente, tutto passa da lui.

Specificato questo si è passati al fulcro dell’intervista, con l’affermazione che poi dà anche il titolo a questo articolo:

Let’s be entirely honest. I hardly read code at all anymore. I’m not a programmer, I’m a development lead. […] I still write code in the sense that I send people patches… but then I make it very clear that, hey, this is a suggestion. This is untested… I expect the maintainers of the code to be the ones who then send me the fix back. So I very seldom commit my own code anymore.

Cerchiamo di essere totalmente onesti. Ormai leggo a malapena il codice. Non sono un programmatore, sono un responsabile dello sviluppo. […] Scrivo ancora codice nel senso che invio patch alle persone… ma poi chiarisco molto bene che, ehi, questo è un suggerimento. Non è testato… mi aspetto che siano i manutentori del codice a rispedirmi poi la correzione. Quindi molto raramente integro io stesso il mio codice.

Affermazioni per certi versi sorprendenti, ma che incrociati con la questione di cui sopra hanno perfettamente senso: per quanto geniale, il creatore del Pinguino rimane umano.

Si prosegue poi su Rust, e su come Linus trovi il linguaggio perfetto per certi contesti e allo stesso tempo non la panacea di tutti i mali:

Rust fixes a few easy bugs that you can make in C, but it does not fix the logic errors, right? It does not think for you, and when you write incorrect code, the language does not matter. The end result will be incorrect. […] The guarantees that Rust give you only apply in the Rust-only parts of your code base, and wherever you interact with C code, all bets are off

Rust corregge alcuni errori facili che si possono fare in C, ma non risolve gli errori logici, giusto? Non pensa al posto tuo, e quando scrivi codice errato, il linguaggio non ha importanza. Il risultato finale sarà sbagliato. […] Le garanzie che Rust ti offre valgono solo nelle parti del tuo codice che sono puramente in Rust, e ovunque interagisci con codice C, non c’è più alcuna certezza.

E quindi il futuro, almeno per quanto riguarda il Kernel Linux, è fatto di coesistenza tra i due linguaggi poiché il codice C attuale è frutto di anni di test effettuati su svariati ambienti di produzione.

Infine, ovviamente, l’AI (nonostante l’autore dell’articolo sottolinei come per ben 26 minuti di intervista si era riusciti a parlare d’altro). La posizione di Torvalds a proposito degli LLM è sempre stata chiara, sono dei tool che servono ad incrementare la produttività, ma l’autore di Git ha voluto correggere se stesso a proposito di alcune stime da lui ipotizzate: gli LLM avrebbero potuto portare a un aumento di 10 volte della produttività dei programmatori.

Su questo ha precisato come il numero non fosse affatto scientifico, aggiungendo:

We’re at the point where hopefully it creates more productivity than it takes away […] we certainly saw more junk being generated by LLMs than we saw useful code up until the like early this year…. it can actually be a huge drain on resources when it takes humans a lot of effort to figure out that, hey, this machine-generated report was not true. […] most of the good ones require more than just the LLM, […] we’ve had to push back quite a bit… if you find a bug with an LLM, it’s not enough to just ask the LLM to make a bug report and then throw it over the fence to us. We want to see a suggested patch; we want to see the human who ran the LLM act as a kind of back-and-forth.

Siamo al punto in cui, si spera, crei più produttività di quanta ne sottragga […] sicuramente abbiamo visto più spazzatura generata dagli LLM che codice utile fino all’inizio di quest’anno… può effettivamente essere un enorme drenaggio di risorse quando gli esseri umani impiegano molto impegno per capire che, ehi, questo rapporto generato da una macchina non era vero. […] la maggior parte di quelli buoni richiede più del solo LLM, […] abbiamo dovuto opporre un bel po’ di resistenza… se trovi un bug con un LLM, non basta chiedere all’LLM di fare un rapporto sul bug e poi scaricarlo oltre la recinzione a noi. Vogliamo vedere una patch suggerita; vogliamo vedere l’umano che ha eseguito l’LLM agire come una sorta di intermediario.

E la mente non può che tornare alle medesime questioni sollevate da Daniel Stenberg, l’autore di curl, il quale ha recentemente sospeso le ricezioni di bug report per il progetto per le stesse ragioni evidenziate da Torvalds, il quale ha descritto molte patch generate dall’IA come “patch senza cervello, tipo cerotti… possono risolvere il problema immediato, ma il tipo di bug rimane, ed è lì che aspetta in agguato per colpirti in un altro punto.“.

Tra l’altro, per i suoi progetti personali, Linus usa gli LLM come prototipatori: codice non utilizzabile nella forma in cui è, ma ottimo per sperimentare, mentre per le correzioni a livello di Kernel, gli LLM non sono ancora al livello atteso.

Magari non sarà più uno sviluppatore come dice, ma il papà di Linux ha ancora le idee molto, molto chiare su come il codice va scritto, e speriamo queste rimangano tali per tanto, tanto tempo ancora.