Rust führt neue Regeln für die KI-Programmierung ein: Es kann Ihnen beim Überprüfen helfen, aber nicht an Ihrer Stelle schreiben, und bei übermäßiger Nutzung wird ein „Circuit Breaker“ ausgelöst.

Diese Woche haben fünf Teams im Rust-Projekt offiziell eine neue Richtlinie für die KI-Programmierung verabschiedet, die regelt, wie Mitwirkende Large Language Models (LLMs) bei der Einreichung von Code an rust-lang/rust einsetzen dürfen.

rust-lang/rust ist das zentrale monolithische Code-Repository des Rust-Projekts. Jynn Nelson, der Autor der Richtlinie, kündigte diese Nachricht am 5. August 2026 im Inside Rust-Blog an.

Zusammengefasst lässt sich das Kernprinzip dieses Dokuments in einem Satz ausdrücken:

LLMs dürfen zum Beantworten von Fragen, Analysieren, Verfeinern, Verbessern, Überprüfen, Vorschlagen von Maßnahmen und Durchführen von Reviews verwendet werden – aber nicht zum Erstellen von neuem Inhalt.

Diese Richtlinie wurde von den fünf Teams für Compiler, Standardbibliothek, Typsystem, rustdoc und Bootstrap genehmigt. Sie ersetzt die bisherige, von Nelson als „Wilder Westen“ bezeichnete Verwaltung ohne offizielle Regeln durch eine Reihe öffentlicher, schriftlich festgehaltener Vorschriften.

Allerdings gilt sie derzeit nur für das Repository rust-lang/rust und bindet nur die Teams, die die Richtlinie verabschiedet haben. In diesem Rahmen zieht sie eine sehr klare Grenze: LLMs sind als Denkwerkzeug willkommen, aber sie dürfen nicht an die Stelle des eigenen Denkens treten.

Was genau darf KI bei Rust tun?

Jynn Nelson stellte diese neue Regelung im Inside Rust-Blog vor:

Niemand ist verpflichtet, von LLMs generierte Inhalte zu lesen, wenn er dies nicht wünscht. Ausgaben von LLMs dürfen nicht in öffentlichen Dokumenten, PR-Beschreibungen oder GitHub-Kommentaren erscheinen, ohne ausdrücklich gekennzeichnet zu sein; wenn Prüfer keine von LLMs mit erstellten PRs prüfen möchten, können sie diese direkt ablehnen.

Für Beiträge an rust-lang/rust wird niemand gezwungen, LLMs zu verwenden. Alle Richtlinien müssen zuerst für Menschen verfasst werden, bevor sie in eine maschinenlesbare Fassung umgewandelt werden; die Ergebnisse von LLM-Reviews dürfen keine menschliche Prüfung und auch keine eigene Überprüfung des Autors ersetzen.

Sie können LLMs privat verwenden, ohne dies offenlegen zu müssen, solange die generierten Inhalte nur für Sie selbst bestimmt sind und nicht an Orten veröffentlicht werden, an denen Mitglieder des Rust-Projekts sie lesen oder prüfen müssen.

Wenn Sie LLMs für maschinelle Übersetzungen, „kleine Änderungen“, das Auffinden von Fehlern oder die Prüfung der Arbeit anderer verwenden, muss die Beteiligung von LLMs offengelegt werden. Rust begrüßt es zudem, wenn Mitwirkende direkt in ihrer Muttersprache kommunizieren, es ist nicht erforderlich, den Inhalt zuerst ins Englische zu übersetzen, um Beiträge einzureichen.

Zusammengefasst lautet die Regel: „Man darf denken, prüfen und übersetzen – nur nicht neu erstellen“. In der praktischen Umsetzung gliedert sich dies grob in drei Ebenen.

Die erste Kategorie ist uneingeschränkt erlaubt: Jede private Nutzung, bei der nur der Mitwirkende selbst die LLM-Ausgabe sieht. Beispielsweise das Stellen von Fragen zum Code-Repository an ein LLM, das Zusammenfassen eines Diskussionsfadens oder die private Prüfung des selbst geschriebenen Codes durch das LLM.

