Poparcie Linusa Torvaldsa dla kodowania z AI zderza się z problemem opiekunów Linuxa

Poparcie Linusa Torvaldsa dla kodowania z AI brzmi dziś wyjątkowo entuzjastycznie, mimo narastającego sporu dotyczącego wkładu generowanego maszynowo w oprogramowanie open source. Podczas wystąpienia 9 października twórca Linuxa powiedział, że teraz „naprawdę lubi używać AI”, choć wcześniej programowanie z AI nie robiło na nim wrażenia.

To poparcie nie oznaczało zgody na przesyłanie niesprawdzonego kodu. Torvalds nazwał AI użytecznym sposobem na czerpanie przyjemności z programowania, zwłaszcza dla początkujących i w projektach osobistych. Ostrzegł też deweloperów, by byli „bardzo ostrożni” przy wykorzystywaniu jej w poważnej pracy.

To rozróżnienie ma znaczenie, ponieważ jądro Linuxa zetknęło się już z obiema stronami rozwoju wspomaganego przez AI. Zautomatyzowane narzędzia potrafią wykrywać rzeczywiste błędy i pomagać deweloperom pracować poza językami, które znają najlepiej. Mogą też zasypywać opiekunów zduplikowanymi zgłoszeniami, powierzchownymi łatkami i pracą, którą ludzie muszą zweryfikować.

Linux stawia więc trudniejsze pytanie niż to, czy AI pisze akceptowalny kod. Wyzwanie polega na ustaleniu, kto ponosi koszt jego walidacji. Wyłaniająca się odpowiedź łączy swobodne korzystanie z narzędzi z ujawnianiem ich użycia, ludzką recenzją i osobistą odpowiedzialnością.

Komentarze Linusa Torvaldsa o kodowaniu z AI wyznaczają wyraźną granicę

Torvalds popiera AI jako narzędzie programistyczne, ale jego poparcie kończy się tam, gdzie zaczyna się niezweryfikowany wynik.

Torvalds rozmawiał o AI z Dirkiem Hohndełem podczas Open Source Summit Europe w Pradze. Linux Foundation zaplanowała tę sesję na 9 października w ramach programu z okazji 35. rocznicy projektu. Program konferencji umieścił ich rozmowę obok ścieżek poświęconych Linuxowi, otwartej AI, zaufaniu cyfrowemu i oprogramowaniu krytycznemu dla bezpieczeństwa.

Jego stanowisko odzwierciedlało zmianę osobistych doświadczeń. Torvalds powiedział, że kiedyś uważał, iż programowanie z AI „po prostu nie było zbyt dobre”. Od tamtej pory zaczął czerpać przyjemność z jej używania i uznaje ją za wartościowe narzędzie, jeśli jest właściwie wykorzystywana.

Ta zmiana nie uczyniła go zwolennikiem bezobsługowego generowania oprogramowania. Torvalds podkreślił, że jest przede wszystkim opiekunem jądra i punktem zbierającym wkład, a nie osobą piszącą większość jego kodu. Jego własne eksperymenty należą do innej kategorii ryzyka niż przyjmowanie zmian do infrastruktury używanej na całym świecie.

Opisał AI jako szczególnie przydatną przy zadaniach wykraczających poza jego ugruntowaną wiedzę. Jeden z przykładów dotyczył osobistego projektu efektu gitarowego. Torvalds potrafił zbudować firmware w C, ale interfejs wyglądał przestarzale. Następnie użył AI do stworzenia implementacji w Javie, języku, którego zwykle nie używa.

Rezultat nie został przedstawiony jako eksperckie programowanie w Javie. Pokazał mu, jak znana mu implementacja w C przekłada się na inny język, i zapewnił projektowi działający interfejs. Eksperyment ilustruje ograniczony przypadek użycia, w którym deweloper rozumie zamierzone działanie i może sprawdzić rezultat.

Torvalds powiązał też AI z doświadczeniem nauki programowania. Gdy zaczął kodować w 1981 roku, proste programy nadal mogły wydawać się znaczące, ponieważ komercyjne oprogramowanie było mniej dopracowane. Nowi deweloperzy porównują dziś swoje pierwsze projekty z dojrzałymi aplikacjami tworzonymi przez duże zespoły.

