Rusts Entwurf einer LLM-Richtlinie zieht die richtige Grenze

Ein am 17. April 2026 geöffneter Pull Request in Rust Forge schlägt eine LLM-Nutzungsrichtlinie für rust-lang/rust vor. Am 17. Mai 2026 ist der Pull Request weiterhin offen, mit 65 Issue-Kommentaren und 284 Review-Kommentaren. Die vorgeschlagene Richtlinie ist also noch nicht übernommen.¹

Trotzdem ist der Entwurf schon jetzt wichtig, weil er die Grenze benennt, die die meisten Leitlinien für KI-gestützte Entwicklung meiden: LLMs können Menschen beim Denken, Lernen, Prüfen und Experimentieren helfen. Sie sollten menschliche Urheberschaft aber nicht dort ersetzen, wo ein Projekt Urteilskraft, Geschmack, Verantwortlichkeit und gemeinsames Verständnis bewahrt.²

Der Vorschlag passt außerdem zu den bestehenden Beitragsnormen von Rust. Der aktuelle Rust-Forge-Leitfaden für Beiträge fordert Mitwirkende bereits auf, Vertrauen aufzubauen, die Zeit der Reviewer zu respektieren, nur Arbeit einzureichen, die sie vollständig verstehen, ihre Arbeit vor dem Einreichen gründlich zu prüfen und Kommentare knapp zu halten.³ Auch die Compiler-Review-Richtlinie sagt, dass Reviewer ein ausreichendes Verständnis des geprüften Codes brauchen und nur begrenzt Review-Zeit haben.⁴ Der LLM-Entwurf macht diese älteren Erwartungen für KI-unterstützte Arbeit konkret.

Kurzfassung

Der Rust-Entwurf erlaubt private LLM-Nutzung zum Lernen, Zusammenfassen, privaten Prüfen, für persönliche Werkzeuge und Experimente.² Er verbietet öffentliche Kommentare, Issue-Beschreibungen, Pull-Request-Beschreibungen, Dokumentation, Compiler-Diagnosen und jeden Prozess, der eine LLM-Review als ausreichend betrachtet, um Code zu mergen oder abzulehnen.² Für von LLMs erstellte Codeänderungen schafft er einen engen Versuchsrahmen: angefragt, nicht kritisch, offengelegt, hochwertig, gut getestet und sowohl von Autor als auch Reviewer vollständig verstanden.² Meine Lesart: Die Richtlinie funktioniert, weil sie auf intellektuelle Verantwortungsübernahme optimiert, nicht auf Ausgabemenge.

Wichtigste Punkte

• Für Maintainer: Eine Richtlinie sollte Review-Kapazität, Projektstimme und Verantwortlichkeit schützen, bevor sie über Produktivität spricht.
• Für Teams mit KI-gestützter Entwicklung: Private Nutzung kann breit erlaubt sein. Bei öffentlicher Urheberschaft, Dokumentation, Diagnosen und Merge-Befugnis braucht es eine deutlich härtere Grenze.
• Für Mitwirkende: Offenlegung hilft nur, wenn der Mensch die Arbeit weiterhin verantwortet. „Das Modell hat es geschrieben” darf keine Ausrede werden.
• Für Tool-Entwickler: Review-Bots brauchen eigene Identitäten, Blockierbarkeit, geringen Falsch-Positiv-Druck und rein beratenden Status.
• Für Agententeams: Die beste Regel im Entwurf ist kulturell, nicht technisch: Nutzen Sie KI, um besser zu schreiben, nicht schneller.²

Der Entwurf trennt Denken von Urheberschaft

Die meisten LLM-Richtlinien werfen zwei unterschiedliche Handlungen in eine Kategorie: KI-Nutzung. Der Rust-Entwurf trennt private Denkarbeit von öffentlicher Urheberschaft.

Private Denkarbeit wird weitgehend erlaubt. Mitwirkende dürfen einem LLM Fragen zur Codebasis stellen, Kommentare für das eigene Verständnis zusammenfassen lassen, den eigenen Code oder Text privat prüfen, persönliche Entwicklerwerkzeuge bauen und mögliche Lösungswege generieren lassen, um daraus zu lernen, bevor sie ihre eigene Lösung schreiben.²

