Polityka wnoszenia kodu pisanego z AI dla zespołów inżynierskich: kto podpisuje jego pochodzenie

Kto skorzysta z tego przewodnika.

• CTO i wiceprezesi ds. inżynierii, których zespoły już wdrażają kod pisany z AI i nie mają spisanej reguły, kto go podpisuje
• Opiekunowie projektów open source, którzy dostają pull requesty z kodem pisanym przez AI i szukają reguł do egzekwowania zamiast sporów
• Menedżerowie inżynierii, od których dział prawny albo bezpieczeństwa chce dokumentu opisującego, jak kod pisany z AI wchodzi do bazy kodu
• Zespoły zarządzania dostawcami, które odbierają dostawy 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. Pytanie pada z dwóch stron: opiekun chce wiedzieć, kto odpowiada za pull request na tysiące linii napisanych przez AI, a inżynier, który odziedziczył niemal w całości tak napisany projekt, chce wiedzieć, czyje nazwisko na nim widnieje. Badanie z września 2026 obejmujące 281 polityk AI w 2 000 najwyżej ocenianych repozytoriów na GitHubie i w grupie znanych projektów (Hora, Robbes i Zacchiroli) ustaliło, że 83,3% z nich dopuszcza AI we wkładzie w kod, a 48,8% wymaga ujawnienia. Działającą częścią polityki są jej warunki, a użyteczna polityka to lista warunków ze sposobem sprawdzenia każdego z nich.

• Kto podpisuje. Człowiek, który otwiera pull request, poświadcza pochodzenie na podstawie Developer Certificate of Origin albo firmowego odpowiednika i bierze z tym błąd, regresję i pytanie o licencję. Narzędzie nigdy nie podpisuje: polityka jądra Linuksa stwierdza, że agenci AI nie mogą dodawać tagów Signed-off-by, bo tylko człowiek może poświadczyć DCO.
• 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.
• Obowiązki autora, zanim poprosi o przegląd. Zrozumienie, którego umie bronić bez narzędzia, testy, które uruchomił, zmianę mieszczącą się w limicie wielkości.
• Co recenzent może zamknąć bez czytania. Spisane, żeby polityka chroniła kolejkę przeglądów, a zamknięcie było regułą, nie osobistą decyzją.

Gdzie zapisać deklarację: trailer, pole szablonu, 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%. Zespół, który chce zarówno przeglądu ze zrozumieniem, jak i audytu, potrzebuje dwóch z nich: pola szablonu i etykiety.

Dwie konwencje się zderzają i polityka musi wybrać jedną. Agent chmurowy Copilota w GitHubie podpisuje swoje commity jako Copilot, z człowiekiem, który uruchomił zadanie, jako współautorem. Kubernetes zakazuje wpisywania AI jako współautora, bo narzędzie nie może podpisać umowy licencyjnej kontrybutora (CLA). Włączył też kontrolę CLA dla współautorów, żeby takie pull requesty były oznaczane jako niegotowe do scalenia. Repozytorium firmowe spotyka to samo pytanie w chwili, gdy umowa z klientem wymaga zidentyfikowanego autora, a odpowiedź musi być skonfigurowana w narzędziach, nie tylko zapisana w polityce.

Co zdecydowały opublikowane projekty

Wiersze poniżej są odczytane z własnych dokumentów projektów, nie z komentarzy o nich. Rozciągają się od pełnego zakazu do ujawnienia na żądanie i każdy jest wewnętrznie spójny: reguła pasuje do kontroli, którą projekt jest w stanie uruchomić.

Zrozumienie, testy, wielkość: co recenzent może zamknąć bez czytania

Obowiązki autora decydują, czy czas przeglądu idzie na kod, czy na ustalanie, czym ten kod jest. Ghostty ujmuje to w jednym zdaniu: jeśli nie umiecie bez narzędzia wyjaśnić, co robią wasze zmiany i jak współdziałają z resztą systemu, nie wnoście wkładu. W firmie ta sama reguła ma praktyczną postać: pole szablonu prosi o powód zmiany słowami autora, a recenzent może zadać jedno pytanie, na które trzeba odpowiedzieć ze zrozumienia, z zamkniętym logiem sesji.

Wielkość jest drugim obowiązkiem i wymaga ustalonej liczby. Praktyki inżynierskie Google podają 100 linii jako zwykle rozsądne i 1 000 jako zwykle za dużo na jedną zmianę, resztę zostawiając osądowi recenzenta. Zmiany pisane przez AI łatwo przekraczają tę górną granicę, bo dodawanie jest dla narzędzia tanie. Polityka ustala twardy limit dla pull requestów pisanych z AI i drogę wyjątku: notatkę projektową i plan podziału.

