Il progetto Rust ha adottato una policy che regola l’uso degli LLM nei contributi al repository principale rust-lang/rust. Cinque team hanno firmato il documento, scritto da Jynn Nelson. La policy definisce cosa è accettabile e cosa no quando si usa un modello per aprire pull request, segnalare issue o rispondere a commenti di revisione.

La mossa arriva mentre Debian sta ancora votando su quattro proposte analoghe, come raccontavamo il 26 luglio. I due progetti open source più strutturati che scrivono regole esplicite nello stesso periodo segnalano un cambio di fase: la governance dei contributi AI diventa operativa.

Perché ti riguarda. Se integri LLM nei workflow tecnici collaborativi, questi documenti sono il modello da cui partire. Rust identifica tre problemi concreti: le PR generate da un modello sembrano curate ma non indicano comprensione reale, il volume di contributi satura la capacità di revisione, e chi incolla risposte di un LLM nei commenti di review spreca il tempo di chi revisiona. Sono dinamiche che qualsiasi team tecnico incontra quando i membri usano assistenti AI nel lavoro condiviso.

La policy formalizza regole che prima erano implicite e applicate in modo inconsistente. Ora i contributori sanno cosa ci si aspetta prima di inviare una PR, e i revisori hanno un riferimento esplicito quando ne chiudono una che non le rispetta.

Nel dettaglio

Prima di questa policy, il progetto Rust applicava un approccio che Nelson definisce “wild west”: nessuna regola pubblicata sull’uso degli LLM, moderazione inconsistente, contributori nuovi che scoprivano le regole solo quando la loro PR veniva chiusa per motivi che non capivano. La mancanza di regole esplicite lavorava contro gli obiettivi di trasparenza e accoglienza del progetto.

Il problema di fondo è che una pull request ben scritta, con test e documentazione, era tradizionalmente un segnale di impegno e comprensione. Influenzava la cultura di Rust in modi specifici: i revisori erano riluttanti a chiudere PR perché rappresentavano il lavoro di qualcuno, il processo enfatizzava la discussione incrementale, e un PR era interpretato come interesse a unirsi alla comunità a lungo termine.

Con gli LLM, nessuno di questi segnali è più affidabile. Un PR curato non indica più sforzo reale. L’autore non necessariamente capisce il codice che ha prodotto. Nel caso degli agenti autonomi, non c’è nessuno dall’altra parte. Nelson scrive che al momento della pubblicazione ci sono 1.281 PR aperte su rust-lang/rust, contro una capacità di revisione già insufficiente prima dell’arrivo dei modelli. Facilitare la scrittura di codice peggiora un problema che il progetto aveva già.

La policy si applica a quattro categorie di persone: chi revisiona o modera PR, chi scrive PR con codice generato da LLM, chi segnala issue trovate con un modello, e chi cita direttamente l’output di un LLM in issue o commenti. Chi non rientra in queste categorie non deve cambiare nulla.

Il punto per chi gestisce team tecnici. Nelson è esplicita: la maggior parte del lavoro di revisione consiste nel decidere se una direzione è giusta e se il PR ha senso. Inviare decine di PR ai revisori ha un costo mentale alto. Il codice stesso è la parte più piccola e in alcuni casi meno importante della contribuzione. Quello che conta è che l’autore capisca cosa fa il codice, abbia pianificato come evolverà, e abbia deciso come dovrebbe apparire. Un LLM non aiuta in nessuno di questi passaggi.

La policy è un documento operativo per un repository specifico. Si applica a cinque team su tutti quelli del progetto, e la governance resta locale. I limiti sono dichiarati: la policy riguarda solo rust-lang/rust e non si estende a tutto l’ecosistema Rust.

Il parallelo con Debian è diretto. Entrambi i progetti stanno scrivendo regole sullo stesso tema nello stesso periodo, partendo da problemi simili: contributori che usano LLM senza sapere cosa ci si aspetta da loro, revisori senza riferimenti espliciti per respingere contributi inaccettabili, e una tensione fra accoglienza dei nuovi arrivati e qualità della collaborazione. La differenza è che Rust ha già un documento firmato da cinque team, mentre Debian è ancora in fase di votazione su quattro proposte che vanno dal bando totale all’approccio graduale.

Per chi porta l’AI nei processi collaborativi, il precedente è duplice: le regole scritte vengono prima dei problemi, e il codice generato da un modello non sostituisce il giudizio di chi lo produce.