AI może obniżyć tę psychologiczną barierę. Może pomóc początkującym przekształcić niewielki pomysł w coś widocznego, zanim opanują każdy element. Torvalds określił ten proces jako sposób na odnalezienie radości w programowaniu, a nawet nazwał AI „narkotykiem wprowadzającym” do tej dziedziny.

Ostrzeżenie dotyczące poważnej pracy zmienia znaczenie tych uwag. Wygenerowany interfejs hobbystyczny, który działa źle, powoduje niedogodności. Wadliwa łatka do jądra może wprowadzić awarie, utratę danych, luki bezpieczeństwa lub trudne do wykrycia problemy z utrzymaniem.

Torvalds przypisał więc odpowiedzialność osobie obsługującej narzędzie. Deweloper musi rozumieć, co oprogramowanie powinno robić, i potwierdzić, że wygenerowana implementacja rzeczywiście to robi. Sama umiejętność tworzenia promptów nie zastępuje technicznego osądu.

To kluczowe ograniczenie w poparciu Linusa Torvaldsa dla kodowania z AI. AI może zmniejszyć wysiłek potrzebny do uzyskania początkowego rezultatu. Nie eliminuje pracy koniecznej do ustalenia, czy ten rezultat powinien trafić do krytycznej bazy kodu.

Jego stanowisko nie jest ani bezwarunkowym poparciem, ani ideologicznym odrzuceniem. Traktuje AI jak inne narzędzia programistyczne, uznając jednocześnie, że jej płynnie brzmiące wyniki mogą ukrywać błędy bardziej przekonująco niż tradycyjne narzędzia.

To praktyczne, wyważone podejście ściśle odpowiada rozwijającym się zasadom wkładu do jądra. Projekt akceptuje pomoc systemów zautomatyzowanych, ale nie pozwala agentowi AI przejmować prawnej ani technicznej odpowiedzialności współtwórcy.

Jądro Linuxa dopuszcza pomoc, a nie anonimową automatyzację

Zasady jądra skupiają się na odpowiedzialnych współtwórcach, ponieważ wygenerowany kod nie może sam poświadczyć swojego pochodzenia, licencji ani poprawności.

Jądro Linuxa publikuje obecnie dedykowane wytyczne dotyczące asystentów AI dla współtwórców. Kierują one pracę wspomaganą przez AI przez ten sam proces rozwoju, standardy kodowania, wymagania licencyjne i oczekiwania dotyczące recenzji, które obowiązują w przypadku łatek pisanych przez ludzi.

Ta ciągłość jest istotna. Linux od dawna akceptuje kod kształtowany przez kompilatory, analizatory statyczne, generatory kodu, systemy automatycznej refaktoryzacji i skrypty. Wkład nie staje się akceptowalny wyłącznie dlatego, że człowiek wpisał każdy znak.

I odwrotnie, wkład nie staje się niedopuszczalny wyłącznie dlatego, że narzędzie wygenerowało jego część. Recenzenci zwracają uwagę na zachowanie, łatwość utrzymania, licencjonowanie oraz na to, czy zgłaszający potrafi obronić zmianę.

Systemy generatywne komplikują ten utrwalony model, ponieważ mogą tworzyć kod, wyjaśnienia, komunikaty commitów i komentarze do recenzji za pomocą jednego interfejsu. Ich wyniki mogą sprawiać wrażenie kompletnych, nawet jeśli rozumowanie jest błędne lub ich pochodzenie pozostaje niepewne.

Wytyczne dla jądra odpowiadają na tę niepewność poprzez ludzką odpowiedzialność. Agenci AI nie mogą dodawać znacznika Signed-off-by. Ten znacznik należy do osoby, która może złożyć poświadczenie wymagane przez Developer Certificate of Origin, powszechnie nazywany DCO.

W ramach procesu DCO jądra podpisujący potwierdza, że wkład ma dopuszczalne pochodzenie i może być rozpowszechniany na licencji projektu. Model językowy nie może złożyć takiego oświadczenia prawnego.

