Projekt polityki Rust dotyczącej LLM wyznacza właściwą granicę

Pull request do Rust Forge, otwarty 17 kwietnia 2026 roku, proponuje politykę użycia LLM dla rust-lang/rust. Według stanu na 17 maja 2026 roku pull request nadal pozostaje otwarty: ma 65 komentarzy w wątku issue i 284 komentarze recenzyjne, więc propozycja nie jest jeszcze przyjętą polityką.¹

Ten projekt jest ważny już teraz, bo nazywa granicę, której większość porad o kodowaniu z AI unika: LLM mogą pomagać ludziom myśleć, uczyć się, sprawdzać i eksperymentować, ale nie powinny zastępować ludzkiego autorstwa tam, gdzie projekt chroni osąd, wyczucie, odpowiedzialność i wspólne rozumienie.²

Propozycja pasuje też do dotychczasowych norm kontrybucji w Rust. Obecny przewodnik Rust Forge dla kontrybutorów już zaleca budowanie zaufania, szanowanie czasu osób recenzujących, zgłaszanie tylko takiej pracy, którą autor w pełni rozumie, szczegółowe sprawdzanie zmian przed wysłaniem oraz zwięzłe komentarze.³ Polityka recenzji kompilatora mówi również, że osoby recenzujące muszą wystarczająco rozumieć sprawdzany kod, a ich czas jest ograniczony.⁴ Projekt dotyczący LLM konkretyzuje te wcześniejsze oczekiwania dla pracy wspieranej przez AI.

W skrócie

Projekt Rust dopuszcza prywatne użycie LLM do nauki, podsumowań, prywatnej recenzji, osobistych narzędzi i eksperymentów.² Zakazuje publicznych komentarzy, treści issue, opisów pull requestów, dokumentacji i diagnostyki kompilatora pochodzących od LLM, a także każdego procesu, który traktuje recenzję wykonaną przez LLM jako wystarczającą do scalenia albo odrzucenia kodu.² Tworzy też wąski eksperyment dla zmian kodu stworzonych przez LLM: na wyraźną prośbę, w obszarach niekrytycznych, z ujawnieniem, wysoką jakością, dobrymi testami i pełnym zrozumieniem po stronie autora oraz osoby recenzującej.² Moja interpretacja: ta polityka działa, bo optymalizuje pod intelektualną odpowiedzialność za pracę, a nie pod liczbę rezultatów.

Najważniejsze wnioski

• Dla opiekunów projektu: polityka powinna chronić możliwości recenzji, głos projektu i odpowiedzialność, zanim zacznie mówić o produktywności.
• Dla zespołów kodujących z AI: prywatne użycie warto dopuścić szeroko, ale przy publicznym autorstwie, dokumentacji, diagnostyce i prawie do scalania trzeba postawić twardszą granicę.
• Dla kontrybutorów: ujawnienie pomaga tylko wtedy, gdy człowiek nadal odpowiada za pracę. „Model to napisał” nie może stać się wymówką.
• Dla twórców narzędzi: boty do recenzji potrzebują osobnych tożsamości, możliwości blokowania, małej presji fałszywych alarmów i statusu doradczego.
• Dla zespołów agentowych: najlepsza zasada w projekcie jest kulturowa, nie techniczna: używać AI, aby pisać lepiej, a nie szybciej.²

Projekt oddziela myślenie od autorstwa

Większość polityk dotyczących LLM wrzuca dwa różne działania do jednej kategorii: używania AI. Projekt Rust rozdziela je na prywatną analizę i publiczne autorstwo.

Prywatna analiza dostaje szerokie przyzwolenie. Kontrybutor może zadawać LLM pytania o bazę kodu, podsumowywać komentarze na własny użytek, prywatnie recenzować swój kod lub tekst, budować osobiste narzędzia deweloperskie oraz generować możliwe rozwiązania, aby się z nich uczyć przed napisaniem własnego rozwiązania.²

