Polityka wkładu AI w kodzie: kto podpisuje się pod pochodzeniem kodu

Dla kogo jest ten przewodnik.

• CTO i szefowie inżynierii, których zespoły już wdrażają kod pisany z AI i nie mają spisanej zasady, kto się pod nim podpisuje
• Opiekunowie projektów open source, do których spływają generowane pull requesty i którzy chcą zasad do egzekwowania, a nie do dyskusji
• Kierownicy inżynierii, od których dział prawny albo security chce dokumentu opisującego, jak kod pisany z AI trafia do repozytorium
• Zespoły zarządzające dostawcami, które odbierają kod od wykonawców pracujących z agentami kodującymi

Cztery pytania, na które polityka musi odpowiedzieć

Spory o pochodzenie kodu w 2026 roku dotyczą odpowiedzialności, nie narzędzi. Wątki na szczycie r/programming i r/opensource zadają to samo pytanie z dwóch stron: opiekun projektu chce wiedzieć, kto odpowie za wygenerowany pull request na 13 tys. linii, a inżynier, który odziedziczył projekt niemal w całości wygenerowany, chce wiedzieć, czyje nazwisko na nim stoi. Badanie 281 polityk AI w 2000 najwyżej ocenianych repozytoriach GitHuba i w grupie znanych projektów (Hora, Robbes i Zacchiroli, wrzesień 2026) pokazało, że 83,3% dopuszcza AI we wkładzie do kodu, a 48,8% wymaga ujawnienia. Treścią polityki są więc warunki, a użyteczna polityka to lista warunków ze sprawdzeniem przy każdym z nich.

• Kto podpisuje. Człowiek, który otwiera pull request, poświadcza pochodzenie, według Developer Certificate of Origin albo firmowego odpowiednika, i bierze razem z tym błąd, regresję i pytanie o licencję. Narzędzie nie podpisuje nigdy: polityka jądra Linuksa mówi wprost, że agenci AI nie mogą dodawać tagu Signed-off-by, bo DCO może poświadczyć tylko człowiek.
• Co się deklaruje i gdzie. Jeden schemat na organizację: trailer w commicie, pole w szablonie pull requesta albo etykieta, wybrany świadomie, a nie odziedziczony po domyślnym ustawieniu narzędzia.
• Co autor jest winien, zanim poprosi o przegląd. Zrozumienie, którego obroni bez narzędzia, testy, które uruchomił, zmianę mieszczącą się w limicie wielkości.
• Co reviewer może zamknąć bez czytania. Spisane, żeby polityka chroniła kolejkę przeglądów i żeby zamknięcie było zasadą, a nie osobistą decyzją.

Gdzie idzie deklaracja: trailer, pole w szablonie, etykieta

Istnieją trzy mechanizmy i odpowiadają na różne pytania. W tym samym badaniu wśród polityk wymagających ujawnienia opis pull requesta jest miejscem wskazanym w 64,7% przypadków, a komunikat commita w 26,7%. Większość zespołów potrzebuje w praktyce dwóch z trzech.

Dwie konwencje się zderzają i polityka musi wybrać jedną. Agent Copilot w chmurze GitHuba podpisuje swoje commity jako Copilot, a człowieka, który uruchomił zadanie, wpisuje jako współautora. Kubernetes zabrania wpisywania AI jako współautora, bo narzędzie nie podpisze umowy licencyjnej kontrybutora, i włączył sprawdzenie CLA dla współautorów, więc taki pull request dostaje flagę, że nie jest gotowy do scalenia. Firmowe repozytorium spotyka to samo pytanie w chwili, gdy umowa z klientem wymaga zidentyfikowanego autora, a odpowiedź trzeba skonfigurować w narzędziach, nie tylko zapisać w polityce.

Co postanowiły projekty, które opublikowały politykę

Wiersze poniżej pochodzą z dokumentów samych projektów, nie z komentarzy o nich. Rozciągają się od pełnego zakazu po ujawnienie na życzenie i każdy jest wewnętrznie spójny: zasada odpowiada sprawdzeniu, które projekt jest w stanie wykonać.

Zrozumienie, testy, wielkość: co reviewer zamyka bez czytania

Obowiązki autora decydują o tym, czy czas przeglądu idzie na kod, czy na ustalanie, czym ten kod jest. Ghostty ujmuje to w jednym zdaniu: jeśli nie potraficie wyjaśnić bez narzędzia, co zmiana robi i jak współgra z resztą systemu, nie wysyłajcie jej. W firmie ta sama zasada ma praktyczną postać: pole w szablonie prosi o uzasadnienie słowami autora, a reviewer ma prawo zadać jedno pytanie, na które trzeba odpowiedzieć ze zrozumienia, przy zamkniętym logu sesji.

