Jestem doskonale świadomy tego, że przez długi czas programowanie było sprzedawane ludziom jako wręcz droga na skróty do dobrze płatnej pracy biurowej. Wystarczyło nauczyć się jednego języka, poznać framework, zrobić kilka projektów, wrzucić coś na GitHuba i cierpliwie czekać, aż branża sama otworzy przed kimś drzwi. Tak było przed rozpowszechnieniem się sztucznej inteligencji, która wręcz ścięła zapotrzebowanie na juniorów w zespołach. Efekt? Czasy, w których upór i kilka miesięcy intensywnej nauki mogą już nie wystarczyć, aby zacząć robić karierę programisty.
Dlatego pytanie nie brzmi już “jakiego języka warto się nauczyć?”, ale raczej “kim trzeba być, żeby w świecie powszechnej sztucznej inteligencji nadal mieć wartość jako programista?”.
Era sztucznej inteligencji zmieniła to, jak wygląda programowanie
O tym, jak ta zmiana wygląda od środka dużej organizacji technologicznej, rozmawiałem ze Sławomirem Kumką, dyrektorem IBM Software Lab w Polsce. Chodzi tu więc o perspektywę firmy, która pracuje nad dużymi systemami enterprise, sztuczną inteligencją, mainframe’ami, Javą, COBOL-em, chmurą i oprogramowaniem, którego nie da się sprowadzić do prostego polecenia “napisz mi aplikację” w okienku chata.
Kumka nie twierdzi jednak, że sztuczna inteligencja zamyka drogę młodym ludziom do zawodu. Wręcz przeciwnie, widzi w niej narzędzie, które może przyspieszyć rozwój programisty. Jednocześnie jednak bardzo jasno mówi, że wejście do branży wygląda dziś inaczej niż kilka czy kilkanaście lat temu.
Wejście do zawodu programisty się podnosi. Tak jak 10 czy 7 lat temu ktoś mógł skończyć kurs programowania i bez trudu zdobyć pracę programisty, tak dziś już się nie da – mówi Sławomir Kumka z IBM.
Czy się z tym zgadzam? Jak najbardziej tak. Zwłaszcza po 3,5-letnich studiach inżynierskich i chylących się ku końcowi studiach magisterskich ze specjalizacją wytwarzania oprogramowania. Kiedy wybierałem tę drogę edukacji kilka lat temu, rzeczywiście praca dosłownie wręcz leżała na ulicy i to nawet w sektorze produkcji gier wideo, gdzie aktualnie znalezienie pracy jest niewspółmiernie trudne względem tego, co było w przeszłości.
Czytaj też: Programista dostał partnera. Spytałem u źródła, jak IBM Bob poprawia proces tworzenia oprogramowania
Warto o tym wiedzieć i ciągle to pamiętać, bo przez lata wokół IT narósł mit szybkiej ścieżki kariery. Nie całkiem fałszywy, bo wiele osób rzeczywiście weszło do branży po kursach, bootcampach i samodzielnej nauce. Problem w tym, że ten rynek się zmienił. Jeśli proste i skomplikowane zadania może wykonać narzędzie sztucznej inteligencji (i robi to coraz lepiej), to początkujący programista nie może już konkurować samą umiejętnością odtwarzania tutorialowego kodu czy kopiowania jednego rozwiązania do drugiego. Dziś w tym samym czasie może to zrobić byle ogarnięty senior z dostępem do solidnej bazy tokenów.
Nie oznacza to jednak, że oto właśnie kursy, bootcampy albo samodzielna nauka straciły sens. Oznacza raczej, że przestały już wystarczać jako jakiś cudowny bilet wejścia. Kumka dopowiada, że potrzebna jest dziś bardziej ugruntowana wiedza informatyczna, a dzięki sztucznej inteligencji możemy przyspieszyć zdobywanie praktycznego doświadczenia.
Trzeba mieć ugruntowaną wiedzę informatyczną, żeby wejść do tego zawodu, a potem doświadczenie przychodzi dużo szybciej dzięki używaniu sztucznej inteligencji – dodaje Kumka.
Dla mnie to jest właśnie najważniejsza różnica tego, co było i co nadeszło na rynku. Sztucznej inteligencja nie zastępuje fundamentów. Ona je bezlitośnie weryfikuje.
Programista przyszłości musi rozumieć całe systemy, a nie tylko samą składnię
Przez lata karierę programisty często dało się opisać po prostu przez język albo framework. Java developer, C# developer, React developer, backendowiec, frontendowiec czy mobile developer. Ten podział nadal ma sens, ale coraz gorzej opisuje pełną wartość człowieka w zespole. Składnię da się dziś podejrzeć w dokumentacji, zapytać model, wygenerować fragment kodu albo szybko przepisać coś z jednego języka na drugi. Jednocześnie dużo trudniej jest zrozumieć, jak działa taki cały system i to zwłaszcza wtedy, kiedy wyszedł nawet częściowo spod ręki AI.
Oczekiwania wobec programistów ewoluują. W tym momencie odchodzimy trochę od samej głębokiej znajomości jednego czy dwóch języków, a bardziej idziemy w stronę rozumienia technologii, systemów i architektury rozwiązań – mówi Sławomir Kumka.
Jest to bardzo ważna uwaga, a to zwłaszcza dla młodych, aspirujących programistów. Nie chodzi oczywiście o to, żeby nie uczyć się konkretnych technologii. Trudno wejść do branży bez języka, narzędzi, projektów i praktyki. Nie można jednak mylić dziś narzędzia z zawodem. Znajomość Reacta, Javy, C# czy Pythona jest środkiem, nie celem. Celem jest umiejętność rozumienia problemu i zbudowania rozwiązania, które ma sens w danym środowisku.
Mając taką wiedzę, zaczynamy rozumieć, jak działają dzisiejsze systemy. A kiedy dochodzimy do tego, jak je programować, wtedy przydaje się AI. Nie po to, żeby napisało za nas kod, o którym nie mamy zielonego pojęcia, tylko po to, żeby pomogło nas wyedukować – tłumaczy Kumka.
To jest ta granica, której młodzi programiści nie powinni przekraczać. AI jako nauczyciel, przewodnik po cudzym kodzie, pomoc przy zrozumieniu zależności? Tak. AI jako proteza zamiast wiedzy? Nie. Bo jeśli programista nie rozumie, co model wygenerował, to nie jest po prostu szybszym programistą. Jest osobą, która szybciej przenosi cudzy błąd do swojego projektu, a kiedy coś się wysypie, to nagle nie wie, jak to naprawić.
“Trash in, Trash out” wraca w nowej formie
W czasach sztucznej inteligencji dużo mówi się o promptach, ale często w złym sensie. Jakby chodziło o zestaw magicznych formułek, które trzeba wpisać do modelu, żeby dostać lepszy wynik. Dla mnie to zbyt płytkie ujęcie tej kwestii, bo dobre pytanie do AI nie jest sztuczką. Jest dowodem na to, że człowiek rozumie problem na tyle, żeby sensownie go opisać i już wtedy może zmierzyć się z zadaniem, choć zajmie mu to po prostu dłużej niż AI.
Nieważne, jak dobrze sztuczna inteligencja byłaby wyszkolona i jak dobrze rozumiałaby elementy systemu, jeżeli zadamy pytanie śmieciowe, tak czy inaczej dostaniemy śmieci na końcu. Cały czas funkcjonuje zasada Trash in, Trash out – mówi Sławomir Kumka.
Jest to chyba jedna z najważniejszych lekcji dla młodego pokolenia programistów. AI nie zwalnia z myślenia. W pewnym sensie wymusza myślenie jeszcze bardziej precyzyjne, bo złe pytanie może dać odpowiedź, która wygląda pozornie wiarygodnie, ale prowadzi w złą stronę. Dawniej początkujący programista mógł utknąć na błędzie kompilacji. Dziś może dostać gładko napisaną odpowiedź, która będzie działać pozornie, bo dopóki nie zderzy się z prawdziwym systemem.
Dlatego komunikacja z AI zaczyna przypominać komunikację z zespołem. Trzeba umieć nazwać problem, podać ograniczenia, opisać kontekst, wskazać cel i zrozumieć odpowiedź. Innymi słowy, nie jest to już jakaś kompetencja poboczna, a ważna część potrzebnego dziś warsztatu.
Nie zaczynałbym od gonienia za modą
Podczas rozmowy zapytałem też o konkretne wskazówki co do tego, czego warto się uczyć. Bardzo podoba mi się, że nie sprowadza się ona do “ucz się najmodniejszego frameworka, bo teraz jest popyt”. Kumka wspomina raczej o rozumieniu technologii, trendów i podstaw.
Sugerowałbym rozumienie technologii, uczenie się, jak technologia się rozwija, jakie są dziś kluczowe trendy, a także zdobywanie wiedzy o najważniejszych technologiach, które są używane – mówi.
W świecie enterprise nadal przewija się Java, REST, systemy rozproszone, integracje, backend, dane i stare technologie, które nie znikają nagle tylko dlatego, że przestały być modne. Przy projektowaniu interfejsów nadal liczy się JavaScript, a frameworki takie jak React czy Angular są łatwiejsze do opanowania, jeśli człowiek rozumie język pod spodem, a nie tylko konkretną bibliotekę. Kumka wskazuje też na C i programowanie strukturalne.
Dobrze jest zacząć też od rozumienia C, chociaż mało kto w tym momencie na to patrzy. To buduje sposób konstruowania myśli programisty i późniejszego realizowania tych myśli w różnych technologiach – tłumaczy.
Język C zmusza do patrzenia na program nie przez pryzmat gotowych klas, obiektów i mechanizmów runtime’u, ale przez dane, pamięć, funkcje i przepływ wykonania. Nie chodzi o to, że C jest lepsze od C++ albo C#, a o to, że pokazuje fundament, który w nowszych technologiach często zostaje ukryty pod warstwą wygodniejszych abstrakcji. W C trzeba świadomie myśleć o tym, czym jest zmienna, czym jest adres w pamięci, czym różni się kopia od wskaźnika, dlaczego tablica przekazana do funkcji nie zna automatycznie swojego rozmiaru, kto odpowiada za przydzielenie i zwolnienie pamięci oraz co może się stać, gdy program wyjdzie poza poprawny zakres danych. Automatycznie buduje to bardzo konkretny sposób konstruowania myśli programisty: najpierw definiuję dane, potem funkcje, które na nich pracują, a dopiero później dokładam wyższe modele organizacji kodu.
Oczywiście nie chodzi tutaj o to, żeby każdy początkujący programista rzucał teraz wszystko i zaczynał od pisania wskaźników w C przez najbliższe pół roku. Chodzi raczej o filozofię nauki. Im lepiej rozumiemy podstawy, tym mniej jesteśmy zakładnikami konkretnego narzędzia. Framework może się zmienić. Modny stos technologiczny może wypaść z rynku. Podstawy algorytmiki, struktur danych, przepływu programu, pamięci, komunikacji między usługami i architektury zostają zaś na znacznie dłużej.
Jeżeli ktoś dobrze rozumie podstawy programowania i algorytmów, będzie potrafił bardzo szybko pojąć wiedzę o każdym języku programowania – mówi Kumka.
Innymi słowy, jest jedna z lepszych porad dla młodego programisty – nie buduj kariery wyłącznie na jednym ekosystemie i nawet języku. Ucz się tego, co pozwoli ci zmieniać narzędzia bez zaczynania od zera, a podstawy są w tym wszystkim kluczowe.
AI może przyspieszyć juniora, ale nie zrobi z każdego specjalisty
W dyskusji o AI i rynku pracy łatwo wpaść w dwa skrajne poglądy. Jeden mówi, że młodzi programiści są już niepotrzebni, bo wszystko napisze model. Drugi mówi, że AI otwiera branżę każdemu, bo teraz każdy może “programować” przez rozmowę z chatbotem. Kumka widzi to inaczej. AI może bardzo mocno przyspieszyć rozwój juniora, ale pod warunkiem, że ten junior ma już fundamenty i trafi do środowiska, w którym naprawdę się uczy.
AI o wiele szybciej potrafi przenieść programistę z poziomu juniora na poziom osoby bardziej zaawansowanej – mówi.
To zdanie dobrze brzmi, ale jeszcze ciekawszy jest przykład, który za nim stoi. Kumka mówi o wejściu nowego pracownika w produkt mający kilka milionów linii kodu. Kiedyś dojście do samodzielności w takim środowisku mogło trwać wiele miesięcy.
Kiedy programista trafiał do produktu mającego kilka milionów linii kodu, zanim stawał się samodzielny, mijało 6-7 miesięcy, jeżeli nie rok. W tym momencie jest to skrócone diametralnie. To kilka miesięcy i pracownik jest operatywny – dodaje Kumka.
To jest bardzo konkretna zmiana. Początkujący programista często nie wykłada się w pracy dlatego, że nie zna składni. Wykłada się dlatego, że nie wie, gdzie jest dana rzecz, jak są zbudowane zależności i dlaczego moduł działa tak, a nie inaczej i kto dotknął go wcześniej. Jeśli sztuczna inteligencja potrafi szybciej tłumaczyć produkt, prowadzić po kodzie i wyjaśniać relacje między elementami systemu, to cały onboarding może być krótszy. Jednocześnie jednak to nie znaczy, że można wejść wszędzie bez przygotowania. Kumka doprecyzowuje, że choć junior nie musi mieć dorobku zawodowego, to powinien mieć własne projekty, które pokazują kierunek i realne zainteresowanie technologią.
Jeżeli dorobkiem rozumiemy działalność w środowisku zawodowym, to nie musi mieć dorobku. Na pewno musi mieć dorobek, jeśli chodzi o projekty, które są ciekawe i dotykają technologii, w której stara się o pracę – mówi.
Jest to ważna różnica. Wedle dyrektora IBM Software Lab w Polsce nie trzeba mieć kilku lat pracy za sobą, żeby być wartym rozmowy. Trzeba jednak pokazać coś więcej niż samą deklarację “uczę się programowania”. Własny projekt, nawet niedoskonały, mówi bowiem więcej niż lista obejrzanych kursów. Pokazuje sposób myślenia, upór, dobór technologii, próby rozwiązania problemów i to, czy ktoś potrafił wyjść poza byle ćwiczenie z tutoriala.
Programista przyszłości musi umieć mówić
Być może jedna z najważniejszych zmian dotyczy kompetencji miękkich. W świecie zdominowanym przez narzędzia sztucznej inteligencji programista przyszłości nie staje się mniej komunikatywny. Moim zdaniem dzieje się coś przeciwnego i w rzeczywistości musi być jeszcze lepszy w komunikacji, a to dlatego, że musi rozmawiać nie tylko z ludźmi, ale też z modelem i systemem, aby nie doprowadzić do wspomnianego wcześniej trash in, trash out.
Szukamy ludzi bardziej otwartych na krytykę, wyrażanie opinii i dyskusję. Mit, że programista to osoba w sweterku, siedząca za komputerem, nic niemówiąca i nierozmawiająca, minął – mówi Sławomir Kumka.
Jest to ewidentnie to zdanie, które wielu osobom może się nie spodobać, ale trudno je ignorować. Przez lata introwertyczny stereotyp programisty był traktowany trochę jak branżowy folklor. Ktoś siedzi sam, pisze kod, nie musi rozmawiać. Byleby dowoził na czas. Tyle że dzisiejsze systemy są zbyt złożone, żeby działać w takim modelu. Programista musi wyjaśniać decyzje, zadawać pytania, rozumieć wymagania, bronić rozwiązań i przyjmować krytykę.
Czytaj też: Sensowna sztuczna inteligencja dla każdego? NVIDIA zrobiła właśnie coś, na co czekałem od dawna
Co więcej, nie chodzi o rozmowę dla samej rozmowy. Kumka podkreśla, że ważna jest polemika dotycząca idei zawodowych, czyli niebranie wszystkiego w ciemno tylko dlatego, że ktoś tak powiedział. Dla młodych ludzi to może być dobra wiadomość. Staż nie zawsze bowiem oznacza najgłębszą wiedzę o każdej nowej technologii. Senior może lepiej rozumieć system jako całość, ale junior bywa punktowo mocniejszy w świeżym narzędziu, języku albo podejściu. W zdrowej organizacji taka wiedza powinna mieć prawo wybrzmieć.
Junior może mieć rację. Musi tylko umieć ją obronić
Ten fragment rozmowy szczególnie mi się spodobał, bo dotyka czegoś, o czym w IT mówi się dosyć rzadko. Nie bez powodu przecież stopniuje się stanowiska na standardowe “junior, mid i senior”.
Bardzo często przy zmianie technologii okazuje się, że juniorzy mają głębszą wiedzę o nowych technologiach niż seniorzy. Seniorzy rozumieją systemy i technologie szerzej, ale zdarzają się przypadki, kiedy osoby przychodzące na stanowiska juniorskie są punktowo na równi albo nawet bardziej zaawansowane od naszych specjalistów – mówi Kumka.
To oczywiście nie znaczy, że młodszy pracownik automatycznie wie lepiej. Oznacza jednak, że nie powinien być tylko cichym wykonawcą poleceń od przełożonych. Jeśli widzi problem, ma argumenty i potrafi je przedstawić, jego głos może być wartością dla zespołu. W świecie, w którym technologie zmieniają się szybciej niż hierarchie, autorytet wynikający wyłącznie ze stażu będzie coraz słabszy.
Czytaj też: Zrobili darmowe narzędzie, które zawstydza całą branżę. Sztuczna inteligencja może być “dobra”
Kumka mówi wprost, że możliwość zakwestionowania seniora może być oceniana pozytywnie, jeśli wynika z otwartości na krytykę i umiejętności obrony opinii. Jest to o tyle ważne, że przyszły programista nie powinien uczyć się jedynie składni. Powinien uczyć się także rozmowy technicznej i tego, jak powiedzieć “nie zgadzam się”, jak uzasadnić pomysł, jak przyjąć kontrargument i jak zmienić zdanie, kiedy druga strona ma rację. Wbrew pozorom to też jest umiejętność inżynierska, bo dobry kompleksowy system rzadko powstaje z pierwszego pomysłu jednej osoby. Powstaje z tarcia między wymaganiami, ograniczeniami, doświadczeniem i świeżą perspektywą.
AI rozleniwia tych programistów, którzy chcą iść na skróty
W rozmowie z Kumką pojawił się też wątek, który warto potraktować jako ostrzeżenie. Sztuczna inteligencja potrafi przyspieszać naukę, ale potrafi też ją blokować, jeśli ktoś używa jej jak automatu do omijania wysiłku.
AI oczywiście może rozleniwiać. To de facto blokuje naukę. Ludzie myślą, że w łatwy sposób dostaną to, czego potrzebują, i nie muszą włożyć w to żadnego wysiłku – mówi Sławomir Kumka.
Mam wrażenie, że to zdanie powinno zawisnąć nad biurkiem każdej osoby uczącej się programowania z pomocą modeli językowych. Bo pokusa jest ogromna. Zamiast walczyć z błędem, można wkleić komunikat do modelu i po kilku minutach dostać rozwiązanie. Zamiast zrozumieć strukturę projektu, można poprosić o gotowe rozwiązanie, które będzie wprawdzie działać, ale nie będzie najlepiej zintegrowane z resztą. Zamiast napisać funkcję samemu, można wygenerować ją i przejść dalej. Problem w tym, że takie “dalej” bywa pozorne.
Kumka puentuje to jeszcze ostrzej.
Jeżeli programista jest leniwy i oczekuje, że system rozwiąże problem za niego, to bardzo szybko może się okazać, że ten system jest lepszy niż on i w ogóle nie będzie go już potrzebował – dodaje.
Właśnie tu leży praktyczna prawda o AI. Model nie zabiera wartości komuś, kto rozumie system, potrafi ocenić odpowiedź, poprawić ją i wziąć odpowiedzialność za wynik. Najbardziej zagraża temu, kto próbuje używać go jako zamiennika myślenia.
Kim więc musi być programista w dzisiejszych czasach?
Dzisiejszy programista nie musi znać wszystkiego. To nawet niemożliwe. Musi jednak mieć fundamenty, rozumieć systemy, być gotowy do ciągłej nauki, potrafić zadawać precyzyjne pytania i nie bać się rozmowy o własnych pomysłach.
Musi też umieć pracować z AI bez oddawania jej odpowiedzialności, a to subtelna, ale bardzo ważna różnica. AI może tłumaczyć, prowadzić po kodzie, przyspieszać onboarding, wskazywać trendy, pomagać w analizie i zmniejszać tarcie w codziennej pracy. Nie może jednak zastąpić rozumienia. Jeżeli młody człowiek potraktuje ją jak nauczyciela i sparingpartnera, może rozwijać się szybciej niż poprzednie pokolenia. Jeśli potraktuje ją jak sposób na prześlizgnięcie się przez podstawy, to szybko uderzy w ścianę.
Dla mnie to dobra i zła wiadomość jednocześnie. Zła, bo romantyczna opowieść o szybkim kursie i natychmiastowej pracy w IT jest już kompletnie nieaktualna bez wiedzy. Jednocześnie jest też dobra, bo programowanie wbrew pozorom nie zamyka się przed młodymi. Po prostu znów zaczyna wymagać tego, co zawsze powinno być w centrum: myślenia, fundamentów, ciekawości i odpowiedzialności za własny kod.
