Miesiąc spierania się kończy jedno zdanie

5 sierpnia 2026 roku zespoły, które utrzymują kompilator Rusta, bibliotekę standardową, system typów, rustdoc i bootstrap, opublikowały formalną politykę użycia LLM dla monorepo rust-lang/rust, zamykając ponad miesiąc wewnętrznej debaty, która doszła do około 3000 wiadomości na czacie Zulip projektu. Zmiana przyszła jako pull request do repozytorium zarządzania rust-lang/rust-forge, napisany przez Jynn Nelson (znanego na Zulipie i GitHubie jako jyn514) - tego samego repozytorium, które już dokumentuje, jak projekt recenzuje, testuje i wydaje kompilator, na którym opiera się duża część światowego oprogramowania krytycznego dla bezpieczeństwa pamięci.

Wpis ogłoszeniowy Inside Rust podsumowuje wynik jednym zdaniem: 'W porządku jest używać LLM do odpowiadania na pytania, analizowania, streszczania, dopracowywania, sprawdzania, proponowania, recenzowania. Ale nie do tworzenia.' To zdanie jest polityką. Wszystko inne w dokumencie stosuje tę samą ideę do jednego konkretnego elementu na raz: komentarza dokumentacyjnego, komentarza bezpieczeństwa, opisu pull requesta, recenzji kodu.

Granica przebiega przy autorstwie commita

Zasada, która przetrwała około 3000 wiadomości na Zulipie, wyznacza granicę przy autorstwie commita, a nie przy samym użyciu narzędzia. Współtwórcy Rusta mogą używać LLM do czytania kodu, analizowania błędu, streszczania długiego wątku dyskusji lub zrozumienia, jak działa podsystem, i nic z tego nie wymaga ujawnienia. W momencie, gdy wynik działania LLM staje się kodem, który trafia do zmergowanego pull requesta, polityka traktuje go jako domyślnie zakazany.

Wąski wyjątek jest uzgodniony wcześniej i w całości przetestowany: współtwórca, który chce zacommitować kod napisany przez LLM, musi uzgodnić zakres z recenzentami z wyprzedzeniem, a powstały patch musi przejść tę samą poprzeczkę, co każda zmiana napisana przez człowieka, bez skrótu za to, że został wygenerowany przez maszynę. Poza takim uzgodnieniem, nierecenzowany patch AI nie zostaje zmergowany, niezależnie od tego, jakie testy twierdzi, że przechodzi na własnym branchu.

Komentarze dokumentacyjne i bezpieczeństwa podlegają tej samej zasadzie

Polityka rozszerza zakaz pisania na prozę wokół kodu, a nie tylko na sam kod. Komentarze dokumentacyjne, komentarze bezpieczeństwa, opisy pull requestów i publiczne teksty zgłoszeń generowane przez LLM muszą być oznaczone jako wygenerowane przez maszynę albo są całkowicie zakazane, bo komentarz bezpieczeństwa w niebezpiecznym Ruscie to twierdzenie, na którym recenzent się opiera, a nieujawnione twierdzenie AI o tym, dlaczego blok niebezpiecznego kodu jest bezpieczny, to dokładnie ten błąd, któremu cała polityka ma zapobiegać.

Pull request w rust-lang/rust-forge, który wprowadza tę zmianę, opisuje ją jako pisanie lepiej, nie szybciej: celem nie jest zwalnianie współtwórców dla samego zwalniania, ale utrzymanie każdego zdania, któremu recenzent ufa, śledzonego do osoby, która za nim stoi. Ujawniony szkic AI, który człowiek następnie przepisuje i przejmuje, jest traktowany inaczej niż nieujawniony, podawany jako oryginalna proza.

Recenzje AI pozostają doradcze, nigdy nie są blokadą mergea

Recenzje kodu generowane przez AI są według nowej polityki wprost jedynie doradcze, i żadna z nich nie może samodzielnie zablokować ani zatwierdzić mergea. Bot lub asystent AI współtwórcy może oznaczyć błąd, zaproponować refaktoryzację lub wskazać brakujący test, ale zatwierdzenie, które faktycznie odblokowuje pull request, wciąż musi pochodzić od ludzkiego recenzenta stosującego istniejące standardy recenzji projektu.

Ta różnica liczy się bardziej w kompilatorze i bibliotece standardowej niż prawie wszędzie indziej w oprogramowaniu, bo regresja bezpieczeństwa pamięci nie zostaje tu ograniczona do jednej aplikacji - rozprzestrzenia się dalej do każdej crate i każdego pliku binarnego zbudowanego na Ruscie. Traktowanie recenzji AI jako propozycji, a nie blokady, utrzymuje odpowiedzialność za to, co zostaje zmergowane, przy konkretnej, nazwanej osobie, każdy raz.

Dlaczego ta granica wykracza poza jeden projekt

Rust stanowi nieproporcjonalnie dużą część kodu fintech, motoryzacyjnego i wbudowanego w UE i Wielkiej Brytanii - od polskiego sektora outsourcingu IT, który pisze wiele z tego kodu, do europejskiego przemysłu motoryzacyjnego - właśnie z powodu gwarancji bezpieczeństwa pamięci, które język wymusza już przy kompilacji - dokładnie tej właściwości, którą nierecenzowany, wygenerowany przez AI patch mógłby po cichu naruszyć, gdyby przeszedł przez recenzję niezauważony. Organizacja, która zależy od infrastruktury opartej na Ruscie, a jednocześnie po cichu obniża własny próg recenzji dla kodu wspomaganego przez AI, ma teraz konkretny punkt odniesienia, wobec którego może się zmierzyć, opublikowany na piśmie przez tych, którzy utrzymują tę zależność.

Większość firm pisze nieformalne wytyczne dotyczące użycia AI, których nikt nie wymusza. Polityka Rusta wyróżnia się, bo wyznacza granicę w konkretnym, sprawdzalnym punkcie: autorstwie commita. Zespół, który audytuje własne zasady, powinien zadać sobie to samo wąskie pytanie, na które rust-lang właśnie odpowiedział: czy zmiana napisana przez AI dociera do mergea bez człowieka, który ją przetestował i za nią odpowiada? Szczera odpowiedź tak oznacza, że spisana polityka istnieje tylko na papierze.

Czytaj dalej: 29-letni błąd Squida ujawnia loginy w postaci jawnej  |  Microsoft Ogranicza Teraz Wydatki Własnych Inżynierów Na AI