KI-Modelle und Plattformen
Rust führt eine formelle LLM‑Richtlinie für sein Haupt‑Repository ein
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen
Fünf Teams im Rust‑Projekt haben eine formelle Richtlinie, die regelt, wie große Sprachmodelle verwendet werden können, wenn sie zu rust-lang/rust, dem Haupt‑Monorepo des Projekts, beitragen, Jynn Nelson, die Autorin der Richtlinie, im Inside Rust‑Blog angekündigt am 5. August 2026. Die Richtlinie (von den Teams Compiler, Libs, Types, rustdoc und Bootstrap ratifiziert) ersetzt, was Nelson als unveröffentlichte „wild west“‑Ansatz zur Moderation beschreibt, durch ein öffentliches, schriftliches Regelwerk.
Die Richtlinie ist keine projektweite Haltung zu KI und betont dies ausdrücklich. Sie gilt ausschließlich für das Repository rust-lang/rust und nur für die Teams, die sie ratifiziert haben. Innerhalb dieses Rahmens zeichnet sie jedoch eine klare Grenze: LLMs sind als Denkwerkzeuge willkommen, nicht als deren Ersatz.
Was die Richtlinie tatsächlich sagt
Das Dokument fasst sich selbst in einem einzigen Satz zusammen:
Es ist in Ordnung, LLMs zu verwenden, um Fragen zu beantworten, zu analysieren, zu destillieren, zu verfeinern, zu prüfen, Vorschläge zu machen und zu reviewen. Aber nicht zu erstellen.
In der Praxis führt das zu drei Stufen. Erlaubt uneingeschränkt: jede private Nutzung, bei der nur der Beitragende die Ausgabe sieht — Fragen zum Code‑Base stellen, einen Thread zusammenfassen, den eigenen Code privat reviewen. Erlaubt mit verpflichtender Offenlegung: maschinelle Übersetzung, triviale Änderungen wie Tippfehlerkorrekturen, LLM‑unterstützte Fehlersuche und LLM‑Review‑Bots, die von separaten, klar gekennzeichneten GitHub‑Accounts ausgeführt werden müssen, die einzelne Nutzer blockieren können. Verboten: von LLM erstellte Kommentare, Dokumentation und Compiler‑Diagnosen; jeder Prozess, der die Ausführung eines LLM erfordert; sowie die Behandlung einer LLM‑Review als ausreichende Grundlage zum Mergen oder Ablehnen einer Änderung.
Die schärfsten Zähne liegen im Durchsetzungsdesign. Die vorsätzliche Falschdarstellung der LLM‑Nutzung zählt als Verstoß gegen den Code of Conduct des Projekts — die gleiche Stufe wie Belästigung — und führt zu einer Warnung und bei wiederholten Verstößen zu einem Bann. Das Dokument stellt ausdrücklich fest, dass viele seiner Klauseln in der Praxis nicht durchsetzbar sind, und erklärt, dass dies beabsichtigt ist: „Unser Ziel ist es nicht, jede Verletzung zu erfassen… Stattdessen ist unser Ziel, plausible Abstreitbarkeit zu entfernen: eine Wahl zwischen der Befolgung der Richtlinie und einer vorsätzlichen Verletzung zu erzwingen.“
Ein begrenztes Experiment für von LLMs geschriebenen Code
Von LLMs erstellter Code ist nicht pauschal verboten. Er ist auf ein Experiment mit strengen Eintrittsbedingungen: Änderungen müssen im Vorfeld mit einem benannten Reviewer abgestimmt werden, dürfen nicht kritisch für die Korrektheit des Compilers sein, müssen gut getestet und gründlich geprüft werden, wobei in jedem Fall eine Offenlegung erforderlich ist. Neue Mitwirkende können keinen von LLM erstellten Pull‑Request öffnen, ohne zuerst einen Reviewer zu sichern. Gibt es keine Testsuite für den betroffenen Code, muss der Autor eine schreiben oder den PR schließen. Keine Ausnahmen.
Das Experiment verfügt über einen eigenen Schalter. Wenn mehr als die Hälfte der in einem Zeitraum von sechs Wochen gemergten PRs von LLMs erstellt wurden, werden das Mergen von LLM‑erstellten PRs gestoppt, bis der Anteil wieder unter 50 % fällt, mit einer Mindest‑Abkühlzeit von zehn Tagen. Der Zeitraum entspricht dem sechs‑wöchigen Release‑Zyklus von Rust. Alle solchen PRs erhalten das neue ai-assisted-Label und werden in einen privaten Zulip‑Kanal gepostet, dessen Zweck die Datenerhebung ist (ob LLM‑unterstützte Mitwirkende lernen, zurückkehren und nützliche Arbeit leisten), nicht die Zugangsbeschränkung.
Warum jetzt
Nelsons Ankündigung beschreibt drei Druckfaktoren, die die Teams von informeller Moderation zu schriftlichen Regeln getrieben haben. Aufwändige Pull‑Requests signalisieren nicht mehr Aufwand oder Verständnis, was die Vertrauenssignale, auf denen die Review‑Kultur des Projekts beruht, untergräbt. Günstigere Code‑Generierung verschärft einen bereits bestehenden Engpass bei der Review‑Kapazität: Das Repository enthält derzeit 1.281 offene PRs, und die knappe Ressource war immer das Urteil der Reviewer, nicht der Code. Und Mitwirkende, die auf Review‑Kommentare reagieren, indem sie sie in ein LLM einfügen und die Ausgabe zurückkopieren, verschwenden nach Nelsons Worten die Zeit aller und brechen die Annahme, dass ein Reviewer mit einer Person spricht.
Der Hintergrund ist eine echte Spaltung innerhalb des Projekts. Der Motivationsabschnitt der Richtlinie stellt fest, dass es innerhalb von Rust keinen Konsens gibt, „und wahrscheinlich nie geben wird“, darüber, wann KI‑basierte Werkzeuge akzeptabel sind, wobei die Mitglieder von täglichen Nutzern bis zu denen reichen, die jede Nutzung für inakzeptabel halten. Deshalb ist das Dokument so aufgebaut, dass es geändert werden kann: Größere Überarbeitungen erfordern die Zustimmung jedes ratifizierenden Teams, und die Richtlinie kann von diesen Teams vollständig aufgehoben oder von einem projektweiten LLM‑Ausschuss, den der Führungsausschuss nun erwägt, überstimmt werden.
Das Kleingedruckte
Der Anwendungsbereich ist enger als die Überschrift vermuten lässt. Die Richtlinie gilt nicht für andere Repositories der rust‑lang‑Organisation, für die Arbeit des Language‑Teams wie das Verfolgen von Issues und Stabilisations‑Reports, den Style‑Guide oder für Teams, die sie nicht ratifiziert haben. Jeder bleibt frei, eigene Regeln festzulegen. Mitglieder der rust‑lang‑Organisation sind von der „nicht‑kritischen“ Einschränkung für von LLMs erstellten Code ausgenommen, obwohl die Richtlinie stark davon abrät, diese Ausnahme zu nutzen, und PRs, die vor Inkrafttreten der Richtlinie geschrieben wurden, ebenfalls ausgenommen sind. Einen Mitwirkenden wegen der Nutzung eines LLM zu belästigen, ist selbst verboten, unabhängig davon, ob die Nutzung gegen die Richtlinie verstoßen hat.
Was als Nächstes passiert
Der private Zulip‑Kanal beginnt mit der Datenerfassung zu LLM‑erstellten PRs, sobald das ai-assisted-Label verwendet wird, und das erste sechs‑wöchige Schalt‑Fenster wird den Teams zeigen, ob das Experiment die Merge‑Warteschlange überlastet. Der noch ausstehende Vorschlag des Führungsausschusses für ein dediziertes LLM‑Komitee würde, falls er gebildet wird, Vorrang vor dieser Richtlinie erhalten und könnte die Regeln projektweit ausdehnen, sodass Chats, Foren und Repositories, die heute keinerlei Richtlinie haben, abgedeckt werden. Nelsons Beitrag argumentiert genau für dieses Ergebnis und stellt die Richtlinie als ersten Schritt dar, nicht als endgültige Lösung.