Bei öffentlicher Urheberschaft zieht der Entwurf die harte Grenze. Kommentare über ein persönliches Konto sind verboten, wenn sie ursprünglich von einem LLM erstellt wurden. Dieselbe Regel gilt für Issue-Beschreibungen und Pull-Request-Beschreibungen.² Auch Dokumentation, die ursprünglich von einem LLM stammt, ist verboten. Dazu gehören nicht triviale Quellkommentare, Doc-Kommentare, Sicherheitskommentare, mehrabsätzige Kommentare und Compiler-Diagnosen.²

Diese Unterscheidung ist richtig, weil öffentliche Artefakte die Projektstimme tragen. Compiler-Diagnosen, Sicherheitskommentare und Dokumentation verschieben nicht nur Informationen. Sie zeigen Benutzern, wie Rust denkt. Zugleich werden sie Teil der langfristigen Wartungslast des Projekts.

Von LLMs generierte Prosa kann geschliffen klingen und diese Last trotzdem vergrößern. Ein Reviewer muss dann fragen: Wer hat diese Formulierung gewählt, wer versteht die Auswirkung, wer verantwortet den Grenzfall, und wer behebt die Verwirrung später? Der Entwurf lässt nicht zu, dass Mitwirkende diese Verantwortung auslagern und zugleich die Glaubwürdigkeit eines menschlichen Kontos behalten.

Die stärkste Regel: Keine KI-Review als Merge-Befugnis

Der Entwurf verbietet, eine LLM-Review als ausreichende Bedingung zu behandeln, um eine Änderung zu mergen oder abzulehnen.² Review-Bots dürfen existieren, müssen aber beratend bleiben. Reviewer müssen einen LLM-Kommentar ausdrücklich bestätigen, bevor er einen Pull Request blockiert, und Autoren schulden weiterhin eine Selbstprüfung.²

Diese Regel vermeidet einen verlockenden Fehlermodus. Teams können KI-Review hinzufügen und den Arbeitsablauf sicherer nennen, obwohl das neue Werkzeug nur einen zweiten Strom von Behauptungen erzeugt, für dessen Bewertung niemand Zeit hat. Ein Bot kann echte Fehler finden. Er kann aber auch belanglose Einwände, veraltete Stilhinweise, halluzinierte Einschränkungen oder selbstsichere Kommentare zu Code produzieren, den er nicht verstanden hat.

Der Rust-Entwurf löst dieses Problem strukturell:

Der Punkt ist nicht, dass LLM-Review keinen Wert hat. Der Punkt ist, dass Review-Befugnis Menschen und dem Projektprozess gehört. Eine Maschine kann den Reviewer unterstützen. Sie kann nicht zum verantwortlichen Reviewer werden.

Die Code-Ausnahme ist absichtlich eng

Der Entwurf verbietet nicht jeden von LLMs erstellten Code. Er schafft einen Versuch für Codeänderungen, die fünf Bedingungen erfüllen: angefragt, nicht kritisch, hochwertig, gut getestet und gut geprüft.²

Jedes Wort leistet Arbeit.

Angefragt bedeutet, dass der Reviewer vorher zugestimmt hat, einen von LLMs erstellten Pull Request zu prüfen. Neue Mitwirkende dürfen für diesen Weg kein LLM verwenden, ohne zuerst mit demselben Reviewer zu sprechen, der dem PR zugewiesen ist.²

Nicht kritisch hält KI-erstellte Änderungen aus Bereichen heraus, in denen ein Fehler eine Soundness-Regression verursachen könnte. Der Entwurf nennt interne Werkzeuge als plausibler und Bereiche wie das Trait-System, den MIR-Aufbau oder das Query-System als wahrscheinlich ungeeignet.²

Hochwertig bedeutet, dass der Code mindestens denselben Standard wie andere Änderungen erfüllen muss. Der Entwurf weist PRs ausdrücklich zurück, die die Qualität der Codebasis verschlechtern.²