Die zweite Kategorie ist nutzbar, muss aber offengelegt werden: Dazu gehören maschinelle Übersetzungen, kleine Änderungen wie die Korrektur von Rechtschreibfehlern, das Auffinden von Fehlern mit Hilfe von LLMs sowie der Einsatz von LLM-Code-Review-Robotern. Für Review-Roboter schreibt die Richtlinie vor, dass diese über unabhängige, eindeutig gekennzeichnete GitHub-Konten betrieben werden müssen, damit Nutzer, die solche Inhalte nicht sehen möchten, sie direkt blockieren können.

Die dritte Kategorie ist ausdrücklich verboten: Dazu gehören die direkte Generierung von Kommentaren, Dokumenten und Compiler-Diagnoseinformationen durch LLMs; alle Abläufe, die zur Ausführung zwingend auf ein LLM angewiesen sind; sowie die Entscheidung, eine Änderung zusammenzuführen oder abzulehnen, nur weil das LLM ein entsprechendes Review-Ergebnis ausgegeben hat.

Der wirklich bindende Teil dieser Richtlinie liegt in ihrer Durchsetzungsform.

Wenn jemand absichtlich verschweigt oder falsch angibt, dass er ein LLM verwendet hat, wird dies als Verstoß gegen den Verhaltenskodex des Rust-Projekts eingestuft und gilt als gleichwertig mit Belästigung. Bei erstmaligem Verstoß kann eine Verwarnung ausgesprochen werden, bei wiederholtem Verstoß kann der Zugriff gesperrt werden.

Das Dokument stellt gleichzeitig klar, dass viele dieser Vorschriften technisch nicht vollständig durchgesetzt werden können – und dies ist absichtlich so. In der Richtlinie heißt es: „Unser Ziel ist es nicht, jeden einzelnen Verstoß aufzudecken... Unser Ziel ist es, jeden Raum für Ausreden zu beseitigen: Die Menschen müssen die Wahl treffen, die Richtlinie einzuhalten oder sie absichtlich zu verletzen.“

Rust ist nicht das einzige Projekt, das beginnt, Grenzen für LLMs zu setzen, und der Vergleich mit Zig ist sehr aufschlussreich.

Die strenge Regel von Zig, die LLMs/KI vollständig zu verbieten, ist noch radikaler: Sie verbietet nicht nur von LLMs generierten Code und Text, sondern auch das Umschreiben oder Nacherzählen von LLM-Inhalten, zudem ist der Einsatz von KI für Bearbeitung, Übersetzung, Brainstorming oder Fehlersuche unzulässig. Das Konzept von Zig hat niedrige Durchsetzungskosten, ist aber für Mitwirkende mit hohen Aufwand bei der Einhaltung verbunden. Bei Rust ist es genau umgekehrt: Es verlangt von den Prüfern mehr Urteilskraft, erlaubt aber Mitwirkenden, die LLM-Tools weiter zu verwenden, die sie ohnehin nutzen.

Wenn zu viel KI-Code geschrieben wird, löst der „Sicherungsausschalter“ aus

Rust verbietet das Schreiben von Code durch LLMs nicht vollständig, sondern beschränkt diese Art von Beiträgen auf ein Experiment mit sehr klar abgegrenzten Grenzen.

Zuerst muss jede von einem LLM erstellte Änderung im Vorfeld mit einem ausdrücklich benannten Prüfer abgesprochen werden; diese Änderungen dürfen keine kritischen Teile wie die Compiler-Soundness betreffen; sie müssen umfassend getestet und einer gründlichen menschlichen Prüfung unterzogen werden; und in jedem Fall muss die Beteiligung von LLMs offengelegt werden.

Neue Mitwirkende unterliegen besonders strengen Beschränkungen. Wenn Sie bisher noch nicht an dem Projekt teilgenommen haben, dürfen Sie keine von einem LLM erstellte Pull Request direkt einreichen, Sie müssen zuerst einen Prüfer finden, der bereit ist, die Verantwortung für die Prüfung zu übernehmen. Wenn der Codebereich, den Sie ändern möchten, keine vorhandene Testsuite hat, müssen Sie selbst eine vollständige Testreihe erstellen – andernfalls muss die PR geschlossen werden. Es gibt keine Ausnahmen.

