Linus Torvalds o AI: narzędzie, które pokochał

Podczas Open Source Summit Europe w Pradze Linus Torvalds, twórca jądra Linux, podzielił się swoim spojrzeniem na sztuczną inteligencję. W rozmowie z Dirkiem Hohndelem, szefem Ericsson Software Technology i swoim dobrym znajomym, stwierdził wprost, że lubi korzystać z AI. To stanowisko kontrastuje z nastrojami w części społeczności open source, gdzie pojawiają się głosy sceptyczne – na przykład firma System76 zakazała treści generowanych przez AI w swoim środowisku COSMIC.

Entuzjazm Torvaldsa ma jednak wyraźne granice. Inaczej traktuje on AI w projektach hobbystycznych, a inaczej w kluczowej infrastrukturze, jaką jest jądro Linux. Tam wygenerowane poprawki i raporty o błędach mogą przytłoczyć maintainerów.

Dlaczego Torvalds ceni AI w projektach hobbystycznych

Torvalds przyznaje, że sam nie zajmuje się już intensywnie programowaniem jądra – jego rola sprowadza się głównie do koordynowania pracy innych. Mimo to wciąż czerpie radość z kodowania, a AI postrzega jako narzędzie, które tę przyjemność wzmacnia.

Zwraca uwagę na istotną zmianę w rzeczywistości programistów. Gdy zaczynał w 1981 roku, komputery były znacznie prostsze, a programy łatwiejsze do zrozumienia. Dziś poprzeczka jest zawieszona bardzo wysoko – początkujący mają trudność z dostrzeżeniem wartości własnych, skromnych wysiłków na tle dopracowanego, profesjonalnego oprogramowania.

Vibe coding jako brama do programowania

W tym kontekście Torvalds broni zjawiska określanego jako „vibe coding” – czyli tworzenia kodu w swobodnej, eksploracyjnej interakcji z modelem AI. Jego zdaniem to doskonały sposób, by początkujący poczuli satysfakcję i przekonali się, że ich praca ma znaczenie. Porównuje AI do „bramy” do świata programowania, która pozwala zrealizować zadania wcześniej trudne lub wręcz nieosiągalne dla nowicjuszy.

Przykład z życia: efekt gitarowy

Torvalds ilustruje to własnym doświadczeniem. Pracując nad swoim projektem hobbystycznym – efektem gitarowym – napisał interfejs w języku C działający na mikrokontrolerze. Wyglądał jednak archaicznie. Choć nie zna Javy, potrzebował nowoczesnego wyglądu. Sięgnął więc po AI, by zrobić coś, w czym nie jest biegły. Jak sam mówi, pierwsza próba była „okropna”, ale dostarczył modelowi własny kod w C jako punkt odniesienia i doprowadził projekt do satysfakcjonującego rezultatu.

AI w jądrze Linux: korzyści i realne koszty

Sztuczna inteligencja odgrywa coraz większą rolę w wykrywaniu i naprawianiu błędów w jądrze Linux. Hohndel pytał o Sashiko – agentowy system recenzowania kodu jądra. Torvalds potwierdził, że publiczne recenzje generowane przez ten system trafiają już na listę dyskusyjną Linux Kernel Mailing List (LKML). Część maintainerów subsystemów oczekuje nawet, że zgłaszane poprawki przejdą taką weryfikację przed akceptacją.

Nie wszystkie zgłoszenia muszą przechodzić przez AI, ale trend jest wyraźny – prawdopodobnie z czasem stanie się to standardem. Narzędzia AI potrafią wychwycić autentyczne problemy z bezpieczeństwem, a także ujawnić usterki w starych, nieużywanych już sterownikach, które przez lata pozostawały niezauważone.

Stres maintainerów i „opatrunki” zamiast rozwiązań

Torvalds nie ukrywa ciemnej strony tego zjawiska. Jak stwierdził, AI poprawia bazę kodu, ale jednocześnie przeciąża maintainerów do poziomu, który staje się problemem. Wspominał już wcześniej w Mumbaju, że przekonujące, lecz zmyślone raporty o błędach wymagają dużego nakładu pracy ludzkiej, by je obalić. Z kolei wąsko ukierunkowane poprawki leczą objawy, nie sięgając przyczyny. Torvalds nazywa część takich zgłoszeń „bezmyślnymi opatrunkami”.

