Kod wspomagany przez AI w projektach open source

Co należy zrobić przed wysłaniem kodu wspomaganego przez AI do repozytorium upstream

Projekty open source publikują obecnie zasady dotyczące kodu wspomaganego przez AI, a wytyczne te nie są ze sobą spójne. Dlatego nawyk jest prosty: przed napisaniem poprawki należy odnaleźć odpowiednią politykę i rzetelnie poinformować o użyciu narzędzi przy wysyłaniu kodu. Jedna zasada dotyczy obu przypadków. Nigdy nie należy przesyłać linii kodu, której nie można wyjaśnić podczas przeglądu.

Poprawna poprawka zostanie odrzucona, jeśli projekt zakazuje kodu wygenerowanego lub jeśli ukryto jego pochodzenie. Koszt ponosi autor, a konsekwencje pozostają, ponieważ opiekun projektu, który odkryje zatajenie informacji, nie ma powodu, by ufać reszcie historii zmian danego programisty. Najpierw kilka wyjaśnień, ponieważ polityki posługują się tymi terminami. LLM (large language model) to model stojący za agentem programistycznym. PR (pull request) w serwisie GitHub to odpowiednik MR (merge request) w serwisie GitLab, a poniższe uwagi dotyczą obu tych rozwiązań. DCO (developer certificate of origin) to linia potwierdzenia (sign-off) na końcu komunikatu commitu, która okazuje się być sednem całego sporu.

Stan polityk open source dotyczących kodu generowanego przez AI

Projekty podzieliły się na cztery grupy. Każdy poniższy przykład jest opatrzony datą, ponieważ te dokumenty podlegają częstym zmianom.

Zakaz. Rada Gentoo przegłosowała 14 kwietnia 2024 roku, że „wyraźnie zabrania się wnoszenia do Gentoo jakichkolwiek treści stworzonych przy pomocy narzędzi sztucznej inteligencji przetwarzających język naturalny”. Wytyczne dotyczące commitów w NetBSD określają dane wyjściowe z LLM jako „kod skażony”, który „nie może zostać zatwierdzony bez uprzedniej pisemnej zgody rdzenia projektu”. Dokument dotyczący pochodzenia kodu w QEMU, według stanu na sierpień 2026 roku, nadal stanowi, że projekt będzie „ODRZUCAŁ wszelkie wkłady, co do których istnieje podejrzenie, że zawierają lub wywodzą się z treści wygenerowanych przez AI”.

Tylko analiza. Większość zakazów jest węższa, niż sugerują nagłówki. Dokument QEMU stwierdza, że polityka „nie ma zastosowania do innych sposobów wykorzystania AI, takich jak badanie API lub algorytmów, analiza statyczna czy debugowanie, pod warunkiem, że ich wyniki nie są włączane do wkładów”. Można używać agenta do czytania kodu. Nie można jednak wysyłać tego, co agent napisał. To rozróżnienie stanowi linię podziału w większości restrykcyjnych projektów i jest to kwestia, którą ludzie często pomijają.

Wymagane ujawnienie. Rada Fedora zatwierdziła politykę dotyczącą wkładów wspomaganych przez AI w październiku 2025 roku. Zezwala ona na używanie narzędzi, przenosząc odpowiedzialność na osobę: współtwórca jest autorem, ponosi pełną odpowiedzialność za cały wkład i musi ujawnić, kiedy znacząca jego część pochodzi z narzędzia bez wprowadzonych zmian. Jądro Linux wzbogaciło się o stronę dotyczącą asystentów kodowania w swojej dokumentacji procesowej w grudniu 2025 roku, zawierającą wzmiankę o rejestrowaniu narzędzia oraz sztywną zasadę dotyczącą tego, kto może podpisać się pod zmianami.

Brak pisemnych ustaleń. Jest to nadal najczęstszy przypadek. Preprint z maja 2026 roku, analizujący 1000 popularnych repozytoriów na GitHub, wykazał, że tylko 118 z nich posiada jakąkolwiek pisemną politykę dotyczącą AI. Brak dokumentacji nie oznacza przyzwolenia. Przed napisaniem poprawki należy zadać pytanie w systemie śledzenia zgłoszeń (issue tracker) w jednym zdaniu, a odpowiedź stanie się publicznym zapisem, na który można się później powołać.

Dlaczego opiekunowie projektu wprowadzili te zasady