Dieses Experiment hat sogar einen eigenen „Sicherungsausschalter“ eingerichtet.

Wenn in einem beliebigen Sechswochen-Zeitfenster mehr als die Hälfte der zusammengeführten PRs von LLMs erstellt wurden, wird die Zusammenführung aller von LLMs erstellten PRs ausgesetzt, bis ihr Anteil wieder unter 50 % sinkt und mindestens eine Abkühlphase von 10 Tagen vergangen ist.

Der Sechswochen-Zyklus wurde nicht willkürlich gewählt, er stimmt genau mit dem sechswöchigen Veröffentlichungszyklus von Rust überein.

Alle solchen PRs erhalten das neue Label „ai-assisted“ und werden in einem privaten Zulip-Kanal synchronisiert. Zweck dieses Kanals ist es nicht, neue Hürden für die Prüfung aufzubauen, sondern Daten zu sammeln: Beispielsweise, ob Mitwirkende mit LLM-Unterstützung tatsächlich lernen, danach weiterhin am Projekt teilnehmen und am Ende in der Lage sind, dauerhaft wertvolle Arbeit zu leisten.

Nelson nennt in der Ankündigung drei Druckfaktoren, die diese Teams dazu veranlasst haben, von der bisherigen informellen Verwaltung zu explizit schriftlich festgehaltenen Regeln überzugehen.

Das erste Problem: Eine Pull Request, die sehr gut strukturiert aussieht, lässt nicht mehr darauf schließen, dass der Autor tatsächlich viel Aufwand investiert hat und den darin enthaltenen Code wirklich versteht.

Früher, wenn ein Open-Source-Projekt eine gut strukturierte, umfassend getestete und detailliert beschriebene PR erhielt, gingen Prüfer normalerweise davon aus, dass die Person dahinter viel Zeit investiert hat und ein gewisses Verständnis für den eingereichten Inhalt hat. Im Zeitalter der LLMs verliert dieses Signal seine Gültigkeit, und die Code-Review-Kultur des Rust-Projekts stützte sich bisher stark auf dieses Vertrauen.

Das zweite Problem: Mit sinkenden Kosten für die Code-Generierung werden die ohnehin knappen Ressourcen für die Prüfung noch stärker belastet. Derzeit gibt es im Repository rust-lang/rust noch 1281 nicht abgeschlossene PRs. Die wirklich knappe Ressource im Rust-Projekt war nie der Code selbst, sondern die Urteilskraft und die Zeit der Prüfer. LLMs ermöglichen es einer Person, sehr schnell mehr Code zu erstellen, aber sie erhöhen nicht gleichzeitig die Anzahl der Personen, die beurteilen können, ob dieser Code in das Projekt aufgenommen werden soll.

Das dritte Problem: Einige Mitwirkende beginnen, die Kommentare der Prüfer in das LLM zu kopieren und die Antwort des LLM anschließend wieder auf GitHub einzufügen. Nach Nelsons Aussage verschwendet dieses Vorgehen „die Zeit aller Beteiligten“. Denn wenn Prüfer wissen möchten, was das LLM denkt, können sie es selbst befragen. Was die Code-Prüfung wirklich braucht, ist das eigene Urteil und das Verständnis des Mitwirkenden.

Dieses Vorgehen untergräbt zudem eine grundlegende Annahme der Code-Prüfung: Prüfer gehen normalerweise davon aus, dass sie mit einer echten Person kommunizieren, die das Problem wirklich versteht und auf das Feedback reagiert.

Sogar die Mitglieder von Rust selbst konnten sich nicht einigen, ob KI verwendet werden darf

Hinter dieser Richtlinie verbirgt sich ein wichtiger Hintergrund: Innerhalb des Rust-Projekts gibt es deutliche Meinungsverschiedenheiten zur Haltung gegenüber KI.

In der Begründung der Richtlinie heißt es ausdrücklich, dass es innerhalb von Rust bisher keinen Konsens darüber gibt, wann und auf welche Weise KI-Tools verwendet werden dürfen – „und es sehr wahrscheinlich nie einen Konsens geben wird“.