Podczas Linux Kernel Maintainer Summit aż trzy czwarte dyskusji poświęcono temu, jak uczynić generowanie i recenzowanie kodu przez AI mniej stresującym i bardziej użytecznym. Wąskim gardłem nie jest bowiem pozyskiwanie poprawek, lecz przepuszczanie wartościowej pracy przez proces recenzji bez wyczerpywania ludzi, którzy za niego odpowiadają.

Od tarballów do Git: jak zmieniał się proces tworzenia Linuksa

Rozmowa dotknęła także historii rozwoju jądra – z okazji 35-lecia projektu. Na początku nie istniała żadna infrastruktura deweloperska. Torvalds śledził zmiany przez paczki z poprawkami i regularnie publikował zaktualizowany kod źródłowy. Jak wspominał, wewnętrznie tworzył łatki codziennie, a wydawał je co najmniej raz w tygodniu. Jak na mały projekt działało to zaskakująco dobrze.

Dystrybucja nowych wersji tarballi trwała do 2002 roku, gdy Linux stał się znacznie większym przedsięwzięciem. W tamtych czasach, jak mówi Torvalds, był „sam ze sobą i swoim komputerem”. Nie chciał jednak stosować istniejących narzędzi kontroli wersji z uporu – zależało mu, by każdy programista pracował niezależnie, we własnym lokalnym środowisku.

BitKeeper, kontrowersje i narodziny Git

Przełomem okazał się system kontroli wersji BitKeeper. Choć jego własnościowa licencja podzieliła społeczność jądra – część deweloperów odmawiała korzystania z niego – Torvalds uznał go za ogromny sukces. Rozproszona kontrola wersji znacząco ułatwiała scalanie pracy z subsystemów, takich jak sieć czy architektura ARM. BitKeeper pokazał mu, czego naprawdę potrzebuje.

Gdy w 2005 roku spór licencyjny wokół BitKeepera odebrał mu narzędzie, do którego się przyzwyczaił, powrót do starych metod nie wchodził w grę. Odpowiedzią był Git. Hohndel przypomniał, że pierwsza działająca wersja powstała w 11 dni – nowy model obiektów, kod i funkcjonalne narzędzie w niespełna dwa tygodnie. Wczesny Git nie zdobył powszechnej sympatii – deweloperzy przyzwyczajeni do CVS uważali go za obcy, a pierwsze wersje miały niedociągnięcia.

Jego późniejszy sukces wciąż zaskakuje samego Torvaldsa. Według badania Stack Overflow Developer Survey z 2022 roku Git stał się de facto standardem kontroli wersji – używa go blisko 94% respondentów i prawie 97% profesjonalnych programistów. Torvalds podkreśla jednak, że chciał jedynie narzędzia dla Linuksa, a nie rewolucji w globalnym tworzeniu oprogramowania. Jak sam mówi, dostaje czasem „zbyt wiele zasług za Git”. Po około pół roku przekazał jego utrzymanie innym – i zaznacza, że dzisiejszy Git jest znacznie lepszy niż wersja z 2005 roku.

Stabilność ponad spektakularne premiery

Proces wydawniczy jądra także przeszedł znaczącą ewolucję – od długo utrzymywanych, osobnych gałęzi stabilnych i rozwojowych w kierunku częstych wydań, okna scalania i kandydatów do wydania. W starym modelu praca gromadziła się w gałęzi rozwojowej, a dystrybucje przenosiły wybrane zmiany do stabilnych jąder. Wydania planowane na rok mogły rozciągać się na lata, co utrudniało planowanie.

Torvalds zaproponował radykalnie krótszy cykl. Reakcja nie była entuzjastyczna – jak wspomina, ludzie patrzyli na niego, „jakby mu wyrosła trzecia głowa”. Początkowy cel pięciu tygodni był celowo ambitny, ale proces ostatecznie ustabilizował się w rytmie dziewięciu–dziesięciu tygodni. Ten model działa już od dwóch dekad i zdaniem Torvaldsa sprawdza się znakomicie.

Twórca Linuksa odrzuca też wizję organizowania projektu wokół spektakularnych premier. Jest zwolennikiem drobnych, przyrostowych zmian, które z czasem składają się na duże funkcje. Cel rozwoju jądra pozostaje niezmienny: ciągłe, stopniowe ulepszanie i stabilny postęp.

Sztuczna inteligencja zmienia więc sposoby wykrywania i naprawiania problemów w Linuksie, ale filozofia projektu pozostaje ta sama – szybkie, niewielkie usprawnienia w kluczowym, stabilnym systemie operacyjnym.