Een maand discussie eindigt in een zin

Op 5 augustus 2026 publiceerden de teams die de Rust-compiler, de standaardbibliotheek, het typesysteem, rustdoc en bootstrap onderhouden een formeel beleid voor het gebruik van LLM's in de rust-lang/rust-monorepo, en sloten daarmee meer dan een maand interne discussie af die uitkwam op ongeveer 3.000 berichten in de Zulip-chat van het project. De wijziging kwam als een pull request naar de governance-repository rust-lang/rust-forge, geschreven door Jynn Nelson (op Zulip en GitHub bekend als jyn514), dezelfde repository die al beschrijft hoe het project de compiler reviewt, test en uitlevert waarop een groot deel van de wereldwijde geheugenveiligheidskritische software steunt.

De aankondiging van Inside Rust vat het resultaat samen in een zin: 'Het is prima om LLM's te gebruiken om vragen te beantwoorden, te analyseren, samen te vatten, te verfijnen, te controleren, voor te stellen, te reviewen. Maar niet om te creëren.' Die zin is het beleid. Al het andere in het document past hetzelfde idee toe op een specifiek onderdeel per keer: een doc-commentaar, een safety-commentaar, een pull-request-beschrijving, een codereview.

De grens ligt bij het auteurschap van de commit

De regel die ongeveer 3.000 Zulip-berichten heeft doorstaan legt de grens bij het auteurschap van de commit, niet bij het gebruik van het gereedschap op zich. Rust-bijdragers mogen een LLM gebruiken om code te lezen, een bug te analyseren, een lange discussie samen te vatten of te begrijpen hoe een subsysteem werkt, en niets daarvan vereist een melding. Zodra de output van een LLM code wordt die in een gemergde pull request terechtkomt, behandelt het beleid dat standaard als verboden.

De beperkte uitzondering is vooraf afgesproken en volledig getest: wie door een LLM geschreven code wil committen, moet de omvang vooraf met reviewers afstemmen, en de resulterende patch moet dezelfde lat halen als elke door een mens geschreven wijziging, zonder kortere weg omdat het machinaal is gegenereerd. Buiten die afspraak wordt een ongereviewde AI-patch niet gemerged, welke tests hij ook op zijn eigen branch claimt te doorstaan.

Doc- en safety-commentaar krijgen dezelfde regel

Het beleid breidt het schrijfverbod uit naar de tekst rond de code, niet alleen de code zelf. Door een LLM gegenereerde doc-commentaar, safety-commentaar, pull-request-beschrijvingen en publieke issue-teksten moeten als machine-gegenereerd worden gemeld of zijn zonder uitzondering verboden, want een safety-commentaar in unsafe Rust is een uitspraak waarop een reviewer vertrouwt, en een niet-gemelde AI-uitspraak over waarom een blok unsafe code veilig is, is precies het falen dat het hele beleid wil voorkomen.

De pull request op rust-lang/rust-forge die de wijziging draagt, omschrijft dit als beter schrijven, niet sneller: het doel is niet om bijdragers te vertragen om het vertragen zelf, maar om elke zin waarop een reviewer vertrouwt herleidbaar te houden tot een persoon die ervoor instaat. Een gemelde AI-conceptversie die een mens vervolgens herschrijft en overneemt, wordt anders behandeld dan een niet-gemelde versie die als eigen tekst wordt gepresenteerd.

AI-reviews blijven adviserend, nooit een merge-slot

Door AI gegenereerde codereviews zijn onder het nieuwe beleid expliciet uitsluitend adviserend, en geen enkele kan op eigen kracht een merge blokkeren of goedkeuren. Een bot of de AI-assistent van een bijdrager mag een bug signaleren, een herstructurering voorstellen of op een ontbrekende test wijzen, maar de goedkeuring die een pull request daadwerkelijk vrijgeeft moet nog altijd komen van een menselijke reviewer die de bestaande reviewnormen van het project toepast.

Dat onderscheid telt zwaarder in een compiler en standaardbibliotheek dan bijna overal elders in software, omdat een geheugenveiligheidsregressie hier niet beperkt blijft tot een toepassing - ze stroomt verder in elke crate en elk binair bestand dat op Rust is gebouwd. Een AI-review behandelen als suggestie en niet als slot houdt de verantwoordelijkheid voor wat wordt gemerged elke keer bij een met naam genoemde persoon.

Waarom deze grens verder reikt dan een project

Rust draagt een onevenredig groot deel van de fintech-, automotive- en embedded-codebases van de EU en het Verenigd Koninkrijk, van de fintechsector in Amsterdam tot de chipindustrie rond Eindhoven, precies vanwege de geheugenveiligheidsgaranties die de taal al bij het compileren afdwingt - exact de eigenschap die een ongereviewde, door AI gegenereerde patch stilletjes zou kunnen ondermijnen als die de review passeerde. Een organisatie die afhankelijk is van op Rust gebaseerde infrastructuur en tegelijk in stilte de eigen reviewdrempel voor AI-ondersteunde code laat zakken, heeft nu een concreet ijkpunt om zichzelf aan te toetsen, schriftelijk gepubliceerd door wie die afhankelijkheid onderhoudt.

De meeste bedrijven schrijven informele AI-richtlijnen die niemand afdwingt. Het beleid van Rust valt op omdat het de grens trekt op een specifiek, controleerbaar punt: het auteurschap van de commit. Een team dat de eigen regels doorlicht, zou zich dezelfde beperkte vraag moeten stellen die rust-lang net heeft beantwoord: bereikt een door AI geschreven wijziging een merge zonder een mens die ze heeft getest en ervoor instaat? Een eerlijk ja betekent dat het geschreven beleid alleen op papier bestaat.

Lees hierna: 29 jaar oude Squid-fout lekt logins in leesbare tekst  |  Microsoft Beperkt Nu Wat Eigen Ingenieurs Aan AI Uitgeven