Pierwszym powodem jest obciążenie procesem przeglądu, a arytmetyka jest tutaj nieubłagana. Agent generuje wiarygodny merge request o długości 400 linii w minutę. Rzetelne sprawdzenie takiego zgłoszenia zajmuje opiekunowi całe popołudnie, a większość opiekunów to wolontariusze. Koszt przesłania kodu spadł niemal do zera. Koszt jego weryfikacji nie zmienił się wcale.

Projekt curl pokazuje skrajny punkt tej krzywej. Daniel Stenberg poinformował w połowie 2026 roku, że około jedna piąta zgłoszeń dotyczących bezpieczeństwa, napływających w ramach programu bug bounty, to tak zwany AI slop: zgłoszenia, które wymieniają rzeczywiste funkcje i ścieżki kodu, opisują wiarygodny atak, ale nie zawierają żadnej wartości. Projekt zakończył program nagród na początku 2026 roku, zamiast finansować zalew takich zgłoszeń. Były to raporty, a nie poprawki, jednak mechanizm jest ten sam: sprawia on, że opiekun otwiera Twój PR, będąc już zmęczonym.

Projekt GNOME Calendar zdefiniował ten problem za pomocą etykiety. W czerwcu 2026 roku wprowadzono oznaczenie "Probabilistically Automated" dla merge requestów wykazujących "znaczną lub całkowitą zależność od sztucznej inteligencji przy generowaniu kodu". Nazwano tam symptom wprost: "zazwyczaj towarzyszy temu brak odpowiednich testów oraz finalizowanie poprawek w oparciu o teoretyczne założenia działania, a nie o poprawność kodu". Przeczytaj to ostatnie zdanie dwukrotnie. Kod wygląda tak, jakby powinien działać. Nikt jednak nie sprawdził, czy faktycznie działa.

Drugim powodem jest pochodzenie, czyli źródło kodu oraz licencja, na której jest udostępniany. Projekt QEMU jasno przedstawia ten konflikt: podpisanie zgłoszenia (sign-off) oznacza, że w pełni rozumiesz status praw autorskich i licencji treści, które wnosisz, a status prawny wyników generowanych przez modele jest nieuregulowany. Rada projektu Gentoo podała ten sam powód, obok kwestii jakości i etyki. Nie musisz zgadzać się z taką interpretacją prawną. Musisz jednak zauważyć, że to opiekun projektu podejmuje decyzję, a nie Ty.

Jak znaleźć politykę AI projektu?

Należy sprawdzić poniższe lokalizacje w podanej kolejności.

• CONTRIBUTING.md w katalogu głównym repozytorium, następnie .github/CONTRIBUTING.md, a potem każdy plik DCO znajdujący się obok.
• Dokumentacja programistyczna. QEMU przechowuje swoje zasady w docs/devel/code-provenance.rst. Jądro systemu przechowuje swoje w Documentation/process/coding-assistants.rst.
• Strona internetowa projektu lub wiki. Polityka Gentoo znajduje się na stronie wiki rady, a polityka NetBSD w wytycznych dotyczących commitów.
• System śledzenia zgłoszeń oraz archiwum listy mailingowej. Polityka zazwyczaj istnieje tam przez miesiące, zanim ktokolwiek zapisze ją w repozytorium.

Z poziomu kopii roboczej większość informacji można uzyskać za pomocą jednego polecenia grep:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Następnie należy przeanalizować historię projektu, ponieważ zatwierdzone konwencje są ważniejsze niż jakiekolwiek ich podsumowanie:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Liczba obok wartości znacznika wskazuje na formę faktycznie stosowaną w danym projekcie. Pusty wynik oznacza, że nikt nie dokonał ujawnienia w tej formie, co również stanowi istotną informację. Jeśli projekt znajduje się na GitHubie, a sam przepływ pracy jest nowy, sekcja jak działają pull requesty i forki na GitHubie wyjaśnia mechanikę, na której opiera się ten rozdział.

Ujawnienie w stopce commitu, nie w komentarzu

Stopka to wiersz Key: value w ostatnim akapicie wiadomości commitu. Git używa już tego formatu dla Signed-off-by: oraz Co-authored-by:, a narzędzia potrafią go parsować, dlatego jest to jedyna forma ujawnienia, która wędruje wraz z kodem do drzewa projektu.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

Jądro systemu dokumentuje ten format jako Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] i wyraźnie określa ograniczenie tego wiersza: „Agenci AI NIE MOGĄ dodawać tagów Signed-off-by. Jedynie ludzie mogą prawnie certyfikować Developer Certificate of Origin (DCO)”. Nazwa agenta trafia do Assisted-by. Twoje imię i nazwisko trafia do Signed-off-by. Nigdy nie pozwól narzędziu na wpisanie tego drugiego i nigdy nie pozwól mu wymyślić adresu Co-authored-by, który do nikogo nie należy.

