La notizia non è che Canonical metterà i bot a riscrivere Ubuntu in blocco. Jon Seager, vicepresidente engineering, ha scelto una strada più sobria: cofinanziare con UK Research and Innovation un dottorato di ricerca triennale all'Università di Bristol per capire se un LLM possa tradurre grandi codebase C in Rust sicuro. Il progetto, supervisionato con il professor Meng Wang e la dottoressa Cristina David, partirà da due componenti concrete: snap-confine e AppArmor.

L'annuncio, pubblicato sul forum Discourse di Ubuntu, supera le mille parole e prova a rispondere a obiezioni che chiunque abbia visto generare codice da un LLM conosce bene. I traduttori da codice sorgente a codice sorgente tradizionali processano molto codice ma riproducono la struttura del C in modo troppo letterale: il risultato compila come Rust, ma resta pieno di operazioni unsafe, conserva idiomi C posticci e richiede un lavoro manuale enorme. L'ipotesi di Bristol è diversa: usare un LLM per scomporre programmi di centinaia di migliaia di righe in componenti più piccole e riscriverle in Rust "sicuro, comportamentalmente corretto e manutenibile".

Il collo di bottiglia non è la traduzione, ma la decomposizione

Il punto più interessante dell'impostazione è che sposta l'attenzione dal miracolo generativo alla fase precedente: spezzare una codebase matura in unità che un LLM possa digerire senza perdere il comportamento reale. Codebase C mature come AppArmor non sono solo sequenze di istruzioni: sono archivi di conoscenza implicita. Anni di correzioni e patch codificano risposte a casi limite che nessuno aveva previsto all'inizio. È il vecchio argomento di Joel Spolsky nel saggio del 2000: una riscrittura pulita fatta da umani può perdere quella conoscenza; una traduzione automatica potrebbe in parte preservarla.

Ma la decomposizione è esattamente il punto fragile. Ricorda la lunga stagione di ricerca sulla parallelizzazione automatica: dividere algoritmi arbitrari in task da distribuire su processi paralleli ha prodotto tecniche utili per casi particolari, ma nessuna soluzione generale. Potrebbe persino rivelarsi un problema non computabile, come il problema della terminazione. Se così fosse, il progetto non fallirebbe in modo banale: dimostrerebbe che il metodo può funzionare solo con supervisione umana stretta, non come sostituto dei maintainer.

Canonical ha già dimostrato pragmatismo nel portare Rust in Ubuntu: la 25.10 ha adottato sudo-rs e uutils coreutils. Ma attenzione: si trattava di progetti indipendenti preesistenti, riscritture umane nate per riprodurre le funzionalità con codebase nuove. Qui si studia un percorso diverso, in cui l'input è il codice C esistente. La differenza non è accademica: se il traduttore preserva troppa struttura C, si ottiene Rust che compila ma non è sicuro; se la ignora, si perde il comportamento accumulato. Il progetto dovrà capire dove sta la linea.

La scelta di AppArmor e snap-confine è rivelatrice. openSUSE 16 ha sostituito AppArmor con SELinux l'anno scorso; nel mondo enterprise Linux la tendenza è verso SELinux, mentre Debian e distribuzioni minori continuano a usare AppArmor. Un AppArmor riscritto in Rust sicuro avrebbe quindi un bacino di utenti reale, anche se più ristretto. Snap, invece, resta una nicchia. Non è una scommessa su tecnicie mainstream; è un banco di prova per capire se il metodo regge su componenti di sicurezza dove gli errori di memoria contano.

C'è un aspetto che interessa chi valuta deployment on-premise e self-hosted. Tradurre codice C proprietario o security-critical con un LLM esterno significa condividere sorgenti che spesso non possono lasciare il perimetro aziendale. Un flusso di traduzione basato su modelli self-hosted, magari con quantization per stare in VRAM contenuta, diventerebbe perciò un prerequisito per usare questi strumenti in contesti di sovranità dei dati. La ricerca di Bristol non affronta direttamente questo vincolo, ma se il metodo dimostrasse di funzionare, il passo successivo naturale sarebbe portarlo dentro infrastrutture locali. Per chi valuta questi trade-off, AI-RADAR offre su /llm-onpremise framework analitici.

La scommessa di Canonical non è sui bot che generano codice a raffica. È sulla possibilità di produrre evidenze in un campo pieno di hype. Tre anni sono la durata convenzionale di un dottorato nel Regno Unito, a patto che non sfori. Se il progetto mostrerà che la decomposizione è il limite, sarà comunque un risultato utile: avremo capito che gli LLM possono assistere i maintainer, non sostituirli. E il valore maggiore della traduzione automatica tra linguaggi potrebbe non essere correggere automaticamente i problemi, ma portare alla luce errori prima sconosciuti.