Pop!_OS zakazuje wprowadzania kodu generowanego przez AI do bazy systemu

Twórcy popularnej dystrybucji Linuksa, Pop!_OS, podjęli radykalne kroki w celu ochrony swojego ekosystemu przed zalewem maszynowo tworzonego oprogramowania. Firma System76 zaktualizowała zasady przyjmowania wkładu do repozytoriów swojego autorskiego środowiska graficznego COSMIC, wprowadzając bezwzględny zakaz nadsyłania kodu, komentarzy oraz opisów wygenerowanych przez modele językowe (LLM / AI). Każdy programista zgłaszający zmiany w serwisie GitHub musi od teraz formalnie potwierdzić, że w jego propozycji nie ma ani jednej linijki wygenerowanej przez sztuczną inteligencję. Decyzja ta stanowi bezpośrednią odpowiedź na przeciążenie inżynierów weryfikujących nadsyłane łatki i stawia Pop!_OS w awangardzie projektów otwartoźródłowych stawiających tamę bezrefleksyjnej automatyzacji.

Nowe zasady w repozytoriach COSMIC: obowiązkowa deklaracja braku udziału AI

Podstawą nowej polityki jest zaktualizowany wzorzec zgłoszeń (PULL_REQUEST_TEMPLATE.md), który pojawił się w kluczowych repozytoriach organizacji na GitHubie, w tym w nadrzędnym projekcie pop-os/cosmic-epoch. Zanim propozycja zmian trafi do oceny technicznej, autor musi zaznaczyć obowiązkowe pole wyboru, zaświadczające o braku maszynowego wkładu.

Formuła deklaracji nie pozostawia miejsca na interpretację i brzmi verbatim:

„I have not included any LLM (also known as AI) generated content in this PR, including code, comments, and descriptions” (Nie zawarłem w tym PR żadnych treści wygenerowanych przez LLM, zwany również AI, w tym kodu, komentarzy ani opisów).

Zakaz dotyczy więc nie tylko właściwego kodu źródłowego pisanego w języku Rust, na którym opiera się nowe środowisko COSMIC, lecz również komentarzy wewnątrz plików oraz treści samego opisu zgłoszenia. Pull requesty, w których autor pominie zaznaczenie tego punktu lub w których recenzenci wykryją kod wygenerowany przez generatywne modele sztucznej inteligencji, podlegają natychmiastowemu zamknięciu bez merytorycznej dyskusji.

W całej strukturze projektów przewidziano tylko jeden wyraźny wyjątek: repozytorium cosmic-flatpak. Wynika to z faktu, że manifesty pakietów Flatpak są tworzone i utrzymywane przez zewnętrzne projekty nadrzędne (upstream), a rolą deweloperów System76 jest w tym wypadku wyłącznie audyt uprawnień piaskownicy (sandboxing).

Przeciążenie opiekunów: dlaczego Jeremy Soller postawił tamę

Za zmianą stoi Jeremy Soller, Principal Engineer w System76 oraz główny architekt pulpitu COSMIC. W uzasadnieniu decyzji wskazał on na krytyczny problem, z jakim mierzą się obecnie zespoły maintainerów: syndrom przeciążenia opiekunów projektu (maintainer overload).

Upowszechnienie asystentów programowania i publicznych generatorów kodu doprowadziło do gwałtownego wzrostu liczby nadsyłanych zgłoszeń, szczególnie od osób debiutujących w repozytorium. Niestety, ułatwienie generowania tekstu doprowadziło do powstania drastycznej asymetrii nakładu pracy. Wyprodukowanie przez użytkownika pozornie działającej funkcji lub poprawki za pomocą zapytania do modelu zajmuje kilka sekund, podczas gdy doświadczony inżynier musi poświęcić kilkadziesiąt minut na drobiazgową analizę składni, weryfikację logiki, uruchomienie testów i wykrycie subtelnych halucynacji algorytmu.