Gut getestet legt die Messlatte höher. Für von LLMs erstellte PRs gilt eine höhere Testerwartung, weil LLMs das Schreiben von Tests erleichtern. Wenn keine vorhandene Testsuite den Code abdeckt, muss der Autor eine neue schreiben oder den PR schließen.²

Gut geprüft bedeutet, dass Autor und Reviewer sich verpflichten, den Code vollständig zu verstehen. Die Review eines Projektmitglieds ersetzt keine Selbstprüfung.²

Dieser Versuch ist sinnvoll geformt. Er tut nicht so, als könne KI-erstellter Code nicht helfen. Er verweigert aber die bequeme Version eines „KI-unterstützten Beitrags”, bei der Mitwirkende einen Patch generieren, Maintainer ihn durchsortieren lassen und selbst keine menschliche Energie ins Verstehen investieren.

Besser, nicht schneller

Der wichtigste Satz des Entwurfs lautet, dass LLMs am besten funktionieren, wenn Menschen sie nutzen, um besser zu schreiben, nicht schneller.²

Dieser Satz sollte zum Standard für KI-gestützte Entwicklung werden.

Schnelligkeit allein verschiebt Arbeit von Autoren zu Reviewern. Mitwirkende sparen eine Stunde beim Generieren eines Patches, danach verbringen Maintainer drei Stunden damit, nützlichen Code von seltsamen Tests, aufgeblähten Kommentaren, vagen Diagnosen und nicht verantworteten Designentscheidungen zu trennen. Das Projekt verliert, selbst wenn der Diff am Ende kompiliert.

Besser stellt andere Fragen: Hat das Werkzeug dem Menschen zu einem schärferen Verständnis verholfen? Hat es einen Grenzfall gefunden, den der Autor geprüft hat? Hat es beim Entwurf eines Tests geholfen, den der Autor versteht? Macht es den endgültigen Beitrag leichter zu prüfen, zu warten und ihm zu vertrauen?

Der Rust-Entwurf macht diese Unterscheidung durchsetzbar. Private LLM-Nutzung kann das Verständnis des Autors verbessern. Öffentliche, von LLMs stammende Urheberschaft kann das gemeinsame Verständnis des Projekts schwächen. Experimenteller KI-erstellter Code darf nur weitergehen, wenn Anfrage, Umfang, Qualität, Tests und Review die zusätzliche Last tragen.

Diese Kombination ist besser als pauschaler Optimismus und pauschales Verbot. Sie sagt: Die Technologie darf helfen, aber das Projekt nimmt keine niedrig verantworteten Ergebnisse auf, nur weil ein Modell sie billig gemacht hat.

Der Moderationsabschnitt vermeidet Hexenjagden

Auch bei der Durchsetzung geht der Entwurf ungewöhnlich sorgfältig vor. Er sagt Mitwirkenden, dass sie nicht Detektiv spielen müssen, um LLM-Nutzung aufzudecken. Wenn ein Verstoß klar aussieht, verweisen Sie auf die Richtlinie. Wenn ein Fall grenzwertig wirkt, melden Sie ihn an die Moderatoren und machen weiter.²

Derselbe Abschnitt behandelt Unehrlichkeit über LLM-Nutzung als Code-of-Conduct-Thema, stellt aber auch klar, dass die Belästigung von Mitwirkenden wegen der Nutzung von LLMs nicht akzeptabel ist.² Diese Paarung ist wichtig. Eine Richtlinie, die Misstrauen einlädt, kann eine Community schneller vergiften als die KI-generierten Inhalte, die sie stoppen soll.

Gute KI-Richtlinien brauchen zwei Grenzen:

Der Entwurf legt Verantwortung auf die Mitwirkenden, ohne jeden Reviewer zum Ermittler zu machen. Das schützt die Review-Kultur genauso wie den Code.

Was andere Projekte übernehmen sollten

Der Rust-Vorschlag verdient Aufmerksamkeit, weil er Rollen definiert statt Stimmungen.

Nutzen Sie LLMs als:

