Rust adotta una politica formale per l’uso degli LLM nel suo repository principale

Cinque team del progetto Rust hanno adottato una politica formale che disciplina come i grandi modelli linguistici possono essere usati quando si contribuisce a rust-lang/rust, il monorepo principale del progetto; Jynn Nelson, l’autrice della politica, ha annunciato sul blog Inside Rust il 5 agosto 2026. La politica (ratificata dai team del compilatore, delle librerie, dei tipi, di rustdoc e di bootstrap) sostituisce quello che Nelson descrive come un approccio non pubblicato “wild west” alla moderazione con un insieme di regole pubbliche e scritte.

La politica non rappresenta una posizione a livello di progetto sull’IA, e lo specifica esplicitamente. Si applica solo al repository rust-lang/rust e solo ai team che l’hanno ratificata. Tuttavia, entro questo ambito, traccia una linea netta: gli LLM sono benvenuti come strumenti per il pensiero, non come suoi sostituti.

Cosa dice realmente la politica

Il documento si riassume in una singola frase:

È lecito usare gli LLM per rispondere a domande, analizzare, distillare, perfezionare, verificare, suggerire, revisionare. Ma non per creare.

In pratica, ciò genera tre livelli. Consentito senza riserve: qualsiasi uso privato in cui il contributore è l’unico a vedere l’output — porre domande sul codice, riassumere una discussione, revisionare privatamente il proprio codice. Consentito con divulgazione obbligatoria: traduzione automatica, modifiche banali come correzioni di refusi, scoperta di bug assistita da LLM e bot di revisione LLM, che devono operare da account GitHub separati e chiaramente etichettati, che gli utenti possono bloccare. Vietato: commenti, documentazione e diagnostica del compilatore generati da LLM; qualsiasi processo che richieda l’esecuzione di un LLM; e considerare una revisione LLM sufficiente per accettare o rifiutare una modifica.

Le sanzioni più severe risiedono nel design dell’applicazione. Rappresentare deliberatamente in modo errato l’uso di un LLM conta come violazione del Codice di Condotta del progetto — lo stesso livello del molestia — comportando un avvertimento e, per violazioni ripetute, un ban. Il documento specifica esplicitamente che molte delle sue clausole sono difficilmente applicabili nella pratica, e afferma che ciò è intenzionale: “Il nostro obiettivo non è catturare ogni violazione… Invece, il nostro obiettivo è eliminare ogni possibile negazione plausibile: costringere a scegliere tra rispettare la politica e violarla intenzionalmente.”

Un esperimento limitato per codice scritto da LLM

Il codice scritto da LLM non è vietato in assoluto. È limitato a un esperimento con condizioni d’ingresso rigide: le modifiche devono essere pre‑accordate con un revisore nominato, non critiche per la correttezza del compilatore, ben testate e ben revisionate, con divulgazione obbligatoria in ogni caso. I nuovi contributori non possono aprire una pull request generata da LLM senza aver prima ottenuto l’approvazione di un revisore. Quando non esiste una suite di test per il codice interessato, l’autore deve scriverne una o chiudere la PR. Nessuna eccezione.

L’esperimento prevede un proprio interruttore di sicurezza. Se più della metà delle PR accettate in un periodo di sei settimane sono generate da LLM, le fusioni di PR LLM‑generated si fermano finché la quota non scende sotto il 50 %, con un periodo di raffreddamento minimo di dieci giorni. La finestra coincide con il ciclo di rilascio di sei settimane di Rust. Tutte queste PR sono contrassegnate con la nuova etichetta ai-assisted e pubblicate in un canale privato di Zulip il cui scopo è la raccolta dati (se i contributori assistiti da LLM stanno apprendendo, tornando e producendo lavoro utile), non il controllo degli accessi.

Perché ora

L’annuncio di Nelson descrive tre pressioni che hanno spinto i team dal moderare in modo informale a stabilire regole scritte. Pull request ben rifinite non segnalano più impegno o comprensione, il che corrode i segnali di fiducia su cui si basa la cultura di revisione del progetto. La generazione di codice più economica aggrava una già esistente carenza di capacità di revisione: il repository attualmente contiene 1.281 PR aperte, e la risorsa scarsa è sempre stata il giudizio dei revisori, non il codice. Inoltre, i contributori che rispondono ai commenti di revisione incollandoli in un LLM e reinserendo l’output, secondo Nelson, stanno facendo perdere tempo a tutti e infrangono l’assunzione che il revisore stia parlando con una persona.

Il contesto è una reale divisione all’interno del progetto. La sezione motivazionale della politica afferma che non esiste consenso in Rust, “e probabilmente non ne esisterà mai”, su quando gli strumenti basati sull’IA siano accettabili, con membri che vanno dagli utenti quotidiani a quelli che considerano inaccettabile qualsiasi uso. Per questo il documento è concepito per essere modificato: revisioni importanti richiedono l’approvazione di ciascun team che l’ha ratificata, e la politica può essere annullata interamente da tali team o superata da un comitato LLM a livello di progetto che il consiglio di leadership sta valutando.

Le clausole dettagliate

L’ambito è più ristretto di quanto suggerisca il titolo. La politica non copre altri repository dell’organizzazione rust-lang, il lavoro del language team come il tracciamento di issue e i rapporti di stabilizzazione, la guida di stile, o i team che non l’hanno ratificata. Ognuno rimane libero di stabilire le proprie regole. I membri dell’organizzazione rust-lang sono esenti dalla restrizione “non critico” sul codice generato da LLM, sebbene la politica sconsigli vivamente di usare tale esenzione, e le PR scritte prima dell’entrata in vigore della politica sono anch’esse esenti. Molestare un contributore per aver usato un LLM è proibito di per sé, indipendentemente dal fatto che l’uso abbia violato la politica.

Cosa succederà dopo

Il canale privato di Zulip inizia a raccogliere dati sulle PR generate da LLM non appena l’etichetta ai-assisted è in uso, e la prima finestra di sei settimane del circuito di sicurezza indicherà ai team se l’esperimento sta sovraccaricando la coda di merge. La proposta in sospeso del consiglio di leadership per un comitato LLM dedicato, se costituita, avrà priorità su questa politica e potrà estendere le regole a livello di progetto, coprendo chat, forum e repository che oggi non hanno alcuna politica. Il post di Nelson sostiene esattamente quel risultato, inquadrando questa politica come un primo passo piuttosto che una risposta definitiva.