Wielkość to drugi obowiązek i potrzebuje liczby, nie nastroju. Praktyki inżynierskie Google podają 100 linii jako zwykle rozsądną wielkość jednej zmiany, a 1000 jako zwykle za dużą, resztę zostawiając ocenie reviewera. Zmiany generowane przekraczają tę górną granicę bez trudu, bo dokładanie nic narzędzia nie kosztuje. Polityka ustala twardy limit dla pull requestów z udziałem AI i ścieżkę wyjątku: notatkę projektową i plan podziału.

Zasady zamykania bez czytania utrzymują ruch w kolejce i nie zamieniają każdej decyzji w spór. curl podaje, że w 2025 roku poniżej 5% jego zgłoszeń bezpieczeństwa było prawdziwych, zanim zakończył program bug bounty, a menedżer produktu GitHuba otworzył na przełomie stycznia i lutego 2026 publiczną dyskusję o tym, by opiekunowie mogli ograniczać albo wyłączać pull requesty. Zamknięcie według zasady jest lżejszą odpowiedzią na tę samą presję. Co reviewer może zamknąć bez otwierania diffa:

• Brak powiązanego zgłoszenia albo przyjętej propozycji, przy wkładzie z zewnątrz
• Wielkość ponad limit bez planu podziału
• Puste pole deklaracji albo wypełnione tekstem, który reviewer rozpoznaje jako wygenerowany
• Odpowiedzi na uwagi wklejone z narzędzia zamiast odpowiedzi autora
• Testy, które według autora zostały uruchomione, a CI pokazuje, że nie

Szablon polityki: zasada, kogo dotyczy, jak jest sprawdzana

Tabela to skrócona postać dokumentu. Każdy wiersz to jedna zasada, grupa, której dotyczy, i sprawdzenie. Zasada bez sprawdzenia nie wchodzi do dokumentu.

Jak polityka łączy się z rejestrem ryzyka i podstawami nadzoru

Polityka nie stoi sama. Jest jednym z artefaktów podstaw nadzoru nad AI, obok polityki użycia AI, listy zatwierdzonych narzędzi i cyklu ewaluacji, i daje rejestrowi ryzyka konkretne wpisy: wygenerowana zmiana scalona bez sprawdzenia, wynik na niezgodnej licencji w bazie kodu, przepustowość przeglądu wyczerpana przez wolumen, atrybucja, której nie akceptuje umowa. Każdy wpis wskazuje sprawdzenie z szablonu jako swój mechanizm kontroli.

Weryfikacja to próbka, nie przekonanie. Okresowy audyt losuje pull requesty z etykietą, sprawdza, czy deklaracja zgadzała się z diffem, czy wyjaśnienie autora się obroniło i czy wymienione testy były tymi, które uruchomiono, i podaje udział tych, w których się nie zgadzało. To ta sama metoda próbkowania co w niezależnym audycie kodu tworzonego z AI, zastosowana do procesu zamiast do kodu.

Gdzie to się psuje i co z tym robimy.

