Linus Torvalds i asystenci AI: Debugowanie jądra systemu Linux
Gdy w grę wchodzi rozwój i stabilność najpopularniejszych systemów, usuwanie usterek potrafi pochłonąć ogromne zasoby czasu. Przekonał się o tym niedawno Linus Torvalds, twórca jądra systemu Linux, który podczas rozwiązywania sprzętowego problemu czarnego ekranu w jednym ze sterowników postanowił zaprząc do pracy asystentów AI. Wnioski płynące z tego eksperymentu doskonale ilustrują, jak w praktyce wygląda obecnie wsparcie sztucznej inteligencji w krytycznych i wysoce skomplikowanych projektach infrastrukturalnych.
Studium tego przypadku, podjęte między innymi w branżowym podcaście Patoarchitekci (odcinek Slop factories vs dark AI factories - na którym poziomie realnie jesteśmy z 11 września), obnaża różnicę pomiędzy marketingowymi obietnicami w pełni autonomicznych narzędzi do pisania kodu a faktyczną współpracą modelu z doświadczonym inżynierem.
18 restartów jądra dla jednej linijki kodu
Najbardziej zaskakujący w całym procesie okazał się stosunek nakładu pracy do ostatecznego kształtu poprawki. Rozwiązanie błędu czarnego ekranu, z którym mierzył się Linus Torvalds, wymagało zmiany zaledwie 1 linijki kodu w sterowniku. Droga do znalezienia i przetestowania tego fragmentu była jednak bardzo długa.
Aby potwierdzić skuteczność wprowadzanych przez siebie modyfikacji oraz sugestii generowanych przez sztuczną inteligencję, programista musiał przygotować łącznie aż 24 patche. Proces ten wymagał także przeprowadzenia 18 restartów jądra (rebootów), co w przypadku testowania tak krytycznego komponentu systemowego jest procedurą żmudną i czasochłonną.
Sztuczna inteligencja w roli "rubber ducking"
Na obecnym etapie rozwoju, narzędzia wspierające programistów nie przypominają jeszcze całkowicie niezależnych inżynierów, zdolnych zdiagnozować złożony błąd w sterownikach sprzętowych, napisać poprawkę i przekazać bezbłędny kod. W opisywanym przypadku asystenci AI pełnili raczej rolę zaawansowanego mechanizmu koncepcyjnego weryfikowania pomysłów.
Model sprawdził się najlepiej w roli rubber ducking – znanej w IT metody „gumowej kaczuszki”, polegającej na tłumaczeniu własnego toku rozumowania na głos, co ułatwia samodzielne odnalezienie luki logicznej. Ten wariant współpracy wymagał od twórcy Linuksa bezustannego nadzoru i kierowania analizą. Sztuczna inteligencja zmuszona była do weryfikacji założeń tylko poprzez ciągłe „poganianie” i punktowanie jej pomyłek. Narzędzie ani przez moment nie zostało pozbawione ścisłej, merytorycznej kontroli seniora.
Granice asystentów w nowoczesnym IT
Rozwiązanie usterki przez twórcę systemu operacyjnego Linux to znakomity przykład szerszego trendu panującego dziś w branży deweloperskiej. Jak zauważają autorzy podcastu Patoarchitekci, narzędzia AI faktycznie potrafią drastycznie przyspieszyć pracę – co potwierdzają rynkowe benchmarki – ale dotyczy to w dużej mierze seniorów. Tylko osoba z głębokim zrozumieniem technologii bazowej potrafi wychwycić błędy w kodzie dostarczonym przez model i narzucić mu odpowiedni rygor testowania.
Z perspektywy redakcyjnej płynie z tego czytelny wniosek: dopóki sztuczna inteligencja będzie masowo generować kod (zjawisko nazywane niekiedy slop factories) bez wysoce wiarygodnego zrozumienia niuansów niskopoziomowych sprzętu, asystenci AI pozostaną jedynie pomocnikami, którzy nierzadko potrafią zgubić się w drodze do celu. Pełna automatyzacja debugowania złożonych problemów w oprogramowaniu rdzeniowym to wciąż bardziej marzenie działów marketingu niż codzienność inżynieryjna, a ostateczny wysiłek naprawczy spoczywa w rękach doświadczonego programisty.
