Będzie łatwiej albo wręcz przeciwnie. Czy wkrótce programować będziemy tylko w języku naturalnym?
Temat powrócił, nagłośniony dzięki wypowiedziom szefa OpenAI, Sama Altmana (1), który mówi, że wiele osób już zaczęło programować jedynie w języku naturalnym. W jego ocenie stanie się to powszechne w ciągu 5…10 lat. W obiegu pojawiły się też komentarze innych tuzów świata technologicznego. Jensen Huang z firmy NVIDIA powiedział, że pewnego dnia każdy będzie programistą, a Satya Nadella z Microsoftu uważał, że „każdy jest programistą” już teraz.
Zdjęcie: commons.wikimedia.org
Rozgorzała dyskusja o tym, czy ewolucja w kierunku programowania niewymagającego znajomości języków programowania i umiejętności pisania poprawnego kodu, gdy większość kodowania przejmie sztuczna inteligencja, będzie w przyszłości zabierać pracę inżynierom oprogramowania. Choć obawy są, to jednak wielu ekspertów branżowych, np. Fracois Chollet, twórca znanej biblioteki Keras, przewiduje, że w ciągu najbliższych pięciu lat powstanie nawet dziesięć milionów więcej nowych miejsc pracy, które będą wymagały znajomości języków programowania, takich jak Python, C czy JavaScript.
Altman też nie przewiduje masowego odbierania programistom pracy przez AI. Jego zdaniem ludzie, wyręczeni w prostszych czynnościach przez algorytmy automatyzujące zadania programistyczne, będą mogli skupić się na wyższym poziomie abstrakcji, na rozwiązywaniu problemów związanych z logiką działania systemów i procesów, które ma obsługiwać kod. Ostatecznie połączenie narzędzia, jakim jest sztuczna inteligencja, z inteligencją i wiedzą programistów powinno podwyższyć wydajność i skuteczność rezultatów pracy programistycznej. Każdy prawdopodobnie będzie kodował w języku naturalnym, ale jak uważa Altman, niekoniecznie uczyni go to programistą. Umiejętności składające się na ten zawód są znacznie bardziej złożone niż umiejętność umieszczania podpowiedzi w narzędziu sztucznej inteligencji, kopiowania kodu lub po prostu pisania w języku naturalnym.
Chollet pisał na platformie X: „Myślę, że byłoby świetnie, gdyby można było w pełni zautomatyzować inżynierię oprogramowania (moją pracę), ponieważ mógłbym wtedy przejść do rzeczy o wyższym potencjale. Tworzenie oprogramowania jest środkiem do celu, a nie celem”. Jak zauważa, inżynieria oprogramowania to praca nad modelowaniem problemów i ich rozwiązań.
Czy rozwiązując problem komplikacji, nie skomplikujemy jeszcze bardziej?
Myśl o automatyzacji procesu programowania ma związek z innym znanym zjawiskiem - narastającą komplikacją kodu tworzonego na przestrzeni lat i dekad. Znane prawo Moore’a dotyczyło sprzętu. Liczba komponentów, z których składają się układy scalone, wzrosła od 1965 roku o osiem rzędów wielkości. Oprogramowanie, choć jego złożoność również rosła, zmieniało się według innych zasad, lecz z pewnością postęp w tej dziedzinie nie polega na powiększaniu liczby linijek kodu. A jeśli w miarę rozwoju systemów tak się właśnie dzieje, to ilość wcale nie przechodzi w jakość.
Oprogramowanie jest czymś zupełnie innym niż systemy mechaniczne i elektromechaniczne, nad którymi człowiek panował z łatwością za pomocą prostych instrukcji i własnego doświadczenia. W świecie programów niewielka edycja tekstu w pliku sprawia, że ta sama porcja krzemu może przekształcić się z autopilota w samolocie w system kontroli zapasów w magazynie. Elastyczność ta jest cudowną cechą oprogramowania i zarazem jego przekleństwem, ponieważ niskie koszty zmian prowadzą do tego, że oprogramowanie jest stale modyfikowane. Z czasem programy mają tendencję do rozrastania się bez ograniczeń. „Problemem”, pisała Nancy Leveson, profesor aeronautyki i astronautyki w Massachusetts Institute of Technology w swojej książce pt. „Engineering a Safer World: Systems Thinking Applied to Safety”, „jest to, że budujemy systemy, które wykraczającą poza zdolność do ogarnięcia umysłem człowieka”.
Tradycyjnie programiści pisali oprogramowanie jako serię twardych reguł - w przypadku wystąpienia X należy wykonać Y. Człowiek instruuje w tym modelu maszynę, krok po kroku, co ma robić. Gdy kod zaczyna się komplikować a potem nawarstwiać przez kolejne poprawki i uzupełnienia kolejnych autorów, którzy niekoniecznie się znają i są w kontakcie, pojawiają się problemy. Ostatecznie działania maszyny stają się niejako wypadkową wszystkich instrukcji w kodzie, jej właściwie już samodzielnym wnioskiem z tego programistycznego galimatiasu. A wnioskowanie maszyny może nie mieć nic wspólnego z ludzkimi intencjami, stąd błędy, awarie systemów, wyłączenia albo wypadki, czasem nawet śmiertelne.
Być może AI rozwiąże problem nawarstwiania się kodu i komplikacji, generując własny jednorodny maszynowy kod. A może pogorszy galimatias, wprowadzając do niego własny kod, który będzie jeszcze mniej czytelny. W technikach uczenia maszynowego co do zasady omijany jest etap programowania przez ludzi. Chodzi o to, aby sieć neuronowa sama wytworzyła algorytm. W większości przypadków AI nie mamy dokładnej wiedzy, jak maszynowy algorytm działa. Pod wieloma względami czynności systemu AI są czarną skrzynką.
Rozwój sztucznej inteligencji zakłada zgodę na samodzielność maszyny i rezygnację z próby przewidzenia wszystkiego, co było immanentną cechą starego myślenia programistycznego, prowadzącego zresztą do znanych, wspomnianych wyżej problemów. Maszyna chyba jednak rozumie algorytm, który sama tworzy. Jest on jednak nieprzenikniony, dla nas i nie wiemy, czy realizuje lub czy realizuje właściwie nasze cele. Nie chcemy być zaskakiwani wtedy, gdy jest już za późno. Sprawdzanie przez człowieka kodu wygenerowanego przez maszynę jest chyba za trudne i nie o to chodzi.
Maszyna ponadto może nie zrozumieć lub źle zrozumieć nas. Według wielu ekspertów pełny dwuznaczności i pułapek logicznych język naturalny nigdy nie stanie się pełnoprawnym narzędziem wspomagającym programowanie, zwłaszcza gdy chodzi o tworzenie kodu o bardzo dużej wadze, np. oprogramowania zarządzającego kluczową infrastrukturą, w medycynie, w dziedzinie obronności i bezpieczeństwa.
Mirosław Usidus