Przy publicznym autorstwie granica jest twarda. Projekt zakazuje komentarzy publikowanych z osobistego konta, jeżeli pierwotnie stworzył je LLM. Ta sama zasada obejmuje treści issue i opisy pull requestów.² Projekt zakazuje też dokumentacji pierwotnie stworzonej przez LLM, w tym nietrywialnych komentarzy w kodzie źródłowym, komentarzy dokumentacyjnych, komentarzy dotyczących bezpieczeństwa, komentarzy wieloakapitowych oraz diagnostyki kompilatora.²

To rozróżnienie jest trafne, bo publiczne artefakty niosą głos projektu. Diagnostyka kompilatora, komentarze dotyczące bezpieczeństwa i dokumentacja nie tylko przenoszą informacje. Uczą użytkowników, jak myśli Rust. Stają się też częścią długoterminowego ciężaru utrzymania projektu.

Proza wygenerowana przez LLM może brzmieć elegancko, a jednocześnie zwiększać ten ciężar. Osoba recenzująca musi wtedy zapytać: kto wybrał takie sformułowanie, kto rozumie jego konsekwencje, kto odpowiada za przypadek brzegowy i kto później naprawi wynikłe nieporozumienie? Projekt nie pozwala kontrybutorowi zlecić tej odpowiedzialności na zewnątrz, a zarazem zachować wiarygodności ludzkiego konta.

Najmocniejsza zasada: brak recenzji AI jako podstawy do scalenia

Projekt zakazuje traktowania recenzji wykonanej przez LLM jako wystarczającego warunku scalenia albo odrzucenia zmiany.² Boty recenzyjne mogą istnieć, ale muszą pozostać doradcze. Osoba recenzująca musi wyraźnie poprzeć komentarz LLM, zanim zablokuje on pull request, a autor nadal ma obowiązek samodzielnej recenzji.²

Ta zasada omija kuszącą pułapkę. Zespoły mogą dodać recenzję AI i nazwać przepływ pracy bezpieczniejszym, nawet jeśli nowe narzędzie tworzy tylko drugi strumień twierdzeń, którego nikt nie ma czasu ocenić. Bot może znaleźć prawdziwe błędy. Może też generować błahe zastrzeżenia, nieaktualne porady stylistyczne, zmyślone ograniczenia albo pewne siebie komentarze do kodu, którego nie zrozumiał.

Projekt Rust rozwiązuje ten problem strukturalnie:

Nie chodzi o to, że recenzja wykonana przez LLM nie ma wartości. Chodzi o to, że prawo do oceny należy do ludzi i procesu projektu. Maszyna może wspierać osobę recenzującą. Nie może zostać oficjalną osobą recenzującą.

Wyjątek dla kodu jest celowo wąski

Projekt nie zakazuje całego kodu stworzonego przez LLM. Tworzy eksperyment dla zmian kodu spełniających pięć warunków: są przygotowane na prośbę, niekrytyczne, wysokiej jakości, dobrze przetestowane i dobrze zrecenzowane.²

Każde z tych słów wykonuje konkretną pracę.

Na prośbę oznacza, że osoba recenzująca z góry zgodziła się sprawdzić pull request stworzony przez LLM. Nowi kontrybutorzy nie mogą użyć LLM w tej ścieżce, jeśli najpierw nie porozmawiają z tą samą osobą recenzującą, która została przypisana do PR.²

Niekrytyczne trzyma zmiany stworzone przez AI z dala od obszarów, w których pomyłka mogłaby spowodować regresję poprawności. Projekt wskazuje wewnętrzne narzędzia jako bardziej prawdopodobny obszar, a takie części jak system traitów, budowanie MIR czy system zapytań jako prawdopodobnie nieodpowiednie.²

Wysoka jakość oznacza, że kod musi spełniać co najmniej ten sam standard co inne zmiany. Projekt wprost odrzuca PR-y pogarszające jakość bazy kodu.²

