Ta strona używa plików cookies, aby zapewnić najlepszą jakość korzystania z naszego serwisu oraz do celów analitycznych. Klikając "Akceptuję", wyrażasz zgodę na używanie wszystkich plików cookies. Możesz również odrzucić zgodę, co spowoduje zablokowanie plików cookies analitycznych. Więcej informacji znajdziesz w naszej Polityce Prywatności.
Linus Torvalds używa AI tam, gdzie sam nie czuje się mocny. W jądrze Linuksa widzi też ryzyko
Linus Torvalds używa AI głównie do zadań, w których sam ma mniejsze doświadczenie, na przykład projektowania interfejsu.
Vibe coding uważa za dobry sposób na zwiększenie radości z programowania, ale nie za zamiennik odpowiedzialnej pracy nad jądrem Linuksa.
AI pomaga znajdować błędy i problemy bezpieczeństwa, lecz może też generować zgłoszenia oraz patche wymagające długiej weryfikacji.
Historia Git i obecny model rozwoju Linuksa pokazują, że Torvalds preferuje małe, częste i stopniowe zmiany.
Sponsorowane
Odkryj rewolucyjną metodę nauki języków
Sprawdź jak w 30 dni opanować podstawy dowolnego języka obcego bez wychodzenia z domu.
Linus Torvalds, twórca Linuksa i osoba odpowiedzialna za nadzorowanie rozwoju jego jądra, nie podziela powszechnej nieufności części społeczności open source wobec sztucznej inteligencji. Podczas Open Source Summit Europe powiedział, że sam bardzo lubi korzystać z AI. Jego stanowisko jest jednak bardziej zniuansowane niż prosta pochwała generowania kodu. Torvalds rozdziela używanie AI dla własnej satysfakcji, nauki lub projektów hobbystycznych od stosowania takich narzędzi przy pracy nad krytycznym elementem systemu operacyjnego.
AI może zwiększać radość z programowania
W rozmowie z Dirkiem Hohndelem, przyjacielem Torvaldsa i szefem Ericsson Software Technology, twórca Linuksa opisał AI jako narzędzie, które poprawiło jego własne doświadczenia z programowaniem. Podkreślił przy tym, że nie zajmuje się obecnie dużą częścią codziennego programowania jądra. Jego rola polega przede wszystkim na utrzymywaniu projektu i zbieraniu pracy wykonywanej przez innych deweloperów. Mimo to nadal bardzo lubi pisać kod i uważa, że AI może sprawić, iż programowanie stanie się bardziej dostępne oraz przyjemniejsze, jeśli użytkownik traktuje model jako narzędzie, a nie autonomicznego autora.
Torvalds wykorzystuje AI do zadań, których sam nie wykonuje dobrze, między innymi do poprawy interfejsu hobbystycznego projektu.
Vibe coding może pomóc początkującym programistom tworzyć rzeczy, które bez wsparcia AI byłyby dla nich trudne.
W jądrze Linuksa AI jest używane między innymi do przeglądania kodu, wyszukiwania błędów oraz problemów bezpieczeństwa.
Największym ograniczeniem nie jest liczba proponowanych zmian, lecz czas potrzebny na sprawdzenie, które z nich są rzeczywiście wartościowe.
Jako przykład Torvalds podał własny projekt związany z gitarowym efektem. Napisał interfejs w języku C, uruchamiany na mikrokontrolerze i małym ekranie. Rozwiązanie działało, lecz wyglądem przypominało mu oprogramowanie z lat 80. Chciał, aby interfejs wyglądał nowocześniej, ale zaznaczył, że nie zajmuje się Javą, ponieważ jego specjalnością są jądra systemów. W tej sytuacji poprosił AI o pomoc. Pierwszy rezultat uznał za bardzo słaby, jednak nie oczekiwał od modelu samodzielnego odtworzenia całego projektu. Miał już działającą wersję w C, więc mógł wykorzystać AI do obszaru, w którym sam czuł się mniej kompetentny, a następnie porównać i poprawić otrzymany efekt.
Słownik artykułu
Pojęcia, które warto znać
Krótkie objaśnienia terminów występujących w tekście. Każde hasło prowadzi do szerszej definicji i przykładów użycia.
Vibe coding jako punkt wejścia, nie metoda dla każdego projektu
Torvalds uważa, że vibe coding bywa niesłusznie wyśmiewany. Jego zdaniem generowanie kodu z pomocą AI może dawać początkującym programistom poczucie, że tworzą coś istotnego i użytecznego. Wysoki poziom współczesnej inżynierii oprogramowania sprawia bowiem, że małe, własne projekty łatwo porównać z dopracowanymi produktami tworzonymi przez profesjonalne zespoły. Torvalds wspominał, że gdy zaczynał programować, około 1981 roku, komputery i programy były prostsze, a ich działanie łatwiej było zrozumieć. Dzisiaj próg wejścia jest wyższy, dlatego AI może pełnić funkcję ułatwiającą rozpoczęcie pracy i eksperymentowanie.
To podejście nie oznacza jednak, że wygenerowany kod można bez sprawdzania włączać do ważnych projektów. Torvalds ostrzegał, że z AI trzeba obchodzić się szczególnie ostrożnie, gdy praca dotyczy czegoś realnego i istotnego. W przypadku jądra Linuksa każda propozycja musi zostać oceniona przez ludzi znających konkretny podsystem, jego ograniczenia i dotychczasową historię. Sam fakt, że narzędzie potrafi wygenerować kod wyglądający wiarygodnie, nie przesądza o jego poprawności. Ta różnica między osobistym projektem a infrastrukturą używaną przez szeroką społeczność jest kluczowa dla stanowiska Torvaldsa.
AI znajduje błędy, ale zwiększa obciążenie opiekunów
Torvalds dostrzega praktyczne zastosowania AI także w rozwoju jądra Linuksa. Hohndel zapytał go o Sashiko, agentowy system przeglądu kodu jądra. Publiczne wyniki jego analiz pojawiają się na liście dyskusyjnej Linux Kernel Mailing List. Według Torvaldsa część opiekunów podsystemów oczekuje już, że zgłaszane zmiany przejdą taki przegląd przed zaakceptowaniem. Nie oznacza to, że każdy pull request musi być analizowany przez AI. Wymagania różnią się między opiekunami, choć Torvalds ocenia, że z czasem takie sprawdzanie może stać się powszechniejsze.
Automatyczna analiza może wskazywać prawdziwe problemy bezpieczeństwa, a także ujawniać błędy w starych sterownikach, które nie są już używane i przez lata pozostawały niezauważone. Z punktu widzenia jakości kodu prowadzi to do wartościowych poprawek. Jednocześnie każda taka sugestia tworzy dodatkową pracę dla ludzi. Opiekun musi ocenić, czy problem rzeczywiście istnieje, czy proponowany patch rozwiązuje jego przyczynę, oraz czy zmiana nie narusza innych elementów systemu. AI może więc poprawiać bazę kodu, ale nie usuwa potrzeby ludzkiego przeglądu.
Największy problem pojawia się wtedy, gdy model tworzy przekonujące, lecz nieprawdziwe zgłoszenie błędu. Jego obalenie może wymagać znacznego wysiłku, nawet jeśli ostatecznie nie prowadzi do żadnej zmiany w kodzie. Innym ryzykiem są wąsko ukierunkowane patche, które usuwają jeden widoczny objaw, ale pozostawiają właściwą przyczynę problemu. Torvalds określał część takich propozycji jako bezmyślne poprawki tymczasowe. W jego ocenie AI pomaga w znajdowaniu i naprawianiu usterek, ale równocześnie może doprowadzić opiekunów do przeciążenia.
Rozmowa dotyczyła także historii procesu tworzenia Linuksa, ponieważ projekt obchodził 35. rocznicę. Na początku nie miał rozbudowanej infrastruktury deweloperskiej. Torvalds przygotowywał zmiany jako archiwa tar i poprawki, a następnie regularnie udostępniał nowe wersje kodu. Wspominał, że wewnętrzne patche tworzył codziennie, a co najmniej raz w tygodniu publikował kolejną wersję. Przy małym projekcie taki model działał zaskakująco dobrze. Dystrybucja nowych archiwów i towarzyszących im zmian trwała do 2002 roku, kiedy skala przedsięwzięcia była już znacznie większa.
Torvalds od początku chciał, aby deweloperzy mieli własne lokalne środowiska pracy. Nie chodziło wyłącznie o niechęć do istniejących narzędzi, lecz o przekonanie, że każdy uczestnik powinien móc pracować niezależnie na własnej kopii projektu. Wraz ze wzrostem społeczności ręczne przyjmowanie i nakładanie zmian stało się jednak wąskim gardłem. Potrzebny był lepszy sposób integrowania pracy różnych podsystemów, między innymi sieciowych i związanych z architekturą ARM. Ten problem doprowadził do ważnej zmiany w sposobie zarządzania kodem.
Taką zmianę przyniósł BitKeeper, system kontroli wersji, który wykorzystywał rozproszony model pracy. Jego licencja podzieliła społeczność jądra i część deweloperów odmówiła korzystania z tego narzędzia, ale Torvalds oceniał je jako bardzo udane. BitKeeper pokazał mu, co może dać rozproszona kontrola wersji, i pomógł określić wymagania wobec następnego rozwiązania. Gdy w 2005 roku spór licencyjny odebrał projektowi dostęp do tego narzędzia, powrót do wcześniejszego sposobu pracy nie był już atrakcyjny. Odpowiedzią Torvaldsa stał się Git.
Pierwsza działająca wersja Git powstała według relacji przywołanej w rozmowie w ciągu 11 dni. Torvalds przygotował nowy model obiektów, kod i działające narzędzie w czasie krótszym niż dwa tygodnie. Początki projektu nie były łatwe. Deweloperzy przyzwyczajeni do CVS musieli nauczyć się innego sposobu pracy, a wczesne wersje Git miały niedoskonałości. Torvalds podkreśla jednak, że późniejszy rozwój narzędzia nie był wyłącznie jego zasługą. Po około sześciu miesiącach przekazał utrzymanie innym osobom, a obecny Git jest znacznie dojrzalszy niż wersja z 2005 roku. Według przywołanego w materiale badania Stack Overflow z 2022 roku z Git korzystało niemal 94 procent respondentów i prawie 97 procent profesjonalnych programistów.
Podobnie stopniowo zmieniał się sam proces wydawania jądra Linuksa. Projekt odszedł od długiego utrzymywania osobnych gałęzi rozwojowych i stabilnych na rzecz częstszych wydań, okna scalania oraz wersji kandydackich. W starszym modelu zmiany gromadziły się w gałęzi rozwojowej, a dystrybucje wybierały potrzebne elementy i przenosiły je do stabilnych jąder. Wydania planowane początkowo co rok mogły przeciągać się na lata, co utrudniało planowanie. Torvalds zaproponował znacznie krótszy cykl. Początkowy cel pięciu tygodni był bardzo ambitny, a praktyka ustabilizowała się ostatecznie na rytmie około dziewięciu do dziesięciu tygodni.
Torvalds nadal uważa ten model za wyjątkowo skuteczny. Nie chce, aby rozwój Linuksa opierał się na pojedynczych, spektakularnych premierach dużych funkcji. Jego zdaniem lepsze rezultaty daje ciąg małych zmian, które z czasem składają się na większe możliwości. Ta zasada łączy historię procesu rozwoju z obecnym podejściem do AI. Narzędzia oparte na sztucznej inteligencji mogą przyspieszyć wykrywanie problemów i pomóc w przygotowaniu poprawek, lecz muszą zostać włączone w proces, który nadal wymaga odpowiedzialnej oceny człowieka. W przypadku Linuksa celem pozostaje nie jednorazowa rewolucja, lecz stopniowa poprawa stabilnego i szeroko używanego systemu.
