Głosowanie Debiana o generatywnej AI łatwo odczytać jako proste pozwolenie. Projekt wybrał “Responsible Use of Generative AI”, a nie zakaz, ale praktyczny przekaz jest ostrzejszy: jeśli wysyłasz pracę do Debiana, nadal odpowiadasz za jej zrozumienie, testy, utrzymywalność, licencje, prywatne dane i za to, by nie przerzucać automatycznej pracy na maintainerów.

Biurko maintainera z węzłem AI, kolejką code review i checklistami governance

General Resolution o użyciu LLM w Debianie zakończyła się 28 sierpnia 2026. Oficjalna strona podaje osiem propozycji plus “None of the above”, dyskusję od 23 lipca do 13 sierpnia i głosowanie od 15 do 28 sierpnia. LWN i Phoronix podały, że wygrała opcja 5 Marca Habera. Dyskusje na Hacker News i LWN szybko przeszły do pytania ważnego dla wszystkich zespołów używających AI coding tools: skoro kod i tekst generuje się taniej, kto płaci za weryfikację?

Zwycięski tekst ani nie popiera, ani nie zakazuje generatywnej AI w rozwoju, utrzymaniu, dokumentacji, pakietowaniu i innych materiałach Debiana. Uznaje możliwy wzrost produktywności, ale utrzymuje te same standardy jakości, poprawności, utrzymywalności i zgodności prawnej. Ujawnianie pomocy AI jest zachęcane, nie wymagane. Ślepe wysyłanie wygenerowanych materiałów bez ludzkiego review jest niezgodne z praktykami projektu.

Odpowiedzialność, nie przepustka

Hasło “Debian pozwala na AI” gubi sens. Debian nie obniża poprzeczki, nie każe akceptować słabych patchy, nie rozwiązuje copyrightu decyzją i nie pozwala wklejać poufnych danych do usług zewnętrznych.

Zasada jest prosta: contributor odpowiada za zgłoszenie. Jeśli narzędzie pomogło napisać patch, człowiek musi go wyjaśnić. Jeśli model stworzył dokumentację, człowiek sprawdza fakty, komendy i nazwy pakietów. Jeśli agent przygotował masową zmianę, koszt review nadal ponosi projekt.

To model potrzebny firmom. “Model tak zrobił” nie jest obroną. “AI pomagała” nie dyskwalifikuje dobrej pracy. Liczą się dowody: mała zmiana, testy, wyjaśnienie, bezpieczeństwo, licencje i sens dla reviewera.

Zakaz kusi, ale pęka

Zakaz odpowiada na realne problemy: słabe patche, zmyślone uzasadnienia, niejasne pochodzenie, większe review i kulturę wysyłania kodu bez zrozumienia. Maintainerzy widzą już konta z wieloma PRs bez kontekstu.

Ale zakaz trudno egzekwować, gdy AI jest w edytorach, wyszukiwarce, tłumaczeniach, CLI i dokumentacji. Czy autocomplete się liczy? Lokalny model wyjaśniający kod? Test wygenerowany i poprawiony ręcznie? Granica jest rozmyta.

Zakaz może też karać odpowiedzialne użycia: szkice testów, porównanie API, streszczenie starych dyskusji, tłumaczenia, szukanie wzorców. Problemem nie jest pomoc, lecz praca bez review i właściciela.

Zgoda bez zasad też szkodzi

AI zmienia koszt zgłoszeń. Patch, komentarz lub raport powstaje szybciej; agent może zrobić ich wiele. Maintainer nadal czyta, rozumie, testuje, odrzuca lub łączy.

Jeśli autor nie rozumie zmiany, praca spada niżej. Debian utrzymuje więc standardy i ostrzega przed masowymi działaniami: mass bug filing, mass patch submission i duże zmiany kodu mają wymagać wcześniejszej dyskusji i zgody.

Dla firm zasada brzmi: narzędzie nie może zrzucać długu review na zespoły, które nie zaplanowały tej pracy.

Bezpieczeństwo i dane

Tekst wymienia informacje poufne, prywatną komunikację, dane wrażliwe dla bezpieczeństwa, błędy pod embargo, klucze kryptograficzne, credentials i inne materiały niepubliczne. Nie powinny trafiać do zewnętrznych usług AI bez autoryzacji.

Firmy potrzebują właśnie takich reguł klas danych. Lista narzędzi nie wystarczy. Kod publiczny, kod firmowy, logi klientów, security advisory, test z secretem i dokument NDA to różne rzeczy.

Dobra polityka mówi, jakie dane mogą wyjść, pod jaką umową, z jaką retencją, logami, zasadami treningu i kto zatwierdza wyjątki.

Ujawnienie i jakość

Debian zachęca do disclosure, ale go nie wymaga. Ujawnienie pomaga, gdy zmniejsza pracę reviewera: test matrix zasugerowany przez AI i sprawdzony ręcznie, albo refactor z listą komend, testów i kontroli człowieka. Szkodzi, gdy wywołuje spór, czy autocomplete to AI.

Firmy nie powinny mylić etykiety z jakością. Potrzebne są dowody review, testy, ryzyka, licencje i odpowiedzialna edycja człowieka. Disclosure to metadane, nie gwarancja.

Wąskie gardło to review

Najsilniejsza reakcja dotyczyła obciążenia review. W open source kod nie jest jedynym zasobem. Uwaga, kontekst, zaufanie, triage i release discipline są rzadsze.

AI może pomagać maintainerom, ale jeśli głównie zwiększa liczbę zgłoszeń bez kontekstu, przenosi koszt. Produktywność submittera staje się darmową pracą reviewera.

Odpowiedzialny workflow wymaga więcej dowodów: małe diffs, jasny problem, reprodukcja, testy, ryzyka i potwierdzenie, że wygenerowany wynik został zrozumiany.

Dla zespołów i deweloperów

Managerowie powinni opisywać odpowiedzialność, nie tylko narzędzia. Gdzie AI może pomagać: research, szkice testów, dokumentacja, skrypty wewnętrzne, kod produkcyjny? Kto posiada wynik? Jakie dowody przed repozytorium, ticketem lub wdrożeniem?

Trzeba rozdzielić pomoc człowiekowi od automatycznej akcji. Pytanie modelu o alternatywy to nie otwarcie pięćdziesięciu PRs. Szkic dokumentacji to nie raport wrażliwego incydentu. Zatwierdzony model lokalny to nie zewnętrzna usługa webowa.

Maintainerzy mogą wymagać zachowań: rozumieć kod, małe zmiany, testy, brak masowych zmian bez dyskusji, żadnych danych prywatnych w usługach zewnętrznych, żadnego pompowania issues wygenerowanym tekstem.

Deweloperzy powinni używać AI do zwiększania rozumienia: eksploracji kodu, testów, porównania API, edge cases, tłumaczeń, refaktoryzacji. Przed wysłaniem trzeba przeczytać diff, uruchomić testy, sprawdzić licencje i usunąć zmyślone twierdzenia.

Wniosek

Decyzja Debiana pokazuje dojrzałość AI-assisted development. Pytanie nie brzmi już, czy narzędzia AI istnieją w pracy programisty, lecz jak używać ich bez szkody dla jakości, prawa, bezpieczeństwa i nauki.

Open source powinien przyjmować pracę spełniającą standardy i chronić maintainerów przed automatyzacją bez właściciela. Firmy potrzebują zasad odpowiedzialności, danych i skali, nie tylko nazw narzędzi. Deweloperzy mają być dzięki AI skuteczniejsi, nie mniej odpowiedzialni.