Dobre testy podnoszą poprzeczkę. PR-y stworzone przez LLM podlegają wyższym oczekiwaniom testowym, bo LLM ułatwiają pisanie testów. Jeżeli żadna istniejąca suita testowa nie obejmuje danego kodu, autor musi napisać nową albo zamknąć PR.²

Dobra recenzja oznacza, że zarówno autor, jak i osoba recenzująca zobowiązują się w pełni rozumieć kod. Recenzja członka projektu nie zastępuje samodzielnej recenzji.²

Ten eksperyment ma sensowny kształt. Nie udaje, że kod stworzony przez AI nie może pomóc. Odrzuca też leniwą wersję „kontrybucji wspieranej przez AI”, w której kontrybutor generuje łatkę, prosi opiekunów projektu, aby ją przesiali, i nie wkłada ludzkiego wysiłku w jej zrozumienie.

Lepiej, nie szybciej

Najważniejsze zdanie projektu mówi, że LLM działają najlepiej wtedy, gdy ludzie używają ich, aby pisać lepiej, a nie szybciej.²

To zdanie powinno stać się domyślnym standardem kodowania z AI.

Sama szybkość przerzuca pracę z autorów na osoby recenzujące. Kontrybutor oszczędza godzinę na wygenerowaniu łatki, po czym opiekunowie projektu spędzają trzy godziny na oddzielaniu użytecznego kodu od dziwnych testów, rozdętych komentarzy, niejasnych diagnostyk i decyzji projektowych, za które nikt nie odpowiada. Projekt traci, nawet jeśli diff ostatecznie się kompiluje.

„Lepiej” zadaje inne pytanie: czy narzędzie pomogło człowiekowi lepiej zrozumieć problem? Czy znalazło przypadek brzegowy, który autor zweryfikował? Czy pomogło napisać test, który autor rozumie? Czy dzięki niemu końcowa kontrybucja jest łatwiejsza do sprawdzenia, utrzymania i obdarzenia zaufaniem?

Projekt Rust czyni to rozróżnienie egzekwowalnym. Prywatne użycie LLM może poprawić zrozumienie autora. Publiczne autorstwo pochodzące od LLM może osłabić wspólne rozumienie projektu. Eksperymentalny kod stworzony przez AI może iść dalej tylko wtedy, gdy prośba, zakres, jakość, testy i recenzja udźwigną dodatkowy ciężar.

Ta kombinacja jest lepsza niż bezwarunkowy optymizm i bezwarunkowy zakaz. Mówi: technologia może pomóc, ale projekt nie będzie przyjmował rezultatów pozbawionych jasnej odpowiedzialności tylko dlatego, że model uczynił je tanimi.

Sekcja moderacji unika polowań na czarownice

Projekt wyjątkowo ostrożnie podchodzi też do egzekwowania zasad. Mówi kontrybutorom, że nie muszą bawić się w detektywów od użycia LLM. Jeżeli naruszenie wygląda jasno, należy wskazać politykę. Jeżeli sprawa jest graniczna, należy zgłosić ją moderatorom i przejść dalej.²

Ta sama sekcja traktuje nieuczciwość w sprawie użycia LLM jako problem z kodeksem postępowania, ale równocześnie stwierdza, że nękanie kontrybutorów za używanie LLM jest niedopuszczalne.² Ta para jest ważna. Polityka zachęcająca do podejrzliwości może zatruć społeczność szybciej niż generowane przez AI treści, które próbuje zatrzymać.

Dobra polityka AI potrzebuje dwóch granic:

Projekt nakłada odpowiedzialność na kontrybutora, ale nie zmienia każdej osoby recenzującej w śledczego. Chroni to kulturę recenzji tak samo jak kod.

Co inne projekty powinny skopiować

Propozycja Rust zasługuje na uwagę, bo definiuje role zamiast nastrojów.

Używać LLM jako:

