En måneds diskussion ender i en sætning
Den 5. august 2026 offentliggjorde de team, der vedligeholder Rust-compileren, standardbiblioteket, typesystemet, rustdoc og bootstrap, en formel LLM-politik for monorepoet rust-lang/rust og afsluttede dermed mere end en måneds intern debat, der nåede omkring 3.000 beskeder i projektets Zulip-chat. Ændringen kom som en pull request til styringsrepositoriet rust-lang/rust-forge, skrevet af Jynn Nelson (kendt på Zulip og GitHub som jyn514) - det samme repositorium, der allerede beskriver, hvordan projektet gennemgår, tester og udgiver compileren, som en stor del af verdens hukommelsessikkerhedskritiske software bygger på.
Inside Rusts opslag om annonceringen opsummerer resultatet i en sætning: 'Det er fint at bruge LLM'er til at besvare spørgsmål, analysere, sammenfatte, forfine, kontrollere, foreslå, gennemgå. Men ikke til at skabe.' Den sætning er politikken. Alt andet i dokumentet anvender den samme idé på et konkret element ad gangen: en dokumentationskommentar, en sikkerhedskommentar, en pull request-beskrivelse, en kodegennemgang.
Grænsen ligger ved forfatterskabet af commit'et
Reglen, der overlevede omkring 3.000 Zulip-beskeder, trækker sin grænse ved forfatterskabet af commit'et, ikke ved brugen af selve værktøjet. Rust-bidragydere kan bruge en LLM til at læse kode, analysere en fejl, sammenfatte en lang diskussionstråd eller forstå, hvordan et undersystem fungerer, og intet af det kræver offentliggørelse. I det øjeblik en LLM's output bliver til kode, der lander i en sammenlagt pull request, behandler politikken den som forbudt som standard.
Den snævre undtagelse er aftalt på forhånd og fuldt testet: en bidragyder, der vil committe LLM-skrevet kode, skal aftale omfanget med reviewere i forvejen, og den resulterende rettelse skal opfylde de samme krav som enhver menneskeskrevet ændring, uden genvej for at være maskingenereret. Uden for den aftale bliver en ugennemgået AI-rettelse ikke merget, uanset hvilke tests den påstår at bestå på sin egen branch.
Dokumentations- og sikkerhedskommentarer får samme regel
Politikken udvider skriveforbuddet til proseen omkring koden, ikke kun koden selv. Dokumentationskommentarer, sikkerhedskommentarer, pull request-beskrivelser og offentlige issue-tekster genereret af en LLM skal oplyses som maskingenereret eller er direkte forbudt, fordi en sikkerhedskommentar i usikker Rust er en påstand, en reviewer lægger til grund, og en uoplyst AI-påstand om, hvorfor en blok usikker kode er sikker, er præcis den fejl, hele politikken skal forhindre.
Pull requesten på rust-lang/rust-forge, der bærer ændringen, beskriver den som at skrive bedre, ikke hurtigere: målet er ikke at bremse bidragydere for princippets skyld, men at holde hver sætning, en reviewer stoler på, sporbar til en person, der står bag den. Et oplyst AI-udkast, som et menneske derefter omskriver og gør til sit eget, behandles anderledes end et uoplyst udkast, der udgives som original prosa.
AI-gennemgange forbliver rådgivende, aldrig en merge-lås
AI-genererede kodegennemgange er under den nye politik udtrykkeligt kun rådgivende, og ingen af dem kan alene låse en merge. En bot eller en bidragyders AI-assistent kan markere en fejl, foreslå en omstrukturering eller påpege en manglende test, men den godkendelse, der reelt frigiver en pull request, skal stadig komme fra en menneskelig reviewer, der anvender projektets eksisterende reviewstandarder.
Den forskel tæller mere i en compiler og et standardbibliotek end næsten alle andre steder i software, fordi en tilbagegang i hukommelsessikkerhed her ikke forbliver begrænset til en enkelt applikation - den fortsætter nedstrøms til hver crate og hver binærfil bygget på Rust. At behandle en AI-gennemgang som et forslag og ikke en lås holder ansvaret for, hvad der merges, hos en navngivet person, hver gang.
Hvorfor denne grænse betyder mere end et projekt
Rust bærer en uforholdsmæssig stor del af EU's og Storbritanniens fintech-, bil- og embedded-kodebaser, fra den danske fintech- og shippingsektor til den europæiske bilindustri, netop på grund af de hukommelsessikkerhedsgarantier, sproget håndhæver allerede ved kompilering - præcis den egenskab en ugennemgået, AI-genereret rettelse i det stille kunne undergrave, hvis den slap forbi review. En organisation, der er afhængig af Rust-baseret infrastruktur og samtidig i det stille sænker sin egen reviewgrænse for AI-understøttet kode, har nu et konkret målepunkt at holde sig selv op imod, offentliggjort skriftligt af dem, der vedligeholder afhængigheden.
De fleste virksomheder skriver uformelle AI-retningslinjer, som ingen håndhæver. Rusts politik skiller sig ud, fordi den trækker sin grænse ved et konkret, kontrollerbart punkt: forfatterskabet af commit'et. Et team, der efterser sine egne regler, bør stille sig det samme snævre spørgsmål, rust-lang lige har besvaret: når en AI-skrevet ændring frem til en merge uden et menneske, der har testet den og står til ansvar for den? Et ærligt ja betyder, at den skrevne politik kun findes på papiret.
Læs videre: 29 år gammel Squid-fejl lækker logins i klartekst | Microsoft Sætter Nu Loft Over Egne Ingeniørers AI-Forbrug