Osoba przesyłająca pracę wspomaganą przez AI musi zrecenzować wygenerowany kod, zapewnić zgodność licencyjną, dodać własny podpis i przyjąć pełną odpowiedzialność. Oznacza to, że „model to napisał” nie może służyć jako obrona, gdy recenzenci znajdą problem.

Wytyczne wprowadzają też znacznik Assisted-by służący do ujawniania istotnego udziału LLM. Współtwórcy mogą wskazać wykorzystanie LLM oraz innych wyspecjalizowanych narzędzi analitycznych. Znacznik dostarcza opiekunom użytecznego kontekstu, nie udając, że narzędzie jest prawnym współtwórcą.

Oddzielne zasady dotyczące generowanych treści rozszerzają tę zasadę poza pliki źródłowe. Mogą obejmować komunikaty commitów, listy przewodnie, dokumentację i tłumaczenia, gdy wygenerowana treść w istotny sposób trafia do zgłoszenia.

Zasady te zachęcają współtwórców do wyjaśniania, jakich narzędzi użyli oraz, gdy jest to przydatne, jakie dane wejściowe wygenerowały pracę. Celem nie jest wymaganie zapisu każdej sugestii autouzupełniania. Chodzi o ujawnienie istotnej automatyzacji, która może wpływać na recenzję, pochodzenie lub odpowiedzialność.

Przejrzystość staje się ważniejsza, gdy pomoc AI jest mniej widoczna. Wygenerowana łatka może zostać przepisana ręcznie. Łatka napisana przez człowieka może otrzymać opis wygenerowany przez AI. Model może wykryć błąd, podczas gdy końcową poprawkę przygotuje opiekun.

Podejście jądra uwzględnia takie mieszane przepływy pracy. Unika nierealistycznego zadania klasyfikowania każdego znaku jako stworzonego przez człowieka lub maszynę. Zamiast tego pyta, czy narzędzie wniosło istotny wkład oraz czy człowiek jest gotów ręczyć za końcowe zgłoszenie.

Model ten stanowi użyteczny precedens dla firm i innych projektów open source. Zespoły nie muszą wybierać między zakazem każdego narzędzia AI a akceptowaniem nieprzejrzystych wyników agentów. Mogą zdefiniować progi ujawniania użycia, zachować ludzkie podpisy i wymagać standardowych dowodów testowania.

Jednak zasady dotyczące przypisania autorstwa rozwiązują tylko część problemu. Określają odpowiedzialność po utworzeniu zgłoszenia. Nie zapobiegają zwiększaniu przez AI liczby raportów i łatek, które opiekunowie muszą sprawdzić.

Problem skali to obszar, w którym liberalne stanowisko Linuxa przechodzi najtrudniejszy test.

AI sprawia, że wkład jest tani, podczas gdy recenzja pozostaje kosztowna

Konflikt nie dotyczy kodu ludzkiego przeciwko kodowi maszynowemu. Dotyczy obfitości wygenerowanych wyników wobec ograniczonej uwagi opiekunów.

Torvalds przyznał, że analiza wspomagana przez AI wykrywa wartościowe problemy w jądrze. Opisał też strumień przypadkowych łatek obejmujących wszystko — od istotnych luk bezpieczeństwa po sterowniki, których nikt nie dotykał od 20 lat.

Zautomatyzowany system nie rozumie naturalnie, który defekt zasługuje na ograniczoną uwagę człowieka. Jeśli otrzyma polecenie wyszukiwania wycieków pamięci, może tworzyć raporty wszędzie tam, gdzie analiza wykryje podejrzany wzorzec. Nie obchodzi go, czy dotknięty komponent jest szeroko wdrożony, przestarzały czy już naprawiany.

Ten brak priorytetyzacji przenosi pracę na opiekunów. Ktoś musi ustalić, czy zgłoszenie jest prawidłowe, określić, czy nie powiela wcześniejszej pracy, znaleźć właściwego właściciela podsystemu, sprawdzić proponowaną poprawkę i ocenić szersze konsekwencje.