• prywatnego tutora;
• prywatnej osoby recenzującej;
• narzędzia do podsumowań na własny użytek;
• pomocy w wykrywaniu błędów, gdy człowiek weryfikuje błąd;
• źródła eksperymentów, gdy osoba recenzująca wyraża zgodę, a zakres pozostaje niskiego ryzyka.

Nie używać LLM jako:

• publicznego autora komentarza;
• głosu dokumentacji projektu;
• autora diagnostyki kompilatora;
• zamiennika ludzkiej recenzji;
• wymówki dla testów, których się nie napisało;
• sposobu na zmuszenie opiekunów projektu do sprawdzania kodu, którego autor nie rozumie.

Ta lista daje opiekunom projektu coś lepszego niż argument moralny. Daje im operacyjną politykę.

Moja interpretacja

Projekt odpowiada na problem jakościowy tworzony przez kodowanie z AI. Kod staje się tańszy w produkcji. Uwaga osób recenzujących, wyczucie, spójność, głos projektu i zaufanie społeczne nie tanieją. Rzadki zasób przesuwa się wyżej.

Projekt optymalizujący pod liczbę rezultatów utopi opiekunów w wiarygodnie wyglądających diffach. Projekt optymalizujący pod odpowiedzialność za pracę nadal może używać AI, ale tylko tak, aby ludzki autor stawał się bardziej kompetentny, a osoba recenzująca mniej obciążona.

Projekt Rust chroni deficytową warstwę. Traktuje diagnostykę, komentarze, dokumentację i prawo do recenzji jako część projektu, nie jako wymienny tekst. Traktuje testy i samodzielną recenzję jako obowiązki, nie dodatki. Daje eksperymentom ścieżkę, ale nie daje czeku in blanco.

To właściwy kierunek dla poważnych projektów programistycznych. Konkretne reguły mogą się zmienić, zanim Rust cokolwiek przyjmie. Podstawowy kształt nie powinien: AI może pomóc ludziom pracować lepiej, ale to człowiek musi nadal odpowiadać za kontrybucję.

FAQ

Czy ta polityka Rust została przyjęta?

Nie. Według stanu na 17 maja 2026 roku polityka istnieje jako otwarty pull request Rust Forge zatytułowany „Add an LLM policy for rust-lang/rust”. Obecna gałąź main repozytorium rust-lang/rust-forge nie zawiera jeszcze src/policies/llm-usage.md.¹⁵

Czy projekt zakazuje całego użycia AI?

Nie. Projekt warunkowo dopuszcza prywatne użycie LLM do nauki, podsumowań, recenzji, osobistych narzędzi i generowania pomysłów. Tworzy też wąski eksperyment dla ujawnionego, przygotowanego na prośbę, niekrytycznego, wysokiej jakości, dobrze przetestowanego i dobrze zrecenzowanego kodu stworzonego przez LLM.²

Czego projekt zakazuje?

Projekt zakazuje publicznych komentarzy, treści issue, opisów pull requestów, dokumentacji i diagnostyki kompilatora pochodzących od LLM, a także traktowania recenzji LLM jako wystarczającej do scalenia albo odrzucenia kodu.²

Dlaczego projekt tak surowo traktuje dokumentację i diagnostykę?

Dokumentacja i diagnostyka niosą głos projektu, wskazówki dla użytkowników i długoterminowe obowiązki utrzymaniowe. Projekt w niektórych przypadkach pozwala LLM pomagać przy otaczającej logice, ale nie pozwala LLM tworzyć samych komunikatów.²

Czego zespoły kodujące z AI powinny nauczyć się z tej propozycji?

Oddzielać prywatną pomoc od publicznego autorstwa. Wymagać ujawnienia tam, gdzie AI wpływa na innych ludzi. Utrzymywać ludzkie prawo do recenzji. Podnosić poprzeczkę testów i samodzielnej recenzji, gdy AI pomaga tworzyć kod. Optymalizować pod lepszą pracę, a nie większą produkcję.

Źródła