Nazwy bywają różne, więc skopiuj lokalną zamiast wymyślać własną. Łatka wysłana na listę QEMU w maju 2026 roku zaproponowała złagodzenie zakazu tego projektu dla zmian mechanicznych, testów, dokumentacji oraz poprawek błędów o długości dwudziestu wierszy lub mniej, rejestrowanych za pomocą stopki takiej jak AI-used-for: tests, docs. Na sierpień 2026 roku jest to propozycja na liście mailingowej, a zatwierdzony dokument nadal odrzuca treści wygenerowane automatycznie. Jeden z projektów zmienił swoje stanowisko dwukrotnie między 2023 a 2026 rokiem. Kolejna zmiana nie będzie na Ciebie czekać, dlatego metoda jest ważniejsza niż lista.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer wymaga Git 2.32 lub nowszego. Drugie polecenie powinno zwrócić wartość bezpośrednio do Ciebie. Pusty wiersz oznacza, że git nie sparsował stopki, co prawie zawsze wynika z obecności pustego wiersza lub zwykłego zdania wewnątrz bloku stopki na dole wiadomości. Dla serii, którą już napisałeś, git rebase --signoff origin/main dodaje podpis do każdego commitu, a git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt edytuje plik wiadomości.

Warto zaplanować działania na wypadek dwóch trybów awarii. Squash merge nadpisuje wiadomość commitu, więc w projekcie, który stosuje squash, powtórz ujawnienie w opisie PR, gdzie przeczyta je opiekun projektu. Komentarz w recenzji nie jest rejestrem, ponieważ komentarze można edytować i nigdy nie trafiają one do historii git.

Dokładność działa w obie strony. Assisted-by w commicie napisanym ręcznie to szum, który obniża wartość Twoich rzeczywistych ujawnień. Pominięcie go w commicie napisanym przez agenta to czynność, która kończy współpracę.

Co faktycznie poświadcza Signed-off-by?

DCO to krótki tekst w wersji 1.1, opublikowany pod adresem developercertificate.org i stosowany w jądrze systemu, QEMU oraz wielu innych projektach. Dodanie Signed-off-by: Your Name <you@example.com> oznacza, że składasz stosowne oświadczenie. Należy zapoznać się z treścią tego, co się podpisuje, ponieważ większość osób składa podpis bez uprzedniego przeczytania dokumentu.

Punkt (a) stanowi, że wkład „został stworzony w całości lub w części przeze mnie i mam prawo przesłać go na licencji open source wskazanej w pliku”. Punkt (b) obejmuje pracę opartą na wcześniejszym kodzie open source, który masz prawo przekazać dalej wraz z modyfikacjami. Punkt (c) dotyczy kodu przekazanego przez osobę, która złożyła to samo oświadczenie. Punkt (d) informuje, że rozumiesz, iż wkład oraz dane osobowe zawarte w podpisie są publiczne i przechowywane bezterminowo.

Zwróć uwagę na to, czego brakuje w treści. DCO nigdy nie stwierdza, że samodzielnie wpisałeś każdy znak. Dokument mówi jedynie, że masz prawo przesłać kod na danej licencji. Dlatego wygenerowany kod stanowi tutaj problematyczną kwestię: nie chodzi o autorstwo, lecz o to, czy potrafisz wykazać pochodzenie kodu. Większość projektów wymagających podpisu wymaga również podania prawdziwego imienia i nazwiska, więc pseudonim nie przejdzie weryfikacji. Dodaj linię za pomocą git commit -s, co odczyta user.name oraz user.email z Twojej konfiguracji git. Gdy bot DCO odrzuci Twój PR i wskaże commit, w którym brakuje tej linii, użycie git rebase --signoff origin/main oraz wymuszenie wypchnięcia (force push) do Twojej gałęzi rozwiąże problem.

Podpisanie commita nie jest tym samym, co "sign-off"

git commit -s dodaje wiersz tekstu. git commit -S tworzy kryptograficzny podpis obiektu commit przy użyciu klucza GPG lub SSH. Odpowiadają one na różne pytania. Podpis zaświadcza, że commit pochodzi od posiadacza danego klucza i nie został zmieniony od momentu podpisania. Nie informuje on jednak o pochodzeniu zawartego w nim kodu, więc podpisany commit zawierający nieujawniony kod wygenerowany automatycznie jest poprawnie podpisany, ale nadal narusza zasady. Sign-off jest deklaracją dotyczącą pochodzenia. Podpis jest deklaracją dotyczącą tożsamości. Projekty wymagające obu tych elementów będą prosić o oba.

