AI – kolejna rewolucja w programowaniu
Trwa już trzeci rok rewolucji AI.
Oczywiście, modele AI rozwijano dużo dłużej, ale od około trzech lat są one bardziej mainstreamowe, bardziej dostępne i tańsze w stosunku do możliwości. I widać już ewidentnie ogromny wpływ tego na programowanie jako zajęcie, pracę, a także na całą branżę IT. Efekt jest taki, że coraz więcej kodu jest tworzone z użyciem modeli bezpośrednio lub z ich wsparciem. Na dniach szef Google’a pochwalił się, że 25% kodu u nich, czyli jedna czwarta, już jest robiona przez modele a chwilę potem Satya Nadela – szef Microsoft – podał podobną liczbę dla swojej firmy.
A z drugiej strony mamy (głównie w mediach antyspołecznych) narzekania i jęki, że ten kod jest słaby, że jest nieoptymalny, że wcale nie jest czytelny, że będzie trudny w utrzymaniu, bo trzeba będzie go zrozumieć i poprawiać po tych modelach albo używać znów modeli, żeby ten kod ogarnąć.
Mnie te jęki o tyle nie zaskoczyły, że słyszałem je już wcześniej. Dużo wcześniej.
Historia się powtarza
Kiedy zaczynałem studia w roku 1989, spotkałem starych informatyków, którzy mocno narzekali, że kompilatory języków wysokiego poziomu (takich jak Pascal czy Modula 2) generują nieoptymalny kod maszynowy. Twierdzili, że powstające w wyniku kompilacji instrukcje dla procesora powodują, że wykonuje on mnóstwo zbędnych czynności, przez co kod nie jest efektywny. A przy tym kod jest za duży, bo te zbędne instrukcje i struktury zajmują (dużo wtedy cenniejsze) miejsce w pamięci.
Miałem wówczas okazję osobiście się przekonać, że to prawda.
W tamtych czasach mieliśmy komputery PC z systemem MS-DOS – oraz pierwsze wirusy komputerowe. No i pisaliśmy z kolegami z roku wirusa, którego zadaniem miało być granie muzyki.
Zanim przejdę dalej młodszemu pokoleniu należy się wyjaśnienie: dzisiejsze komputery mają praktycznie syntezatory muzyki wysokiej klasy, które pozwalają generować dźwięki w bardzo dobrej jakości (dlatego większość z nas nie ma już ”wież HiFi” tylko Spotify). Wtedy to był tylko głośniczek podpięty do płyty głównej, skonstruowany głównie do wydawania krótkich pisków – jego zadaniem było sygnalizowanie użytkownikowi, że np. wystąpił błąd albo zakończył się jakiś proces.
Granie melodii z pomocą tego czegoś wymagało naprawdę niezłego kombinowania. No i na roku mieliśmy kolegę z talentem, który potrafił skomponować muzykę – i to nie byle jaką, ale taką, która wbijała się w mózg i miała fajny rytm – a potem napisać kod grający to na tym głośniczku. Unikalna kombinacja umiejętności. Z tym, że napisał to w Pascalu, bo assemblera za bardzo nie znał. Po skompilowaniu kawałek kodu grający muzyczkę miał około 5 kilobajtów, co na nasze potrzeby było stanowczo za dużo.
Wraz z innym kolegą przysiedliśmy nad tym i zaczęliśmy przekładać to ręcznie na assembler. Zajęło nam to kilka dni pracy. Efekt był taki, że osiągnęliśmy wielkość około 800 bajtów. Ten sam rezultat – muzyka grała identycznie – ale kod był pięć razy mniejszy.
W ten sposób przekonałem się bezpośrednio, że starzy informatycy mieli rację – kod generowany przez kompilatory faktycznie był nieoptymalny i to mocno.
Tylko co z tego?
Co z tego, skoro w skali branży to nie miało żadnego znaczenia! Prawo Moore’a działało (choć wtedy trochę wolniej), moc komputerów i wielkość pamięci rosły, więc kompletnie nie miało znaczenia, że kod maszynowy jest nieoptymalny i procesory wykonują zbędne czynności a kod jest 5-6x “za duży”. Rosnąca moc komputerów pokrywała te niewydajności z naddatkiem.
Dużo ważniejsze stało się to, że programista mógł zrobić coś szybko, że nie potrzebował tych czterech dni, żeby wycyzelować program, tylko mógł zrobić go dużo szybciej. Zarazem, nie musiał wgryzać się w ograniczenia rejestrów, adresacji itp. – mógł operować łatwiejszymi do zrozumienia abstrakcjami zmiennych, funkcji i tak dalej. A to, że efekt był co najmniej pięciokrotnie mniej wydajny i większy? Nikt się tym przejmował! Komputery i tak były, jako się rzekło, coraz szybsze.
Dalszy rozwój informatyki podążał dokładnie tą ścieżką: wzrost mocy procesorów, coraz więcej dostępnej pamięci, coraz większe oderwanie języków programowania od poziomu maszyny. Potem przyszła Java i koncepcja maszyny wirtualnej, która wprowadziła kolejny poziom niewydajności. O cyzelowaniu wydajności, poza kilkoma niszowymi zastosowaniami, generalnie zapomniano.
W efekcie większość współczesnych programistów nawet nie wie, jak skonstruowany jest procesor, jak wygląda język maszynowy, a w szczególności nigdy go nie używała. I to w niczym nie przeszkadza – jest to całkowicie normalne.
Nowy paradygmat
Rozumiesz już analogię?
Co za różnica, że kod pisany przez modele AI nie jest idealny? To nie ma żadnego znaczenia, bo ten robiony przez nisko płatnego juniora w centrum outsourcingu gdzieś Indiach czy w Polsce też jest słaby. Wielu z tych, co tak jęczą i narzekają porównuje kod generowany przez AI do wyidealizowanego kodu, robionego przez super wymiataczy. A tymczasem większość kodu na świecie tak nie wygląda, więc już teraz kod z AI jest przeciętnie lepszy niż przeciętny.
Co z tego, że być może będziemy potrzebować później modelu AI, żeby zrozumieć ten kod i go modyfikować? Żaden problem, przecież będziemy te modele mieli – i to jeszcze lepsze niż obecnie.
To, co obserwujemy, to kolejna zmiana paradygmatu w programowaniu. Zamiast pisać maszynie bezpośrednio, co ma zrobić (do czego służyły wszystkie języki programowania strukturalne i obiektowe), teraz mówimy maszynie, co chcemy osiągnąć. A maszyna generuje dla nas etap pośredni w postaci kodu, który następnie jest przekładany (kompilator/interpreter) na kolejny etap, a potem kolejny, aż w końcu gdzieś tam ostatecznie procesory nadal wykonują instrukcje ze swojego relatywnie prostego zestawu.
Patrząc perspektywicznie ten etap pośredni w postaci kodu w jakimś języku programowania prawdopodobnie zacznie zanikać. Bo po co? Jaki to ma sens? Maszyna będzie generować bezpośrednio wynik, rezultat, którego oczekuje użytkownik. Ale pewnie potrwa to trochę, bo przez te ~50 lat wytworzyliśmy już bardzo dużo “infrastruktury” wokół języków programowania, więc generowanie kodu w którymś z nich jest na razie po prostu prostszym i szybszym sposobem na działający efekt.
Czy wartość oprogramowania spadnie?
Ostatnio zadano mi ciekawe pytanie: czy nie obawiam się, że w efekcie wartość programów jako takich spadnie?
To pytanie warte zastanowienia. Skoro upowszechnianie się programowania z pomocą modeli AI może spowodować spadek wartości zawodu programisty, to czy efekt jego pracy – produkt końcowy – nie stanie się również mniej wartościowy? A skoro tak, to czy cała branża nie imploduje?
Moim zdaniem: oczywiście że wartość oprogramowania spadnie! Ale to wcale nie oznacza końca dla branży. Wręcz przeciwnie – tych produktów cyfrowych będzie po prostu więcej.
Znów odwołam się do historii, bo ta pokazuje pewne długofalowe wzorce działania ludzkości. Na przestrzeni wieków wiele technologii już wdrożono i zawsze było tak, że na początku dana jednostkowa rzecz będąca produktem danej technologii była droga, a potem stawała się coraz tańsza.
Weźmy przykład samochodu. Sto czterdzieści lat temu samochód był zabawką dla bogaczy, a sto lat temu był luksusem dostępnym wyłącznie wybranym, zwłaszcza w takim kraju jak Polska. Wielkość produkcji wiodących firm była maleńka według dzisiejszych standardów. Jednostkowo samochód kiedyś był więc dużo bardziej wartościowym przedmiotem niż teraz (zwłaszcza używany). Obecnie skala produkcji jest nieporównywalnie większa a to, że samochody nowe są relatywnie drogie wynika głównie z przerażająco wysokiego opodatkowania w Europie (wystarczy zobaczyć jakie ceny nowe auta mają w Chinach). Czy branży to zaszkodziło? Nie.
To samo z komputerami. Komputer sprzed 55 lat był niewiarygodnie drogą rzeczą, poza zasięgiem przeciętnego człowieka. “Komputer osobisty”, który pojawił się na początku lat 80-tych, czyli 45 lat temu, też był rzeczą bardzo drogą – już nie tak jak wcześniej, ale nadal dostępną głównie dla klasy wyższej średniej. Te maszynki typu Commodore 64 czy wczesne pecety – to nie były przedmioty, na które stać było każdego, a już szczególnie w Polsce. Tych komputerów było jednak dużo więcej niż dekadę wcześniej i to o kilka rzędów wielkości – a zarazem było ich dużo, dużo mniej niż teraz.
Dzisiaj komputer nie jest aż tak drogą rzeczą. Oczywiście, są drogie komputery, ale są też tanie, a różnice między nimi nie są gigantyczne. Ktoś, kto kupi sobie taniego laptopa za 2 tysiące złotych w markecie, może fundamentalnie zrobić to samo, co ktoś, kto kupił najnowszego MacBooka. Owszem, nie tak wygodnie i nie tak szybko, ale co do możliwości – różnica nie jest fundamentalna.
Czy to zaszkodziło branży? Wprost przeciwnie. Firmy produkujące komputery są dziś bogatsze niż kiedykolwiek. A już z pewnością są bogatsze niż wtedy, kiedy komputery były drogie a ich liczbę w danym kraju można było wyrazić 2-3 cyfrową liczbą.
Jednostkowa wartość vs. skala
Tak samo będzie z oprogramowaniem. Jednostkowo wartość pojedynczego programu oczywiście że będzie mniejsza, ale warto zauważyć, że to się już dzieje. W czasach pierwszych maszyn obliczeniowych, w latach 60-70., budowa oprogramowania była gigantycznym przedsięwzięciem, angażującym mnóstwo ludzi, trwającym długo, więc tylko największe firmy mogły sobie na to pozwolić.
Dzięki strukturalnym językom programowania i komputerom osobistym już w latach 80-tych programy ludzie mogli tworzyć sami jeśli mieli odpowiednią wiedzę. Tych programów zrobiło się więc więcej. Pod koniec tamtej dekady pojawiło się freeware, shareware i ruch open source, czyli coraz więcej oprogramowania było dostępne zupełnie za darmo. Czy to zaszkodziło branży?
Wprost przeciwnie. Gigantyczne firmy softwarowe, dysponujące ogromnymi funduszami, powstały dopiero wtedy, a nie w czasach wielkich maszyn obliczeniowych, kiedy jednostkowe programy były bardzo drogie.
Zatem, moim zdaniem odpowiedź na pytanie, czy oprogramowanie będzie mniej wartościowe, jest niejednoznaczna. Jednostkowo prawdopodobnie tak. Ale myślę, że całej branży to wyjdzie raczej na dobre, bo będziemy mieli więcej produktów cyfrowych, nie mniej. Będą one coraz bardziej dopasowane do różnych potrzeb, pojawi się większy „rozrzut” możliwości.
Jeżeli mam 100 programów, które próbują zaspokoić jakąś potrzebę, a wcześniej miałem 10, to teraz mam dużo większe szanse, że przynajmniej część z nich dobrze tę potrzebę zaspokoi, dobrze trafi w cel.
W skali makro będzie to raczej oznaczać rosnącą wartość dla tych, którzy się tym zajmują (szczególnie dużych firm), ale w skali mikro wartość pojedynczego “kawałka” oprogramowania prawdopodobnie będzie dużo mniejsza niż była jeszcze niedawno.