• privaten Tutor;
• privaten Reviewer;
• Zusammenfasser für Ihr eigenes Verständnis;
• Hilfe beim Auffinden von Fehlern, wenn der Mensch den Fehler verifiziert;
• Quelle für Experimente, wenn der Reviewer zustimmt und der Umfang risikoarm bleibt.

Nutzen Sie LLMs nicht als:

• öffentlichen Autor Ihres Kommentars;
• Stimme der Projektdokumentation;
• Autor von Compiler-Diagnosen;
• Ersatz für menschliche Review;
• Ausrede für Tests, die Sie nicht geschrieben haben;
• Weg, Maintainer Code prüfen zu lassen, den Sie nicht verstehen.

Diese Liste gibt Maintainern etwas Besseres als ein moralisches Argument. Sie gibt ihnen eine Betriebsrichtlinie.

Meine Einschätzung

Der Entwurf passt zu dem Qualitätsproblem, das KI-gestützte Entwicklung erzeugt. Code wird billiger zu produzieren. Review-Aufmerksamkeit, Geschmack, Kohärenz, Projektstimme und soziales Vertrauen werden nicht billiger. Die Knappheit wandert nach oben.

Ein Projekt, das auf Ausgabemenge optimiert, wird seine Maintainer in plausiblen Diffs ertränken. Ein Projekt, das auf Verantwortungsübernahme optimiert, kann KI weiterhin nutzen, aber nur so, dass der menschliche Autor fähiger und der Reviewer weniger belastet wird.

Der Rust-Entwurf schützt die knappe Schicht. Er behandelt Diagnosen, Kommentare, Dokumentation und Review-Befugnis als Teil des Projekts, nicht als austauschbaren Text. Er behandelt Tests und Selbstprüfung als Pflichten, nicht als Zubehör. Er gibt Experimenten einen Weg, aber keinen Blankoscheck.

Das ist die richtige Richtung für ernsthafte Softwareprojekte. Die genauen Regeln können sich ändern, bevor Rust etwas übernimmt. Die zugrunde liegende Form sollte bleiben: KI kann Menschen helfen, bessere Arbeit zu leisten, aber der Mensch muss den Beitrag weiterhin verantworten.

FAQ

Ist diese Rust-Richtlinie übernommen?

Nein. Am 17. Mai 2026 existiert die Richtlinie als offener Rust-Forge-Pull-Request mit dem Titel „Add an LLM policy for rust-lang/rust.” Der aktuelle rust-lang/rust-forge-Main-Branch enthält src/policies/llm-usage.md noch nicht.¹⁵

Verbietet der Entwurf jede KI-Nutzung?

Nein. Der Entwurf erlaubt private LLM-Nutzung unter Bedingungen zum Lernen, Zusammenfassen, Prüfen, für persönliche Werkzeuge und zur Ideenfindung. Außerdem schafft er einen engen Versuch für offengelegten, angefragten, nicht kritischen, hochwertigen, gut getesteten und gut geprüften, von LLMs erstellten Code.²

Was verbietet der Entwurf?

Der Entwurf verbietet von LLMs stammende öffentliche Kommentare, Issue-Beschreibungen, Pull-Request-Beschreibungen, Dokumentation, Compiler-Diagnosen und die Behandlung einer LLM-Review als ausreichend, um Code zu mergen oder abzulehnen.²

Warum behandelt der Entwurf Dokumentation und Diagnosen so streng?

Dokumentation und Diagnosen tragen Projektstimme, Benutzerführung und langfristige Wartungspflichten. Der Entwurf erlaubt LLMs in manchen Fällen, bei der umliegenden Logik zu helfen, untersagt ihnen aber, die Meldungen selbst zu erstellen.²

Was sollten Teams mit KI-gestützter Entwicklung aus dem Vorschlag lernen?

Trennen Sie private Unterstützung von öffentlicher Urheberschaft. Verlangen Sie Offenlegung dort, wo KI andere Menschen betrifft. Halten Sie Review-Befugnis menschlich. Erhöhen Sie die Messlatte für Tests und Selbstprüfung, wenn KI beim Erstellen von Code hilft. Optimieren Sie auf bessere Arbeit, nicht auf mehr Ausgabe.

Quellen