En månads debatt slutar i en mening
Den 5 augusti 2026 publicerade de team som underhåller Rust-kompilatorn, standardbiblioteket, typsystemet, rustdoc och bootstrap en formell policy för LLM-användning i monorepot rust-lang/rust, och avslutade därmed mer än en månads intern debatt som nådde cirka 3 000 meddelanden i projektets Zulip-chatt. Ändringen kom som en pull request till styrningsrepositoriet rust-lang/rust-forge, skriven av Jynn Nelson (känd på Zulip och GitHub som jyn514) - samma repositorium som redan beskriver hur projektet granskar, testar och levererar kompilatorn som en stor del av världens minnessäkerhetskritiska programvara bygger på.
Inside Rusts tillkännagivande sammanfattar resultatet i en mening: 'Det är okej att använda LLM:er för att besvara frågor, analysera, destillera, förfina, kontrollera, föreslå, granska. Men inte för att skapa.' Den meningen är policyn. Allt annat i dokumentet tillämpar samma idé på ett specifikt inslag i taget: en dokumentationskommentar, en säkerhetskommentar, en pull request-beskrivning, en kodgranskning.
Gränsen ligger vid författarskapet av committen
Regeln som överlevde cirka 3 000 Zulip-meddelanden drar sin gräns vid författarskapet av committen, inte vid själva användningen av verktyget. Rust-bidragsgivare får använda en LLM för att läsa kod, analysera en bugg, sammanfatta en lång diskussionstråd eller förstå hur ett delsystem fungerar, och inget av det kräver en deklaration. I det ögonblick en LLM:s utdata blir kod som hamnar i en sammanslagen pull request, behandlar policyn den som förbjuden som standard.
Det snäva undantaget är överenskommet i förväg och fullständigt testat: en bidragsgivare som vill committa LLM-skriven kod måste komma överens om omfattningen med granskare i förväg, och den resulterande patchen måste nå samma nivå som varje mänskligt skriven ändring, utan genväg för att ha genererats av en maskin. Utanför den överenskommelsen mergas en ogranskad AI-patch inte, oavsett vilka tester den påstår sig klara på sin egen gren.
Dok- och säkerhetskommentarer får samma regel
Policyn utvidgar skrivförbudet till prosan runt koden, inte bara koden själv. Dokumentationskommentarer, säkerhetskommentarer, pull request-beskrivningar och publika issue-texter som genereras av en LLM måste deklareras som maskingenererade eller är helt förbjudna, eftersom en säkerhetskommentar i osäker Rust är ett påstående en granskare litar på, och ett odeklarerat AI-påstående om varför ett block osäker kod är säker är precis det fel hela policyn finns för att förhindra.
Pull requesten på rust-lang/rust-forge som bär ändringen beskriver den som att skriva bättre, inte snabbare: målet är inte att bromsa bidragsgivare för sakens skull, utan att hålla varje mening en granskare litar på spårbar till en person som står för den. Ett deklarerat AI-utkast som en människa sedan skriver om och tar över behandlas annorlunda än ett odeklarerat utkast som presenteras som egen prosa.
AI-granskningar förblir rådgivande, aldrig en merge-spärr
AI-genererade kodgranskningar är under den nya policyn uttryckligen enbart rådgivande, och ingen av dem kan på egen hand spärra en merge. En bot eller en bidragsgivares AI-assistent får flagga en bugg, föreslå en omstrukturering eller peka på ett saknat test, men godkännandet som faktiskt öppnar en pull request måste fortfarande komma från en mänsklig granskare som tillämpar projektets befintliga granskningsstandarder.
Den skillnaden väger tyngre i en kompilator och ett standardbibliotek än nästan någon annanstans i mjukvara, eftersom en minnessäkerhetsregression här inte förblir begränsad till en enda applikation - den fortsätter nedströms till varje crate och varje binärfil byggd på Rust. Att behandla en AI-granskning som ett förslag och inte en spärr håller ansvaret för vad som mergas hos en namngiven person, varje gång.
Varför denna gräns betyder mer än ett projekt
Rust bär en oproportionerligt stor del av EU:s och Storbritanniens fintech-, fordons- och embedded-kodbaser, från den svenska fordonsindustrin till telekomutrustning som bygger på inbyggda system, just på grund av de minnessäkerhetsgarantier språket upprätthåller redan vid kompilering - precis den egenskap en ogranskad, AI-genererad patch i tysthet skulle kunna underminera om den slank förbi granskningen. En organisation som beror på Rust-baserad infrastruktur samtidigt som den i tysthet sänker sin egen granskningsnivå för AI-assisterad kod har nu en konkret mätpunkt att hålla sig själv mot, publicerad skriftligt av dem som underhåller det beroendet.
De flesta företag skriver informella AI-riktlinjer som ingen upprätthåller. Rusts policy sticker ut eftersom den drar sin gräns vid en konkret, kontrollerbar punkt: författarskapet av committen. Ett team som granskar sina egna regler bör ställa sig samma snäva fråga som rust-lang just besvarat: når en AI-skriven ändring en merge utan en människa som testat den och står till svars för den? Ett ärligt ja betyder att den skrivna policyn bara finns på papper.
Läs vidare: 29 år gammalt Squid-fel läcker inloggningar i klartext | Microsoft Sätter Nu Tak För Egna Ingenjörers AI-Utgifter
