Rust antar en formell LLM‑policy för sitt huvud‑repo

Fem team i Rust‑projektet har antagit en formell policy som reglerar hur stora språkmodeller får användas när de bidrar till rust-lang/rust, projektets huvud‑monorepo, Jynn Nelson, policy‑författaren, annonserades på Inside Rust‑bloggen den 5 augusti 2026. Policyn (godkänd av kompilator‑, lib‑, types‑, rustdoc‑ och bootstrap‑teamen) ersätter det som Nelson beskriver som en opublicerad ”vild‑väst‑”metod för moderering med ett offentligt, skriftligt regelverk.

Policyn är inte ett projektomfattande ställningstagande kring AI, och den är tydlig med detta. Den gäller endast för rust-lang/rust-arkivet och endast för de team som ratificerat den. Men inom detta område dras en klar gräns: LLM‑er är välkomna som verktyg för tänkande, inte som ersättare för det.

Vad policyn faktiskt säger

Dokumentet sammanfattar sig självt i en enda mening:

Det är okej att använda LLM‑er för att svara på frågor, analysera, destillera, förfina, kontrollera, föreslå, granska. Men inte för att skapa.

I praktiken ger detta tre nivåer. Tillåtet utan restriktion: all privat användning där bidragsgivaren är den enda som ser resultatet — ställa frågor om kodbasen, sammanfatta en tråd, privat granska sin egen kod. Tillåtet med obligatorisk avslöjning: maskinöversättning, triviala ändringar som stavningsrättningar, LLM‑assisterad felupptäckt och LLM‑gransknings‑botar, som måste köras från separata, tydligt märkta GitHub‑konton som enskilda användare kan blockera. Förbjudet: LLM‑skapade kommentarer, dokumentation och kompilatordiagnostik; alla processer som kräver att en LLM körs; samt att betrakta en LLM‑granskning som tillräcklig för att slå ihop eller avvisa en ändring.

De skarpaste tänderna sitter i verkställighetsdesignen. Att medvetet felrepresentera LLM‑användning räknas som ett brott mot projektets uppförandekod — samma nivå som trakasserier — med en varning och, vid återkommande överträdelser, ett avstängningsbeslut. Dokumentet är explicit med att många av dess klausuler är opraktiska att verkställa, och säger att detta är avsiktligt: ”Vårt mål är inte att fånga varje överträdelse… Istället är vårt mål att eliminera möjligheten till plausibel förnekelse: att tvinga ett val mellan att följa policyn och att medvetet bryta mot den.”

Ett avgränsat experiment för LLM‑skriven kod

LLM‑skriven kod är inte förbjuden i sin helhet. Den är begränsad till ett experiment med strikta inträdesvillkor: ändringar måste förhandsarrangeras med en namngiven granskare, vara icke‑kritiska för kompilatorns korrekthet, vältestade och välgranskade, med avslöjande som krävs i varje fall. Nya bidragsgivare får inte öppna en LLM‑skapad pull‑request utan först ha säkrat en granskare. Där ingen testsvit finns för den berörda koden måste författaren skriva en eller stänga PR:n. Inga undantag.

Experimentet har en egen strömbrytare. Om mer än hälften av de PR‑er som slås ihop under ett sex‑veckorsfönster är LLM‑skapade, stoppas sammanslagning av LLM‑skapade PR‑er tills andelen sjunker under 50 procent, med en minsta avkylningsperiod på tio dagar. Fönstret stämmer överens med Rusts sex‑veckors utgivningscykel. Alla sådana PR‑er får en ny ai-assisted-etikett och publiceras i en privat Zulip‑kanal vars syfte är datainsamling (om LLM‑assisterade bidragsgivare lär sig, återkommer och producerar användbart arbete), inte gatekeeping.

Varför nu

Nelsons tillkännagivande beskriver tre påtryckningar som förde teamen från informell moderering till skrivna regler. Polerade pull‑requests signalerar inte längre ansträngning eller förståelse, vilket urholkar de förtroendesignaler som projektets granskningskultur bygger på. Billigare kodgenerering förvärrar en redan befintlig brist på granskningskapacitet: repot har för närvarande 1 281 öppna PR‑er, och den knappa resursen har alltid varit granskarnas omdöme, inte koden. Och bidragsgivare som svarar på granskningskommentarer genom att klistra in dem i en LLM och sedan klistra in resultatet tillbaka, slösar enligt Nelson allas tid och bryter antagandet att en granskare talar med en människa.

Bakgrunden är en verklig splittring inom projektet. Policyns egen motivationssektion konstaterar att det inte finns någon konsensus inom Rust, ”och sannolikt kommer det aldrig att finnas”, om när AI‑baserade verktyg är acceptabla, med medlemmar som sträcker sig från dagliga användare till de som anser all användning oacceptabel. Därför är dokumentet byggt för att kunna förändras: större revideringar kräver godkännande från varje ratificerande team, och policyn kan helt upphävas av dessa team eller åsidosättas av ett projektomfattande LLM‑kommitté som ledningsrådet nu överväger.

Det finstilta

Omfattningen är snävare än rubriken antyder. Policyn täcker inte andra arkiv i rust‑lang‑organisationen, språk‑teamets arbete såsom ärende‑ och stabiliseringsrapporter, stilguiden eller team som inte har ratificerat den. Varje sådant team förblir fritt att sätta egna regler. Medlemmar i rust‑lang‑organisationen är undantagna från begränsningen ”icke‑kritisk” för LLM‑skapad kod, även om policyn starkt avråder från att använda detta undantag, och PR‑er skrivna innan policyn trädde i kraft är också undantagna. Att trakassera en bidragsgivare för att använda en LLM är i sig förbjudet, oavsett om användningen bröt mot policyn.

Vad som händer härnäst

Den privata Zulip‑kanalen börjar samla data om LLM‑skapade PR‑er så snart ai-assisted-etiketten är i bruk, och det första sex‑veckors‑strömbrytar‑fönstret kommer att visa teamen om experimentet överväldigar sammanslagningskön. Ledningsrådets pågående förslag om en dedikerad LLM‑kommitté skulle, om den bildas, ha företräde framför denna policy och kunna utvidga reglerna projektomfattande, vilket skulle omfatta chattar, forum och arkiv som idag saknar någon policy. Nelsons inlägg argumenterar för just detta resultat, och placerar policyn som ett första steg snarare än ett slutgiltigt svar.