Wiarygodny, lecz fałszywy raport może pochłonąć więcej czasu niż raport oczywiście słaby. Opiekunowie muszą zbadać wystarczający kontekst, by go obalić. Osoba, która wygenerowała raport, mogła poświęcić zaledwie kilka minut na promptowanie modelu.

Torvalds już wcześniej ostrzegał, że napływ raportów AI utrudnia zarządzanie listą bezpieczeństwa jądra. Zduplikowane odkrycia pogłębiały obciążenie, ponieważ różni użytkownicy mogli uruchamiać podobne narzędzia na tym samym kodzie i niezależnie zgłaszać ten sam problem.

Podczas wydarzenia w Pradze powiedział, że AI ogólnie poprawia bazę kodu. Tej pozytywnej ocenie towarzyszyło równie bezpośrednie ostrzeżenie: obciąża ona opiekunów „do tego stopnia, że staje się problemem”.

Skala obaw była widoczna podczas powiązanego spotkania opiekunów. Według Torvaldsa około trzy czwarte dyskusji dotyczyło tego, jak sprawić, by narzędzia AI do generowania i recenzowania kodu były mniej obciążające i bardziej użyteczne.

Ten szczegół przenosi debatę poza sferę osobistych preferencji. Opiekunowie nie spierają się po prostu o to, czy wygenerowany kod wydaje się autentyczny. Przeprojektowują przepływy pracy wokół zmiany produkcyjnej, która już nadeszła.

AI jednocześnie obniża kilka barier. Pozwala mniej doświadczonym deweloperom tworzyć szkice łatek, pomaga badaczom analizować nieznane podsystemy i przekształca podejrzewany problem w dopracowany raport. Te możliwości mogą poszerzać grono współtwórców i ujawniać błędy, które w przeciwnym razie pozostałyby niezauważone.

Jednak ta sama wygoda zachęca do jednorazowego udziału. Osoba może przesłać raport bez zrozumienia otaczającego go kodu, a następnie zniknąć, gdy opiekun poprosi o kroki reprodukcji, testy lub pełniejszą poprawkę.

Tradycyjne bariery związane z wkładem w projekt kiedyś ograniczały część takich zachowań. Przygotowanie poprawki, napisanie spójnego wyjaśnienia i odpowiadanie na uwagi z przeglądu wymagały wysiłku wystarczającego, by sygnalizować zaangażowanie. Narzędzia generatywne mogą naśladować te oznaki, zanim użytkownik zdobędzie odpowiadającą im wiedzę.

Ujawnienie użycia narzędzi nie może w pełni przywrócić utraconego sygnału. Tag Assisted-by informuje recenzenta, że automatyzacja uczestniczyła w pracy. Nie ujawnia jednak, czy zgłaszający rozumie dany podsystem ani czy pozostanie zaangażowany po pierwszej odpowiedzi.

Kernel potrzebuje więc filtrów operacyjnych obok przypisania autorstwa. Maintainerzy potrzebują sposobów grupowania zduplikowanych zgłoszeń, oceniania praktycznego wpływu, automatycznej weryfikacji twierdzeń oraz identyfikowania współtwórców, którzy wielokrotnie dostarczają użyteczną pracę.

Potrzebują też możliwości szybkiego odrzucania materiałów o niskiej wartości. Traktowanie każdego płynnie napisanego raportu AI jako pełnoprawnego wkładu zamieniłoby wygenerowaną masę treści w obowiązek dla nieopłacanych lub przeciążonych recenzentów.

Problem ten jeszcze dotkliwiej dotyczy mniejszych projektów. Linux ma dużą sieć współtwórców oraz maintainerów zatrudnionych przez duże firmy technologiczne. Biblioteka prowadzona przez jednego lub dwóch wolontariuszy ma znacznie mniejszą zdolność do obsługi automatycznych zgłoszeń.

Ta nierównowaga wyjaśnia, dlaczego projekty open source przyjęły różne zasady dotyczące LLM. Zakaz może być decyzją o zarządzaniu zasobami, a nie twierdzeniem, że cały wygenerowany kod jest wadliwy. Liberalna polityka może działać, gdy projekt dysponuje infrastrukturą testową i wystarczającą liczbą recenzentów, aby egzekwować swoje standardy.