Die Standpunkte der Projektmitglieder reichen weit auseinander: Einige verwenden KI-Tools täglich, andere halten jede Form der KI-Nutzung für unakzeptabel, und viele befinden sich noch in einer Phase des Abwartens und Nachdenkens. Aus diesem Grund wurde diese Richtlinie von Anfang an so konzipiert, dass sie angepasst werden kann. Für zukünftige größere Überarbeitungen muss jedes Team, das die Richtlinie bereits genehmigt hat, erneut zustimmen. Gleichzeitig können diese Teams auch beschließen, die Richtlinie vollständig aufzuheben.

Zudem erwägt das Leitungsgremium von Rust derzeit, einen projektweiten LLM-Ausschuss zu gründen. Wenn dieser Ausschuss gebildet wird, können seine zukünftig erlassenen projektweiten Regeln die vorliegende Richtlinie direkt außer Kraft setzen.

Allerdings ist der tatsächliche Geltungsbereich dieser Richtlinie deutlich kleiner als der Titel vermuten lässt.

Sie gilt nicht für andere Code-Repositories der rust-lang-Organisation und auch nicht für einige Arbeiten des Sprachteams, beispielsweise Issue-Verfolgung und Stabilitätsberichte.

Der Style-Guide von Rust unterliegt ebenfalls nicht dieser Richtlinie. Teams, die die Richtlinie noch nicht verabschiedet haben, sind ebenfalls nicht gebunden – jedes Team kann weiterhin eigene Regeln festlegen.

Für interne Mitglieder der rust-lang-Organisation gibt es eine Ausnahme: Sie unterliegen nicht der Beschränkung „keine Änderungen an kritischem Code vorzunehmen“, wenn sie LLMs zum Erstellen von Code verwenden. Die Richtlinie stellt aber ausdrücklich klar, dass die Nutzung dieser Ausnahme stark abgeraten wird.

Zudem gelten für PRs, die vor dem Inkrafttreten der Richtlinie eingereicht wurden, die neuen Regeln nicht.

Ein weiterer Punkt ist erwähnenswert: Selbst wenn ein Mitwirkender tatsächlich gegen die LLM-Nutzungsrichtlinie verstößt, darf niemand ihn wegen der Verwendung von LLMs belästigen. Belästigung selbst verstößt ebenfalls gegen den Verhaltenskodex des Rust-Projekts.

Nach sechs Wochen entscheidet Rust, ob die Nutzung weiterhin erlaubt bleibt

Sobald das Label „ai-assisted“ offiziell aktiviert ist, beginnt Rust, Daten zu von LLMs erstellten PRs über den privaten Zulip-Kanal zu sammeln.

Der erste Sechswochen-Zyklus wird diesen Teams helfen, zu beurteilen, ob die Zulassung von LLM-Code-Beiträgen in einem definierten Rahmen die vorhandene Zusammenführungswarteschlange weiter überlasten wird.

Gleichzeitig diskutiert das Leitungsgremium von Rust die Gründung eines speziellen LLM-Ausschusses. Wenn dieser Ausschuss endgültig gebildet wird, haben seine Regeln eine höhere Priorität als die aktuelle Richtlinie, und die Regeln können sich von dem Code-Repository rust-lang/rust auf das gesamte Rust-Projekt erstrecken.

Zu diesem Zeitpunkt werden möglicherweise auch Chat-Kanäle, Foren und andere Code-Repositories, für die es bisher keine expliziten KI-Richtlinien gibt, in die einheitlichen Regelungen einbezogen.

Nelson unterstützt diese Richtung in ihrem Artikel. Ihrer Ansicht nach ist die vorliegende Richtlinie nur ein erster Schritt und nicht die endgültige Antwort darauf, wie Rust mit LLMs umgehen soll.

Referenzlinks:

https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/#what-does-the-policy-say

Dieser Artikel stammt aus dem WeChat-Offiziellen Konto „InfoQ“, Autor: Tina, veröffentlicht mit Genehmigung von 36Kr.