Jak podkreślił Soller, zgłoszenia generowane maszynowo były w przeważającej mierze „nieplanowane i rzadko akceptowane” (unplanned and rarely accepted). Zamiast realnej pomocy deweloperzy otrzymywali dziesiątki powierzchownych propozycji, które angażowały cenny czas etatowych pracowników System76, odciągając ich od dopracowywania wydania Pop!_OS opartego na nowym stosie graficznym.

Kod generatywny a asysta techniczna: granica przyjęta przez System76

Regulacje wprowadzone w projektach Pop!_OS i COSMIC precyzyjnie definiują granicę dozwolonego zastosowania narzędzi cyfrowych. Zespół nie sprzeciwia się ogólnemu wykorzystaniu technologii obliczeniowych, lecz kategorycznie odrzuca wprowadzanie ich bezpośrednich wytworów do oficjalnej bazy kodu.

Autorzy zmian nadal mogą korzystać z narzędzi wspierających wyszukiwanie błędów, zaawansowanych linterów czy lokalnych analizatorów pomagających zrozumieć strukturę projektu. Warunkiem koniecznym pozostaje jednak pełna sprawczość i odpowiedzialność człowieka. Zgłaszający musi potwierdzić przestrzeganie standardu Developer Certificate of Origin (DCO), zaświadczając, że dokładnie rozumie każdą wprowadzoną instrukcję i osobiście zweryfikował jej działanie w działającym środowisku.

Szerszy opór w świecie open source: od Gentoo po cURL

Ruch twórców Pop!_OS nie jest odosobnionym incydentem, lecz częścią narastającej fali sprzeciwu w ekosystemie wolnego i otwartego oprogramowania wobec niekontrolowanego napływu treści maszynowych. Już w kwietniu 2024 roku Rada Gentoo (Gentoo Council) jednogłośnie uchwaliła całkowity zakaz wprowadzania kodu tworzonego przy użyciu narzędzi AI bazujących na przetwarzaniu języka naturalnego (NLP). Tamtejsza społeczność argumentowała swój krok obawami o „skażenie” bazy kodu materiałami o niejasnym statusie praw autorskich oraz ryzykiem wprowadzania trudnych do zdiagnozowania błędów w kluczowych pakietach dystrybucji.

Podobne zjawisko wyczerpania recenzentów (reviewer fatigue) regularnie opisuje Daniel Stenberg, autor biblioteki cURL, który zmaga się z falą bezwartościowych, wygenerowanych przez modele językowe raportów o rzekomych lukach bezpieczeństwa. Choć w projektach takich jak jądro Linuksa dopuszcza się formalnie kod powstający przy wsparciu dowolnych narzędzi, to i tam nadrzędną zasadą pozostaje rygor DCO: autor podpisujący się pod łatką bierze za nią pełną odpowiedzialność prawną i techniczną.

Bilans: ochrona ludzkich zasobów w erze generatorów

Decyzja firmy System76 unaocznia realny koszt rewolucji generatywnej w inżynierii oprogramowania. Zdolność modeli do taniego i masowego produkowania kodu nie idzie w parze ze zdolnością do jego syntezy w spójną architekturę systemu operacyjnego. Pop!_OS, budując od zera nowoczesne środowisko COSMIC w bezpiecznym pamięciowo języku Rust, potrzebuje kodu przemyślanego, przewidywalnego i napisanego przez ludzi rozumiejących specyfikę platformy.

Wprowadzony zakaz pokazuje, że w dobie powszechnej automatyzacji to czas i uwaga doświadczonych programistów stają się najcenniejszym oraz najbardziej deficytowym zasobem. Wprowadzenie obowiązku deklaracji w repozytoriach Pop!_OS może stać się drogowskazem dla kolejnych dystrybucji Linuksa, które nie zamierzają marnować sił swoich zespołów na weryfikację maszynowych halucynacji.