Linux zajmuje wyjątkową pozycję. Może korzystać z analizy AI w ogromnej bazie kodu, ale każda zaakceptowana zmiana wpływa na krytyczną infrastrukturę. Jego skala tworzy zarówno najsilniejszy powód do korzystania z automatyzacji, jak i najsilniejszy powód, by ją ograniczać.

Prawdziwy kompromis dotyczy dostępu i odpowiedzialności

AI może zaprosić więcej osób do programowania, lecz odpowiedzialny wkład nadal wymaga wiedzy, wytrwałości i poczucia odpowiedzialności.

Najbardziej atrakcyjna część argumentu Torvaldsa dotyczy dostępu. Programowanie staje się łatwiejsze do odkrywania, gdy początkujący może opisać pomysł, otrzymać działający szkic i zmieniać go poprzez rozmowę.

Taka pętla informacji zwrotnej może utrzymać zaangażowanie osoby uczącej się. Zamiast spędzać pierwszą sesję na rozwiązywaniu problemów z instalacją lub zapamiętywaniu składni, może ona zobaczyć rezultat i stopniowo badać, jak działa.

Dla doświadczonych programistów te same narzędzia mogą wypełniać mniejsze luki wiedzy. Programista kernela może potrzebować interfejsu użytkownika, frameworka testowego albo skryptu w nieznanym języku. AI może dostarczyć punkt wyjścia bez konieczności poświęcania tygodni na niezwiązaną specjalizację.

To rzeczywisty wzrost produktywności. Różni się jednak od przekazania modelowi całej zmiany wrażliwej z punktu widzenia bezpieczeństwa. Programista w pierwszym scenariuszu rozumie już docelowy system i potrafi ograniczyć nieznany komponent.

Różnica zaciera się, gdy użytkownicy nie potrafią ocenić wyniku. Początkujący może uznać, że program działa, ponieważ przechodzi jeden widoczny test. Doświadczony inżynier może przeoczyć błąd spoza swojej specjalizacji, ponieważ wygenerowane wyjaśnienie brzmi wiarygodnie.

Dlatego określenie „human in the loop” może stać się pustym zapewnieniem. Osoba zatwierdzająca wynik nie gwarantuje rzeczywistego nadzoru. Recenzent musi dysponować wystarczającym kontekstem, czasem i uprawnieniami, aby wykryć błąd.

Zasada kernela dotycząca ludzkiego podpisu określa, kto ponosi odpowiedzialność, ale nie może stworzyć kompetencji. Zgłaszający może podpisać poprawkę, której naprawdę nie rozumie. Maintainerzy nadal potrzebują dowodów technicznych i aktywnego udziału w dyskusji.

Wygenerowany kod rodzi też nierozstrzygnięte pytania o pochodzenie. Modele mogą odtwarzać znane wzorce, nie zapewniając jasnej historii dla konkretnego wyniku. Współtwórcy muszą upewnić się, że zgłaszana praca spełnia wymagania licencyjne kernela GPL-2.0-only, nawet gdy model nie potrafi wyjaśnić każdego wpływu danych treningowych.

Polityka Linuxa nie twierdzi, że rozstrzyga szersze spory dotyczące danych treningowych lub praw autorskich. Wyznacza granicę wkładu: ludzki zgłaszający musi być w stanie złożyć istniejące poświadczenie prawne.

Bezpieczeństwo wprowadza kolejną niepewność. Systemy AI mogą wykrywać błędy w zapomnianych ścieżkach kodu, co przynosi projektowi korzyści. Mogą też stworzyć wydajny mechanizm produkowania powierzchownych zgłoszeń podatności na skalę przytłaczającą prywatne kanały raportowania.

Publiczne zgłaszanie stwarza inne zagrożenia. Natychmiastowe ujawnienie może narazić użytkowników, zanim maintainerzy zdążą przygotować i rozpowszechnić poprawkę. Prywatne raportowanie chroni koordynację, ale staje się nieskuteczne, jeśli kanały wypełniają się zduplikowanymi lub sfabrykowanymi zgłoszeniami.