Nigdy nie zgłaszaj kodu, którego nie potrafisz wyjaśnić podczas przeglądu

To jest test i wcale nie chodzi w nim o uczciwość. Dla każdej linii kodu: po co ona jest i co przestanie działać bez niej? Jeśli brakuje którejkolwiek z tych odpowiedzi, poprawka nie jest gotowa, ponieważ komentarz recenzenta i tak się pojawi, a Twoja odpowiedź będzie wymagała kolejnej rundy generowania. Recenzenci potrafią to rozpoznać. To moment, w którym współtwórca staje się obciążeniem. Zadaj to samo pytanie o przypadki brzegowe, puste dane wejściowe, ścieżkę błędu oraz drugiego wywołującego.

Uruchom to. Zbuduj projekt, wykonaj zestaw testów i napisz reproduktor błędu, który rzekomo naprawiasz. Dokumentacja jądra podaje uczciwą alternatywę w prostych słowach: „Jeśli poprawka nie mogła zostać zbudowana lub przetestowana, albo jeśli nie udało się stworzyć reproduktora, powiedz to wprost: opiekunowie marnują obecnie zbyt wiele czasu na analizowanie niezweryfikowanych zgłoszeń i nietestowanych poprawek”. Napisanie „Nie mogłem przetestować tego na rzeczywistym sprzęcie” nic Cię nie kosztuje. Sugerowanie, że to zrobiłeś, kosztuje Cię udział w projekcie.

Odpowiadaj na komentarze z przeglądu samodzielnie, własnymi słowami i w swoim czasie. Odpowiedź, która pojawia się trzydzieści sekund po komentarzu i powtarza go w pięciu akapitach, mówi opiekunowi dokładnie, co się stało. Dbaj również o to, by diff był mały. Czterdzieści linii, które w pełni rozumiesz, jest dla projektu warte więcej niż czterystulinijkowy refaktoryzacja, którą nadzorowałeś. Jeśli Twój agent ciągle zwraca więcej, niż prosiłeś, umiejętność ograniczenia go do najmniejszej działającej zmiany jest jednym ze sposobów na utrzymanie poprawki w rozmiarze, który wciąż możesz obronić linijka po linijce.

Przechowywanie instrukcji dla agenta w repozytorium

Instrukcje przekazywane agentowi stanowią część łańcucha narzędzi, dlatego należy traktować je jak kod. Plik w głównym katalogu repozytorium, zazwyczaj AGENTS.md, zawiera polecenie budowania, polecenie testowania, format komunikatów commitów, wymóg podpisywania zmian oraz zasady stylu, które projekt już dokumentuje. Plik ten podlega wersjonowaniu i przeglądowi, dzięki czemu jest identyczny każdego dnia. Instrukcje wpisywane z pamięci podczas każdej sesji generują za każdym razem inny patch, co uniemożliwia ustalenie, która sesja wyprodukowała odrzuconą zmianę. Pisanie pliku AGENTS.md czytelnego zarówno dla agenta, jak i człowieka omawia strukturę tego pliku.

Należy zachować ostrożność w przypadku repozytoriów innych osób. Pierwszym wkładem w projekt, którego nie jesteś opiekunem, nie powinien być PR dodający plik z instrukcjami dla agenta. Jest to odbierane jako próba narzucenia polityki narzędziowej projektu z zewnątrz i stanowi szybki sposób na powiązanie własnego konta z działaniami, którymi opiekunowie są już zmęczeni. Przechowuj ten plik w swoim forku, dopóki ktoś o niego nie poprosi.

Miejsce uruchomienia agenta ma znaczenie z tego samego powodu. Agent, który potrafi zbudować projekt i uruchomić testy w kontrolowanym środowisku typu sandbox, dostarcza patch, który został faktycznie zweryfikowany. Jest to różnica między ujawnieniem wsparcia a ujawnieniem przypuszczenia. Uruchamianie agenta programistycznego na własnym VPS opisuje taką konfigurację, a praktyczne różnice między Claude Code, Cursor, Codex i Copilot wyjaśnia codzienne różnice w działaniu tych narzędzi.

Metoda postępowania po zmianie polityki