Reguły zamykania bez czytania utrzymują ruch w kolejce bez zamieniania każdej decyzji w spór. curl podaje, że w 2025 roku poniżej 5% jego zgłoszeń bezpieczeństwa było zasadnych, zanim zakończył program bug bounty, a menedżer produktu GitHuba otworzył na przełomie stycznia i lutego 2026 publiczną dyskusję o pozwoleniu opiekunom na ograniczanie albo wyłączanie pull requestów. Zamknięcie na podstawie reguły jest lżejszą odpowiedzią na tę samą presję. Co recenzent może zamknąć bez otwierania diffu:

• Brak powiązanego zgłoszenia albo przyjętej propozycji, w przypadku wkładu z zewnątrz
• Wielkość ponad limit bez planu podziału
• Puste pole deklaracji albo pole bez wskazanego zakresu zmiany i tego, co zweryfikowano ręcznie
• Odpowiedzi na komentarze z przeglądu wklejone z wyniku narzędzia zamiast odpowiedzi autora
• Wymagane testy, które nie wykonały się w CI, choć szablon je wymienia

Szkielet polityki: reguła, kogo obowiązuje, jak jest sprawdzana

Tabela to rezultat w skrócie. Każdy wiersz to jedna reguła, grupa, której dotyczy, oraz sposób sprawdzenia. Reguła bez sposobu sprawdzenia nie wchodzi do dokumentu. Wartości limitów, nazwiska właścicieli, harmonogram przeglądu i procedura zatwierdzania wyjątków to pola do uzupełnienia w waszej wersji.

Jak polityka łączy się z rejestrem ryzyk i zasadami korzystania z AI

Polityka nie stoi sama. Jest jednym z artefaktów praktyki Zasady korzystania z AI w firmie, obok polityki użycia AI, listy dopuszczonych narzędzi i harmonogramu ewaluacji. Daje rejestrowi ryzyk konkretne wpisy: scalona niezweryfikowana zmiana napisana przez AI, wynik na niezgodnej licencji w bazie kodu, przepustowość przeglądu wyczerpana przez wolumen, atrybucja, której umowa nie akceptuje. Każdy wpis wskazuje kontrolę z szablonu jako swoje zabezpieczenie.

Przestrzeganie polityki sprawdza okresowy audyt próbki. Losuje pull requesty z etykietą i sprawdza trzy rzeczy: czy deklaracja zgadzała się z diffem, czy wyjaśnienie autora się broniło i czy nazwane testy były testami uruchomionymi. Losuje też próbkę zmian bez etykiety, żeby wykryć pominięte deklaracje, z użyciem dostępnych śladów narzędzi. Raportuje udział tych, które nie przeszły. To ta sama metoda próbkowania co w praktyce Audyt kodu pisanego przez AI, zastosowana do procesu zamiast do kodu.

