Rust: w głównym repozytorium AI recenzuje, nie pisze

Wolno pytać model, wolno kazać mu streścić, sprawdzić, uporządkować i zrecenzować cudzą pracę. Nie wolno kazać mu jej stworzyć. Na takim podziale stanął projekt Rust, który ogłosił własną politykę korzystania z dużych modeli językowych. Podpisało się pod nią pięć zespołów, a obowiązuje w głównym repozytorium rust-lang/rust, nie w całym projekcie. To ważna różnica, bo w nagłówkach zdarzy się pewnie skrót “Rust zakazał AI”. Nic takiego się nie stało i sam dokument mówi coś dokładnie odwrotnego.

Co przyjął projekt Rust i gdzie ta zasada obowiązuje

Zasada obowiązuje w monorepozytorium rust-lang/rust i tylko tam. Zbudowano ją wokół jednego zdania. W tłumaczeniu brzmi ono tak: korzystanie z modeli językowych do odpowiadania na pytania, analizy, streszczania, dopracowywania, sprawdzania, sugerowania i recenzowania jest w porządku, ale nie do tworzenia. Siedem czynności dozwolonych, jedna wykluczona.

Rozróżnienie wygląda na oczywiste dopiero wtedy, gdy ktoś je nazwie. Do tej pory dyskusja w projektach otwartego oprogramowania toczyła się w kategoriach “wolno albo nie wolno używać AI”, jakby to była jedna czynność. A to jest kilkanaście różnych czynności o zupełnie różnym ryzyku. Model, który sprawdza, czy w zgłoszeniu nie ma literówki albo czy testy pokrywają nowy przypadek, niczego nie wnosi do repozytorium. Model, który pisze łatkę, wnosi kod, za który ktoś potem odpowiada.

Osobno wymieniono dwie rzeczy zakazane. Publiczna dokumentacja i opisy zgłoszeń zmian nie mogą pochodzić od modelu, jeśli nie są wyraźnie oznaczone. Zmiany krytyczne dla poprawności języka, czyli te decydujące o tym, że program w Rust nie odwoła się do nieistniejącej pamięci, są wyłączone całkowicie.

Kiedy kod od modelu może wejść do repozytorium

Furtka istnieje, tylko jest wąska i ma pięć zamków naraz. Wpis dopuszcza zmiany pierwotnie stworzone przez model, jeśli są uzgodnione wcześniej, niekrytyczne, wysokiej jakości, dobrze przetestowane i dobrze zrecenzowane. Do tego z ujawnieniem, czyli autor musi napisać, że kod pochodzi od modelu.

Wszystkie te warunki muszą wystąpić razem, więc mają utrudnić masowe zgłaszanie wygenerowanych łatek. “Uzgodnione wcześniej” jest tu najmocniejszym filtrem. Ktoś z projektu musiał się zgodzić, zanim praca w ogóle powstała, więc nie da się postawić opiekunów przed faktem dokonanym.

Obowiązek ujawnienia zasługuje na osobne zdanie, bo dotyczy nie tylko kodu. Publiczna dokumentacja i opisy zgłoszeń zmian napisane przez model mają być oznaczone, tak samo jak kod dopuszczony na zasadzie wyjątku. Recenzent nie musi zgadywać, z kim rozmawia.

Wąskim gardłem jest przegląd kodu, nie jego pisanie

Autorzy podali trzy powody i w żadnym nie ma niechęci do technologii. Pierwszy jest społeczny: dopracowana forma zgłoszenia przestała być sygnałem, że ktoś włożył w nie pracę i rozumie, co proponuje. Wcześniej porządny opis i czysty kod mówiły recenzentowi, że po drugiej stronie jest ktoś poważny. Teraz nie mówią nic.

Drugi jest arytmetyczny. Autorzy piszą o istniejącym już problemie z przepustowością recenzji, a modele obniżyły koszt wyprodukowania zgłoszenia niemal do zera. Koszt jego sprawdzenia się nie zmienił. Rosnąca kolejka zgłoszeń nie jest sukcesem, tylko zatorem.

Trzeci jest najbardziej praktyczny i najłatwiejszy do rozpoznania w każdej firmie. Kiedy autor przekleja uwagi recenzenta do modelu, a odpowiedź modelu z powrotem do dyskusji, dwie osoby przestają rozmawiać ze sobą. Rozmawiają dwa modele, tyle że w wolnym czasie żywych ludzi. To ten sam mechanizm, o który poszło w decyzji Godota o odrzucaniu kodu od AI i w polityce projektu GCC, z tą różnicą, że Rust zamiast zamykać drzwi rozdzielił czynności.

Frontend Master 2026 · Kodożercy

Wreszcie rozumiesz, dlaczego kod od AI raz działa, a raz nie

Frontend Master 2026 to pakiet sześciu kursów Kodożerców, który daje Ci język do prowadzenia kodu od AI: poprawiania, łączenia, rozszerzania i szybkiego znajdowania linijki, którą trzeba zmienić. Bez teorii dla samej teorii.

Wchodzę w to →

Zasada, którą da się przepisać do własnego zespołu

Większość firm próbuje ustalić u siebie jedną granicę: wolno albo nie wolno. Rust pokazuje, że pytanie jest źle postawione. Sensowniej jest wypisać czynności i przy każdej zdecydować osobno, bo streszczenie dokumentacji i napisanie modułu płatności to nie ta sama sprawa.

Drugi element wart skopiowania to obowiązek ujawnienia. Nie po to, żeby kogoś przyłapać, tylko po to, żeby osoba sprawdzająca wiedziała, na co patrzy. Kod od modelu czyta się inaczej niż kod od kolegi z zespołu, bo w tym pierwszym błędy bywają pewne siebie i ładnie sformatowane.

Warto też wiedzieć, czego w tym dokumencie nie ma. Nie podano daty wejścia w życie ani tego, co się stanie osobie, która polityki nie dotrzyma. To istotna luka, bo bez niej nie wiadomo, co się dzieje po złamaniu zasady. Czy sama polityka wystarczy przy skali, o której mówią autorzy, pokaże dopiero kolejka zgłoszeń za pół roku.

Podsumowanie

Zamiast pytać, czy w projekcie wolno używać sztucznej inteligencji, projekt Rust rozpisał to na czynności. Analiza, sprawdzanie, sugerowanie i recenzowanie zostały dopuszczone. Tworzenie kodu jest wyłączone poza wąskim wyjątkiem, który wymaga wcześniejszego uzgodnienia, niekrytycznego zakresu, testów, recenzji i wyraźnego ujawnienia. Publiczna dokumentacja i opisy zgłoszeń od modelu wymagają oznaczenia, a zmiany decydujące o poprawności języka są wyłączone całkowicie. Zasada obowiązuje w repozytorium rust-lang/rust, więc to nie jest stanowisko całego projektu ani tym bardziej całej branży. Jest za to gotowy szkielet rozmowy, którą prędzej czy później odbędzie u siebie każdy zespół piszący kod: nie “czy AI”, tylko “do której konkretnie czynności”.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.