Komentarze Torvaldsa sugerują, że Linux nie rozwiąże tego napięcia poprzez całkowite odrzucenie AI. Wcześniej w 2026 roku argumentował, że Linux nie jest projektem anty-AI i że narzędzia powinny pomagać maintainerom, a nie sprawiać im problemów.

Ten standard wywiera presję na twórców narzędzi. Sukcesu nie można mierzyć wyłącznie liczbą wykrytych defektów, przygotowanych poprawek czy wygenerowanych komentarzy do przeglądu. Użyteczny system musi zmniejszać całkowity ludzki wysiłek potrzebny do podjęcia prawidłowej decyzji.

W przypadku agenta wykrywającego błędy oznacza to reprodukcje, ocenę wpływu, wykrywanie duplikatów i dowody powiązane z konkretnymi ścieżkami kodu. W przypadku generatora poprawek oznacza to ukierunkowane zmiany, testy i wyjaśnienia, które wytrzymają ekspercki przegląd.

Dla agentów recenzujących użyteczność oznacza wskazywanie istotnych defektów bez zasypywania maintainerów spekulacyjnymi ostrzeżeniami. Precyzja i priorytetyzacja są ważniejsze niż duża liczba komentarzy.

Ta sama lekcja dotyczy firm wdrażających systemy AI do programowania. Mierzenie liczby wygenerowanych linii lub zaakceptowanych sugestii może nagradzać wolumen, nie ujawniając kosztu utrzymania. Zespoły muszą śledzić czas przeglądu, regresje, konieczne poprawki, liczbę incydentów i długoterminową odpowiedzialność.

Osobisty entuzjazm Torvaldsa nie unieważnia tych obaw. Uwypukla je. Jeśli programista rozumiejący ryzyka kernela nadal uważa AI za przyjemne i użyteczne, całkowite odrzucenie pozostawia istotne korzyści niewykorzystane.

Gdyby Linux przyjmował cały wygenerowany materiał bez dodatkowych kontroli, przenosiłby ukryte koszty tej technologii na maintainerów. Obecny kierunek projektu próbuje zachować przestrzeń do eksperymentowania, jednocześnie odmawiając takiego przeniesienia kosztów.

Co społeczność Linuxa musi udowodnić dalej

Polityka AI Linuxa odniesie sukces tylko wtedy, gdy wygenerowane wkłady staną się łatwiejsze do zweryfikowania, ustalenia priorytetów i utrzymania niż dzisiejsza fala napływających zgłoszeń.

Pierwszym sygnałem, na który warto zwrócić uwagę, będzie sposób stosowania przez kernel zasad ujawniania w zwykłym procesie recenzji. Formalna dokumentacja ma znaczenie, lecz o tym, czy współtwórcy rozumieją, kiedy używać Assisted-by i jakich informacji oczekują recenzenci, zdecyduje konsekwentna praktyka.

Zbyt szerokie ujawnianie może tworzyć powtarzalne metadane o niewielkiej wartości. Słabe ujawnianie może ukrywać istotną automatyzację i pozbawiać recenzentów kontekstu. Użyteczna równowaga wyłoni się dzięki rzeczywistym zgłoszeniom, opiniom maintainerów i aktualizacjom wytycznych.

Drugim sygnałem będzie to, czy automatyzacja przeglądu zmniejsza obciążenie powodowane przez generowanie. Torvalds zauważył, że projekty już wykorzystują AI do recenzowania poprawek wspieranych przez AI, co czasem sprawia wrażenie botów rozmawiających z botami.

Ten cykl nie jest automatycznie absurdalny. Analiza statyczna już sprawdza kod generowany przez maszyny i pisany przez ludzi. Recenzent AI może pełnić podobną rolę, jeśli jego ustalenia są precyzyjne, odtwarzalne i podporządkowane maintainerom ponoszącym odpowiedzialność.

Niebezpieczeństwo pojawia się, gdy jeden niepewny system potwierdza drugi, a ludzie traktują tę zgodność jako dowód. Wiele modeli może powielać to samo błędne założenie. Potoki recenzji muszą opierać się na testach, wynikach budowania, zachowaniu w czasie działania i możliwej do prześledzenia analizie kodu, a nie na konsensusie modeli.