1. 1
   Trailer dodany przez edytor i polityka, która go zabrania

   W kwietniu 2026 VS Code zmienił domyślną wartość ustawienia git.addAICoAuthor tak, że commity dostawały trailer Co-authored-by: Copilot; błąd przypisywał Copilotowi także podpowiedzi spoza Copilota, a w wersji 1.119 domyślna wartość wróciła do off (microsoft/vscode, zgłoszenie #314311). Przez dwa wydania o atrybucji w historii commitów decydowało ustawienie edytora, nie autor. Zespół, którego polityka zabrania współautora AI, jak w Kubernetes, albo którego umowa z klientem wymaga zidentyfikowanego autora, odkrywa to w historii po fakcie.

   Co z tym robimy

   Wybieramy z wami jeden schemat atrybucji, zapisujemy go w polityce i konfigurujemy tam, gdzie powstają commity: w ustawieniach edytora, w tożsamości commitów agenta, w hooku commit-msg, który odrzuca trailery spoza dozwolonej listy. Potem przeszukujemy historię pod kątem trailerów, które już weszły, i zapisujemy decyzję, co z nimi.

   Co zostaje u was: schemat atrybucji w polityce, hook w repozytorium i lint w CI oraz raport z przeszukania historii z listą dotkniętych commitów
2. 2
   Próg ujawnienia zapisany słowem istotny

   Polityki piszą, że ujawnić trzeba istotne albo znaczące użycie AI. Badanie 1000 najwyżej ocenianych repozytoriów (Hora i Robbes, lipiec 2026) wskazuje dokładnie te słowa jako powtarzającą się niejasność. Bez obserwowalnego wyzwalacza dzieją się dwie rzeczy naraz: ostrożni inżynierowie deklarują wszystko, więc etykieta nie niesie informacji, a reszta nie deklaruje nic, bo przyjęcie podpowiedzi nigdy nie wydawało się istotne.

   Co z tym robimy

   Zastępujemy przymiotnik wyzwalaczami, które da się zaobserwować: każdy fragment diffa przyjęty z narzędzia bez zmian, każda sesja agenta, każde narzędzie z listy. Potem kalibrujemy próg na waszych ostatnich pull requestach i pokazujemy, jaki udział wymagałby deklaracji, żeby zasadę poprawić przed ogłoszeniem, a nie po tym, jak zostanie zignorowana.

   Co zostaje u was: tabela decyzyjna dla deklaracji oraz raport kalibracji na waszych ostatnich pull requestach
3. 3
   Autor podpisuje, agent odpowiada na przegląd

   Reviewer pyta, dlaczego zmieniła się funkcja. Wiedza autora o zmianie to podsumowanie od agenta, więc odpowiedź jest wklejona od agenta, kolejne pytanie dostaje kolejne podsumowanie, a przegląd staje się rozmową reviewera z narzędziem, w której człowiek tylko przekazuje wiadomości. Kubernetes napisał swoją zasadę dokładnie na ten przypadek: reviewerzy rozmawiają z ludźmi, a na uwagi z przeglądu nie odpowiada narzędzie. Pull requesty na 13 tys. linii, o których opiekunowie dyskutowali na początku 2026 roku, to skrajna postać: nikt nie byłby w stanie odpowiedzieć.

   Co z tym robimy

   Wstawiamy pole wyjaśnienia do szablonu i prawo do jednego pytania na listę kontrolną reviewera, a pull requesty z udziałem AI przepuszczamy przez bramkę wielkości, żeby na pytanie dało się odpowiedzieć. Gdy przegląd stanie na odpowiedzi wklejonej z narzędzia, lista kontrolna mówi: zamknij, a polityka stoi za reviewerem.

   Co zostaje u was: szablon pull requesta z polem wyjaśnienia oraz lista kontrolna reviewera z zasadami zamykania
4. 4
   Polityka każe przeglądać wszystko, a wąskim gardłem jest kolejka

   Polityka, która podnosi poprzeczkę autorom, nie zmienia liczby przychodzących pull requestów. W curl udział prawdziwych zgłoszeń bezpieczeństwa spadł w 2025 roku poniżej 5% i projekt zakończył bug bounty; GitHub otworzył dyskusję o tym, by opiekunowie mogli ograniczać pull requesty. W firmie ta sama presja wygląda tak, że czas oczekiwania na przegląd rośnie, choć wszyscy trzymają się dokumentu, bo dokument nałożył wszystkie zasady na autora, a żadnej na wejście.

   Co z tym robimy

   Przenosimy zasady mechaniczne na wejście: powiązane zgłoszenie, wielkość, pole deklaracji, testy w CI, sprawdzane przez bota, zanim człowiek poświęci minutę. Potem mierzymy co miesiąc czas do pierwszego przeglądu i udział zamkniętych bez przeglądu, żeby limit stroić na liczbach, nie na frustracji.

   Co zostaje u was: sprawdzenia wejściowe w CI oraz miesięczny raport z czasem do pierwszego przeglądu i udziałem zamkniętych według zasady
5. 5
   DCO podpisane pod wynikiem, do którego nikt nie sprawdził praw

   Developer Certificate of Origin każe kontrybutorowi poświadczyć, że stworzył wkład albo ma prawo zgłosić go na danej licencji. Apache Software Foundation rozpisuje, co to znaczy dla kodu generowanego: warunki narzędzia muszą dawać prawa do wyniku, a wynik nie może zawierać cudzego kodu na niezgodnej licencji. Podpis bez sprawdzenia którejkolwiek z tych rzeczy jest częsty, bo lista narzędzi nigdy nie została spisana, a warunków nikt nie czytał pod kątem tej klauzuli.

   Co z tym robimy

   Dodajemy do listy zatwierdzonych narzędzi kolumnę z prawami do wyniku, z klauzulą i datą jej odczytania, i uruchamiamy skanowanie licencji na plikach z etykietą, żeby odtworzony cudzy kod wyszedł na jaw przed wydaniem. Polityka wskazuje, kto ma o tym wiedzieć, tak jak wytyczne ASF wymagają tego od swoich kontrybutorów.

   Co zostaje u was: lista zatwierdzonych narzędzi z kolumną praw do wyniku oraz skanowanie licencji wpięte pod etykietę ai-assisted

Co zostaje u was.

• Polityka wkładu AI: jeden dokument, zasada / kogo dotyczy / jak jest sprawdzana, dla pracowników, wykonawców zewnętrznych i kontrybutorów z zewnątrz
• Szablon pull requesta z polem deklaracji i polem wyjaśnienia oraz konwencja trailerów w commitach
• Konfiguracja repozytorium: hook commit-msg, sprawdzenia w CI dla trailerów, wielkości, deklaracji i testów, bot etykiet
• Lista kontrolna reviewera z zasadami zamykania bez czytania
• Raport kalibracji progu ujawnienia na waszych ostatnich pull requestach
• Wpisy do rejestru ryzyka dla wkładu z udziałem AI, każdy powiązany z mechanizmem kontroli z polityki
• Lista zatwierdzonych narzędzi rozszerzona o kolumnę praw do wyniku
• Jednostronicowe streszczenie dla menedżerów i do przewodnika kontrybutora

Jak pracujemy.

1. 1
   1. Odczyt stanu obecnego

   Przeszukujemy historię commitów pod kątem trailerów AI i współautorów, mierzymy wielkość pull requestów i czas oczekiwania na przegląd, czytamy, co już mówią wasz przewodnik kontrybutora i umowy. Wynikiem jest tabela faktów, nie opinia.

   Dni 1-3
2. 2
   2. Projekt polityki i kalibracja progu

   Piszemy zasady ze sprawdzeniem przy każdej i kalibrujemy wyzwalacz ujawnienia na waszych ostatnich pull requestach, a potem przechodzimy projekt z inżynierią, działem prawnym i, gdzie to ma sens, z opiekunami projektu.

   Tydzień 1-2
3. 3
   3. Narzędzia i wdrożenie

   Konfigurujemy szablon, hook, sprawdzenia w CI i bota etykiet, przez jeden cykl uruchamiamy je w trybie samego raportowania, potem przełączamy na blokowanie. Lista kontrolna reviewera wychodzi razem z krótką sesją dla reviewerów.

   Tydzień 2-3
4. 4
   4. Przekazanie i pierwszy audyt

   Przekazujemy politykę, konfigurację i wpisy do rejestru, a po pierwszym pełnym cyklu wracamy, losujemy próbkę oznaczonych pull requestów i raportujemy, jak zasady się trzymały.

   Tydzień 3, potem po pierwszym cyklu

Pozostałe strony z tej serii.

Gdzie to zamienia się w usługę.

Skąd pochodzą daty i liczby.

• Dokumentacja jądra Linuksa: AI Coding Assistants (tag Assisted-by, zasada Signed-off-by)
• Developer Certificate of Origin 1.1
• Hora, Robbes, Zacchiroli: "We Permit the Use of AI, but [...]": The Landscape of AI Policies in Popular Open Source Projects (arXiv 2609.07542, wrzesień 2026)
• Hora, Robbes: AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI? (arXiv 2605.16706, lipiec 2026)
• Blog kontrybutorów Kubernetes: Open source maintainership in the age of AI (26 czerwca 2026)
• Apache Software Foundation: Generative Tooling Guidance
• curl: Contributing, sekcja On AI use in curl
• Ghostty: AI Usage Policy
• Rada Gentoo: polityka AI (14 kwietnia 2024)
• Dokumentacja QEMU: Code provenance
• GitHub Docs: Responsible use of GitHub Copilot agents
• GitHub Blog: GitHub Copilot, meet the new coding agent
• microsoft/vscode, zgłoszenie #314311: update on Co-authored-by: Copilot in commit messages
• Google Engineering Practices: Small CLs
• Daniel Stenberg: The end of the curl bug-bounty (26 stycznia 2026)
• The Register: GitHub rozważa ograniczenie pull requestów przez opiekunów (3 lutego 2026)