1. Przed przystąpieniem do pracy należy ustalić obowiązującą politykę: w repozytorium, dokumentacji dla programistów, witrynie internetowej lub systemie śledzenia błędów.
2. W przypadku braku polityki należy zadać pytanie w zgłoszeniu (issue) w jednym zdaniu i zachować odpowiedź.
3. Ujawnienie informacji powinno nastąpić w formie wymaganej przez projekt, w stopce commitu (commit trailer), z powtórzeniem w treści PR, jeśli projekt stosuje squashing.
4. Należy podpisać się własnym imieniem i nazwiskiem, mając świadomość, że linia ta stanowi oświadczenie o prawie do przesłania kodu.
5. Własną poprawkę należy przejrzeć tak, jakby napisał ją ktoś obcy, ponieważ w istocie tak jest.

Każdy projekt wymieniony na tej stronie zmieni swoje położenie do czasu, gdy użytkownik będzie czytał ten tekst. Pięć powyższych kroków pozostaje niezmiennych.

FAQ

Czy muszę ujawniać użycie agenta programistycznego AI?

Sprawdź zasady projektu, ponieważ odpowiedź jest ustalana lokalnie. Fedora wymaga ujawnienia informacji, gdy znacząca część wkładu pochodzi z narzędzia i nie została zmodyfikowana. Jądro Linux wymaga dodania znacznika Assisted-by. Gentoo oraz QEMU, według stanu na sierpień 2026, nie akceptują takiego wkładu w ogóle. Jeśli brak jest pisemnych wytycznych, ujawnij ten fakt w commit trailerze. Utrzymujący projekt, który dowie się o tym później, zareaguje na zatajenie informacji, a nie na samo narzędzie, a ta reakcja wpłynie na ocenę wszystkich Twoich przyszłych zgłoszeń.

Które projekty open source zakazują kodu wygenerowanego przez AI?

Stan na sierpień 2026: Gentoo od kwietnia 2024, NetBSD, który traktuje dane wyjściowe LLM jako kod skażony wymagający zatwierdzenia przez rdzeń projektu, QEMU, który odrzuca wkłady pochodzące z wygenerowanej treści, oraz kilka aplikacji GNOME, w tym Loupe i Calendar. Zapoznaj się z dokumentacją każdego projektu zamiast polegać na tej liście, ponieważ informacje te ulegają dezaktualizacji. Zwróć uwagę na wyjątek wspólny dla większości z nich: użycie modelu do badania API, uruchamiania analizy statycznej lub pomocy w debugowaniu jest zazwyczaj dozwolone, o ile wynik jego pracy nie znajduje się w patchu.

Jaka jest różnica między Signed-off-by a podpisanym commitem?

Signed-off-by to linia zwykłego tekstu dodawana przez git commit -s. Potwierdza ona Developer Certificate of Origin, co oznacza, że masz prawo przesłać ten kod na licencji projektu. Podpisany commit, wykonany za pomocą git commit -S, to kryptograficzny podpis obiektu commita przy użyciu Twojego klucza GPG lub SSH. Dowodzi on, że commit pochodzi z Twojego klucza i nie został zmieniony. Pochodzenie i tożsamość to odrębne deklaracje, więc podpisany commit nadal może naruszać politykę dotyczącą AI.

Czy mogę umieścić informację o ujawnieniu w opisie pull requesta zamiast w wiadomości commita?

Umieść ją w wiadomości commita, ponieważ jest to zapis, który trafia do historii git i towarzyszy kodowi każdemu, kto później sklonuje repozytorium. Opis pull requesta można edytować później i istnieje on tylko na platformie hostingowej. Dodaj tę informację również w treści PR, jeśli projekt stosuje squash merge, ponieważ squash nadpisuje wiadomość commita i może usunąć trailer.

Mój pull request został zamknięty, ponieważ został wygenerowany przez AI. Co teraz?

Nie dyskutuj o polityce w wątku, ponieważ osoba zamykająca zgłoszenie nie ustaliła tej zasady samodzielnie, a wątek nie jest miejscem na jej zmianę. Przeczytaj tekst polityki, a następnie zdecyduj, czy jesteś w stanie ją spełnić. Tam, gdzie projekt zakazuje wygenerowanych patchów, jasny raport o błędzie z reproduktorem i bez załączonego patcha jest nadal mile widziany i często stanowi bardziej użyteczny wkład. Jeśli wrócisz z kodem, przygotuj niewielką zmianę, którą będziesz w stanie obronić linijka po linijce.