Warto obserwować narzędzia, które dołączają konkretną weryfikację do każdego ustalenia. Raport zawierający reproduktor, dotkniętą konfigurację, wynik testu i minimalną poprawkę jest wartościowszy niż pewny siebie akapit opisujący możliwy defekt.

Trzecim sygnałem jest obciążenie maintainerów. Jeśli liczba zduplikowanych raportów bezpieczeństwa spadnie, poprawki o niskiej wartości będą szybciej triagowane, a użyteczni współtwórcy pozostaną zaangażowani w proces recenzji, model kontrolowanej akceptacji Linuxa będzie wyglądał na trwały.

Jeśli kolejki nadal będą rosnąć, a doświadczeni maintainerzy będą się wypalać, projekty będą miały silniejsze powody, by wprowadzać ostrzejsze ograniczenia. Istotnym rezultatem nie jest to, ile kodu wygenerowanego przez AI trafia do drzewa. Chodzi o to, czy społeczność może zachować jakość przeglądu bez wyczerpywania osób za niego odpowiedzialnych.

Dostawcy narzędzi powinni traktować ten rezultat jako wymaganie produktowe. Agent, który przygotowuje dziesięć poprawek, tworząc przy tym dwadzieścia godzin pracy recenzenckiej, nie dostarczył dziesięciu jednostek produktywności.

Programiści powinni również odróżniać eksperymentowanie od wnoszenia wkładu. Vibe coding, czyli iteracyjne programowanie poprzez prompty w języku naturalnym, może dobrze sprawdzać się w przypadku jednorazowego prototypu. Wprowadzenie kodu upstream wymaga zrozumienia jego zachowania, historii, testów i konsekwencji dla utrzymania.

To przejście jest miejscem, w którym wsparcie Linusa Torvaldsa dla programowania z AI staje się najbardziej użyteczne jako wskazówka. Zacznij od ograniczonego zadania. Korzystaj z AI tam, gdzie pomaga. Sprawdź, co tworzy. Przetestuj wynik, wyjaśnij go własnymi słowami i weź odpowiedzialność, zanim poprosisz inną osobę o jego recenzję.

Początkujący nie powinni interpretować tej ostrożności jako powodu, by unikać AI. Metafora Torvaldsa o „bramie do uzależnienia” uznaje, że dostępne narzędzia mogą stworzyć motywację potrzebną do nauki. Następnym krokiem jest przekształcenie wygenerowanego sukcesu w prawdziwe zrozumienie.

Doświadczeni inżynierowie nie powinni traktować swojej wiedzy jako odporności na błędy. Płynność może sprzyjać nadmiernej pewności siebie, zwłaszcza gdy model tworzy wiarygodnie wyglądający kod w nieznanej dziedzinie. Poważne systemy wymagają niezależnej weryfikacji, nawet gdy pierwszy wynik wygląda na dopracowany.

Maintainerzy z kolei potrzebują uprawnień do określania, jakie wsparcie rzeczywiście pomaga ich projektowi. Linux może wspierać AI bez wymagania od każdego właściciela podsystemu akceptowania nieograniczonej pracy generowanej przez maszyny.

Wyłaniający się model kernela jest wymagający, ale spójny. Narzędzia mogą uczestniczyć. Ludzie muszą ujawniać istotne wsparcie, spełniać zasady licencjonowania, rozumieć swoje zgłoszenia i pozostawać odpowiedzialni za konsekwencje.

Takie podejście nie zakończy sporu open source o treści generowane przez LLM. Różne projekty mają różne ryzyka i różną przepustowość recenzentów. Przenosi jednak debatę od tożsamości ku działaniu.

Najbliższe miesiące powinny pokazać, czy Linux potrafi przekształcić tę zasadę w możliwy do zarządzania proces pracy. Programiści mogą już teraz pomóc odpowiedzieć na to pytanie: przed zgłoszeniem pracy wspieranej przez AI sprawdź, czy oszczędza ona czas maintainerom, zamiast jedynie oszczędzać czas osobie, która ją wygenerowała.