Rust antar en formell LLM-policy för sitt huvudrepository

Fem team i Rust-projektet har antagit en formell policy som reglerar hur stora språkmodeller kan användas när de bidrar till rust-lang/rust, projektets huvudmonorepo, meddelade Jynn Nelson, policyns författare, på Inside Rust-bloggen den 5 augusti 2026. Policyn (ratificerad av kompilator-, libs-, types-, rustdoc- och bootstrap-teamen) ersätter det som Nelson beskriver som en outgiven “vilda västern”-tillvägagångssätt för moderering med en offentlig, skriven uppsättning regler.

Policyn är inte en projektomfattande inställning till AI, och den är försiktig med att säga så. Den gäller endast för rust-lang/rust-databasen och endast för de team som ratificerat den. Men inom det området drar den en tydlig linje: LLM:er är välkomna som verktyg för att tänka, inte som ersättning för det.

Vad policyn faktiskt säger

Dokumentet sammanfattar sig själv i en enda mening:

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

I praktiken resulterar det i tre nivåer. Tillåtet utan begränsningar: alla privata användningar där bidragsgivaren är den enda som ser utdata — att ställa frågor om kodbasen, sammanfatta en tråd, privat granska sin egen kod. Tillåtet med obligatorisk avslöjande: maskinöversättning, triviala ändringar som korrigering av skrivfel, LLM-assisterad felsökning och LLM-granskningsrobotar, 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 kompilator-diagnostik; alla processer som kräver en LLM för att köra; och att behandla en LLM-granskning som tillräcklig för att slå samman eller avvisa en ändring.

De skarpaste tänderna sitter i utformningen av verkställigheten. Att medvetet missrepresentera LLM-användning räknas som ett brott mot projektets uppförandekod — samma nivå som trakasserier — och medför en varning och, för upprepade brott, ett förbud. Dokumentet är uttryckligen att många av dess klausuler är ogenomförbara i praktiken, och säger att det är medvetet: “Vårt mål är inte att fånga varje brott… Istället är vårt mål att ta bort trovärdig förnekelse: att tvinga ett val mellan att följa policyn och medvetet bryta mot den.”

En begränsad experiment för LLM-skriven kod

LLM-författad kod är inte förbjuden uttryckligen. Den är begränsad till ett experiment med stränga inträdesvillkor: ändringar måste vara föravtalade med en namngiven granskare, icke-kritiska för kompilatorns ljudhet, väl testade och väl granskade, med avslöjande krävt i varje fall. Nya bidragsgivare kan inte öppna en LLM-skapad pull request utan att först säkra en granskare. Om det inte finns någon testsvit för den berörda koden måste författaren skriva en eller stänga PR. Inga undantag.

Experimentet har sin egen säkerhetsbrytare. Om mer än hälften av de slagna sammanfogningarna under en sexveckorsperiod är LLM-skapade, stoppas sammanfogningar av LLM-skapade pull requests tills andelen sjunker tillbaka under 50 procent, med en minimikylning på tio dagar. Fönstret sammanfaller med Rusts sexveckorsutgivningscykel. Alla sådana pull requests har en ny ai-assisterad-etikett och publiceras på en privat Zulip-kanal vars syfte är datainsamling (om LLM-assisterade bidragsgivare lär, återvänder och producerar användbar arbete), inte grindvakt.

Varför nu

Nelsons tillkännagivande beskriver tre tryck som tvingade teamen från informell moderering till skrivna regler. Välpolerade pull requests signalerar inte längre ansträngning eller förståelse, vilket korroderar förtroendesignalerna som projektets granskningskultur bygger på. Billigare kodgenerering förvärrar en befintlig granskningsbandbreddsbrist: databasen har för närvarande 1 281 öppna pull requests, och den knappa resursen var alltid granskarnas omdöme, inte kod. Och bidragsgivare som svarar på granskningskommentarer genom att klistra in dem i en LLM och klistra in utdata tillbaka slösar, enligt Nelsons ord, allas tid och bryter antagandet att en granskare pratar med en person.

Bakgrunden är en verklig splittring inom projektet. Policyns egen motivationssektion anger att det inte finns någon enighet inom Rust, “och troligen aldrig kommer 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 att all användning är oacceptabel. Det är därför dokumentet är byggt för att ändras: stora revideringar kräver godkännande från varje team som ratificerat den, och policyn kan upplösas helt av dessa team eller åsidosättas av en projektomfattande LLM-kommitté som ledningsrådet nu överväger.

Det finstilta

Omfånget är smalare än rubriken antyder. Policyn täcker inte andra databaser i rust-lang-organisationen, språkteamsarbete som att spåra problem och stabiliseringsrapporter, stilguiden eller team som inte har ratificerat den. Var och en förblir fri att ställa in sina egna regler. Medlemmar i rust-lang-organisationen är undantagna från “icke-kritiska”-begränsningen för LLM-skapad kod, även om policyn säger att den starkt avråder från att använda den undantaget, och pull requests som skrivits före att policyn trädde i kraft är undantagna också. 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 in data om LLM-skapade pull requests så snart ai-assisterad-etiketten används, och den första sexveckors säkerhetsbrytaren kommer att berätta för teamen om experimentet överväldigar sammanfogningskön. Ledningsrådets väntade förslag för en dedikerad LLM-kommitté skulle, om den bildas, ha företräde framför denna policy och kunde utöka regler projektomfattande, som täcker chattar, forum och databaser som i dag inte har någon policy alls. Nelsons inlägg argumenterar för exakt det resultatet, och ramverket för denna policy som ett första steg snarare än ett fast svar.