Debian nie zagłosował ani za “AI bez ograniczeń”, ani za całkowitym zakazem. Zwycięska opcja General Resolution o “LLM usage in Debian” ustala praktyczną zasadę: narzędzia generatywne mogą pomagać, ale wkład musi spełniać zwykłe standardy projektu, a odpowiedzialność pozostaje po stronie człowieka.

Maintainer sprawdza wkład open source wspierany przez AI z testami, licencjami i odpowiedzialnością

To ważne nie tylko dla Linuksa. Debian jest infrastrukturą wolnego oprogramowania, więc jego decyzja przypomina szablon dla firm i maintainerów: AI może pomóc napisać kod, dokumentację albo łatkę, ale nie przejmuje jakości, licencji, bezpieczeństwa ani późniejszego utrzymania.

Co zdecydował Debian

Oficjalna strona głosowania podaje dyskusję od 23 lipca do 13 sierpnia 2026, głosowanie od 15 do 28 sierpnia UTC i wynik 29 sierpnia. Wygrał Choice 5: “Responsible Use of Generative AI”. Debian neither endorses nor prohibits generative AI w development, maintenance, documentation, packaging i innych mediach projektu. Klucz: pomoc AI nie zmniejsza odpowiedzialności autora; trzeba rozumieć, przejrzeć, przetestować i w razie potrzeby poprawić wynik.

Dlaczego to więcej niż Debian

Wiele zespołów nie pyta już, czy programiści mogą używać AI. Copilot, Cursor, Claude Code, Codex, ChatGPT i lokalne modele są w obiegu. Trudniejsze pytania brzmią: kto posiada diff, kto sprawdza licencję, kto widzi ryzyka bezpieczeństwa, kto utrzymuje zmianę za pół roku? Debian przesuwa spór do governance: narzędzie jest drugorzędne, wkład ma być wyjaśnialny i utrzymywalny.

Review staje się wąskim gardłem

LLM obniża koszt napisania patcha, issue albo dokumentacji, ale nie obniża tak samo kosztu review. Maintainer nadal czyta, testuje, sprawdza projekt, licencję i długoterminowe skutki. Jeśli autor wysyła generated work, którego nie rozumie, reviewer jest pierwszym realnym inżynierem w pętli. AI slop to więc przeniesienie kosztu na społeczność.

Prawo i bezpieczeństwo

Zwycięski tekst uznaje nierozwiązane pytania o copyright, autorstwo, licencje i możliwą reprodukcję materiału treningowego. Ostrzega też przed wysyłaniem do zewnętrznych usług AI prywatnej korespondencji, embargoed security bugs, kluczy kryptograficznych, credentials i informacji niepublicznych. Dla firm to gotowa reguła: sekrety, dane klientów i podatności nie trafiają do wygodnego zewnętrznego promptu.

Dla maintainerów

Praktyczna zasada: nie wysyłaj wkładu, którego nie potrafisz wyjaśnić. Maintainer może zamknąć PR nie dlatego, że jest “AI”, lecz dlatego, że autor nie odpowiada, nie daje testów, wysyła zbyt duży diff albo nie rozumie skutków. Disclosure ma pomagać w review: “AI pomogło w szkicu; przejrzałem diff i uruchomiłem testy” jest użyteczne.

Dla firm

Polityka wewnętrzna powinna mówić: jakie narzędzia są zatwierdzone do kodu, jakie klasy danych są zakazane, kiedy ujawniać znaczącą pomoc AI, kto sprawdza licencje, kiedy potrzebne są human approval, CI, security review i audit logs. Główna zasada: osoba wysyłająca pracę odpowiada za pracę. AI pomaga, ale nie przejmuje odpowiedzialności.

Wniosek

Decyzja Debiana nie jest zwycięstwem lekkomyślnego vibe coding. To dojrzała odmowa dwóch uproszczeń: że zakaz łatwo wyegzekwować i że generated output można przyjąć bez ludzkiego osądu. Dojrzałe wdrożenie AI mierzy się zdolnością bezpiecznego przyjęcia wyniku do realnych workflows.

Minimalna polityka na jedną stronę

Na początek wystarczy pięć zasad. Po pierwsze: autor PR rozumie zmianę i za nią odpowiada. Po drugie: dane wrażliwe nie trafiają do niezatwierdzonych modeli. Po trzecie: istotna pomoc AI jest ujawniana, gdy pomaga w review, provenance albo security assessment. Po czwarte: bulk submissions, mass bug filing i automatyczne refaktoryzacje wymagają wcześniejszej rozmowy. Po piąte: maintainer może wymagać krótkiego uzasadnienia, testów i odtwarzalności, a nie długiego generated rationale.

To nie rozwiązuje całej filozofii autorstwa, ale chroni realne wąskie gardła: czas review, niepewność prawną, sekrety i utrzymanie. Dlatego przypadek Debiana jest użyteczny dla AI Practice: zamienia “pozwolić czy zabronić” w zasady operacyjne.

Granica między pomocą a wyręczaniem

Najzdrowszy użytek z AI w projekcie open source przypomina pracę z narzędziem, nie z anonimowym współautorem. Model może zaproponować szkic testu, streścić długą dyskusję, znaleźć powtarzalny błąd w dokumentacji albo pomóc rozbić zmianę na mniejsze commity. Problem zaczyna się wtedy, gdy człowiek wysyła wynik bez zrozumienia, a maintainer ma odkrywać intencję, poprawność i ryzyko prawne od zera.

Dlatego disclosure nie powinno być celem samym w sobie. Użyteczna informacja dla review brzmi: które części powstały z pomocą modelu, co autor sprawdził samodzielnie, jakie testy uruchomił i gdzie zmienił sugestię narzędzia. Taka praktyka buduje zaufanie bardziej niż zakaz, którego nikt nie potrafi wiarygodnie egzekwować.