Co może pójść nie tak i co z tym robimy.

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

   W kwietniu 2026 VS Code zmienił domyślną wartość git.addAICoAuthor tak, że commity dostawały trailer Co-authored-by: Copilot; defekt przypisywał Copilotowi także podpowiedzi spoza Copilota, a w wersji 1.119 domyślne ustawienie wróciło do wyłączonego (microsoft/vscode, zgłoszenie #314311). Przez dwa wydania o atrybucji w historii commitów decydowało ustawienie edytora, nie autor. Zespół, którego polityka zakazuje współautorów AI, jak w Kubernetes, albo którego umowa z klientem wymaga zidentyfikowanego autora, znajduje 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: ustawienia edytora, tożsamość commitów agenta, hook commit-msg odrzucający trailery spoza dozwolonej listy. Potem skanujemy historię pod kątem trailerów, które już weszły. Decyzję, co z nimi zrobić, zapisujemy.

   Co zostaje u was: schemat atrybucji w polityce, hook w repozytorium i lint w CI oraz raport ze skanu historii z listą dotkniętych commitów
2. 2
   Próg ujawnienia zapisany przymiotnikiem: istotne użycie

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

   Co z tym robimy

   Zastępujemy przymiotnik wyzwalaczami, które da się zaobserwować: deklaracja jest wymagana, gdy do zmiany wszedł fragment diffu przyjęty z narzędzia bez edycji albo gdy zmiana powstała w sesji agenta. W deklaracji autor podaje narzędzie z listy dopuszczonych, zakres i to, co zweryfikował ręcznie. Potem kalibrujemy próg na waszych niedawnych pull requestach i pokazujemy, jaki udział wymagałby deklaracji, żeby regułę poprawić przed ogłoszeniem, a nie po tym, jak zostanie zignorowana.

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

   Recenzent pyta, dlaczego funkcja się zmieniła. Wiedza autora o zmianie to streszczenie agenta, więc odpowiedź jest wklejona od agenta, pytanie uzupełniające dostaje kolejne streszczenie, a przegląd staje się rozmową recenzenta z narzędziem, w której osoba przekazuje wiadomości. Kubernetes napisał swoją regułę na ten przypadek: recenzenci rozmawiają z ludźmi, a na komentarze z przeglądu nie odpowiada narzędzie. Pull requesty na tysiące linii napisanych przez AI to skrajna postać: nikt nie mógłby odpowiedzieć.

   Co z tym robimy

   Umieszczamy pole wyjaśnienia w szablonie i prawo do jednego pytania w liście kontrolnej recenzenta, a pull requesty pisane z AI ograniczamy bramką wielkości, żeby na pytanie dało się odpowiedzieć. Gdy przegląd utyka na odpowiedzi wklejonej z narzędzia, lista kontrolna każe zamknąć, a polityka stoi za recenzentem.

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

   Polityka, która podnosi poprzeczkę autorom, nie zmienia niczego w liczbie nadchodzących pull requestów. curl podaje, że w 2025 roku poniżej 5% jego zgłoszeń bezpieczeństwa było zasadnych, po czym zakończył program bug bounty; GitHub otworzył dyskusję o pozwoleniu opiekunom na ograniczanie pull requestów. W firmie ta sama presja wygląda jak rosnące opóźnienie przeglądu, podczas gdy wszyscy trzymają się dokumentu, bo dokument nałożył wszystkie reguły na autora i żadnej na wejście.

   Co z tym robimy

   Przenosimy reguły 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 czas do pierwszego przeglądu i udział zamkniętych bez przeglądu, co miesiąc, żeby limit był strojony na liczbach, nie na frustracji.

   Co zostaje u was: kontrole wejściowe w CI i miesięczny raport z czasem do pierwszego przeglądu oraz udziałem zamkniętych na podstawie reguły
5. 5
   DCO podpisane dla wyniku, którego praw nikt nie sprawdził

   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 precyzuje, co to znaczy dla generowanego kodu: warunki narzędzia muszą przyznawać prawa do wyniku, a wynik nie może zawierać kodu osób trzecich na niezgodnej licencji. Podpisanie bez sprawdzenia jednego i drugiego zdarza się tam, gdzie lista narzędzi nigdy nie została spisana i nikt nie czytał warunków pod kątem tej klauzuli.

   Co z tym robimy

   Dodajemy do listy dopuszczonych narzędzi kolumnę praw do wyniku, z klauzulą i datą jej odczytania. Uruchamiamy skanowanie licencji na plikach zmienionych w oznaczonych pull requestach, żeby rozpoznane licencje i podobieństwa wymagające sprawdzenia wyszły na jaw przed wydaniem. Polityka wskazuje, kto jest informowany, gdy tak się stanie, tak jak wytyczne ASF wymagają tego od swoich kontrybutorów.

   Co zostaje u was: lista dopuszczonych narzędzi z kolumną praw do wyniku oraz skan licencji plików zmienionych w pull requestach z etykietą ai-assisted

Co zostaje u was.

• Polityka wnoszenia kodu pisanego z AI: jeden dokument w układzie reguła / kogo obowiązuje / jak jest sprawdzana, obejmujący pracowników, wykonawców 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, kontrole CI dla trailerów, wielkości, deklaracji i testów, bot etykiet
• Lista kontrolna recenzenta z regułami zamykania bez czytania
• Raport z kalibracji progu ujawnienia na waszych niedawnych pull requestach
• Wpisy w rejestrze ryzyk dla kodu pisanego z AI, każdy przypisany do kontroli z polityki
• Lista dopuszczonych 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

   Skanujemy historię commitów pod kątem trailerów AI i współautorów, mierzymy wielkość pull requestów i opóźnienie przeglądu oraz czytamy, co już mówią wasz przewodnik kontrybutora i umowy. Wynikiem jest tabela z liczbami i cytatami z dokumentów.

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

   Piszemy reguły ze sposobem sprawdzenia każdej z nich i kalibrujemy wyzwalacz ujawnienia na waszych niedawnych pull requestach; zespół bez takiej historii dostaje reguły ustalone na przykładowych zmianach, z przeglądem po pierwszym okresie stosowania. Potem przeglądamy projekt z inżynierią, działem prawnym oraz, gdy to ma znaczenie, z opiekunami.

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

   Konfigurujemy szablon, hook, kontrole CI i bota etykiet, uruchamiamy je w trybie samego raportowania przez jeden cykl, a potem przełączamy na blokowanie. Recenzenci dostają listę kontrolną na krótkim szkoleniu.

   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 reguły się sprawdziły.

   Tydzień 3, potem po pierwszym cyklu

Pozostałe strony z tej serii.

Usługi, które to wdrażają.

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)