Gdybym wcześniej poznał Lindy Effect, to inaczej bym zaplanował swoją karierą i rozwój w IT. Nie wybrałbym innej ścieżki, ale inaczej stawiał bym na niej kroki - bardziej świadomie.

Kto lub co to jest ten Lindy?

Jak każda dobra historia, ta też musi zacząć się od jakiegoś ciekawego miejsca - a kto nie lubi dobrej kawiarnio-cukierni? Lindy wzięło się od nazwy nowojorskiej knajpki (Lindy’s Cheesecake Deli), gdzie spotykali się komicy i producenci filmowi. Rozmawiając nad filiżanką kawy i kawałkiem sernika, zaobserwowali pewną zależność: im większa początkowa popularność wykonawcy, tym krócej trwała jego kariera. Trochę tak, jakby dość szybko kończyło mu się paliwo i potencjał, aby utrzymywać się na topie. Na podstawie tego spostrzeżenia Albert Goldman, pisarz i biografista, opracował regułę zwaną Lindy Effect.

Benoît Mandelbrot, jak na matematyka przystało, przekształcił tę regułę kciuka w rygorystyczny model matematyczny oparty na rozkładach potęgowych. Dla przypomnienia, to ten wykres, który wskazuje że im wyższa wartość tym mniej badanych ją spełnia - jak w społeczeństwie - wiele ludzi ciężko pracuje, ale niewielu z nich dorobiło się naprawde dużych pieniedzy. Mało kto czyta do poduszki podręczniki i tablice matematyczne, więc Nassim Taleb, ekonomista-filozof, w swojej książce „Antykruchość”, przystępnie opisał i spopularyzował tezę udowodnioną wcześniej przez Mandelbrota.

Dla Goldmana Lindy Effect, było narzędziem do pokazywania, że popularność jest zasobem i może się wyczerpać. Biografie, które pisał, miały pokazywać to u ówczesnych, największych ikon muzyki. Natomiast Taleb wyewoluował tę regułę odwracając jej logikę. Pisał, że im dłużej już coś trwa, to ma większe szanse trwać dalej. Na przykład książka, która jest czytana od 50 lat, ma dużo większe szanse, być czytana przez kolejnych 50 lat, niż świeży bestseller. Te teorie nie są ze sobą sprzeczne, ale mają inny kąt natarcia na bardzo podobne wnioski. Goldman skupiał się na człowieku, który się męczy i nudzi, a Taleb na rzeczy lub idei, która nie ulega biologicznym procesom starzenia się, a jedynie przechodzi próbę czasu.

Nieintuicyjna reguła

Na pierwszy rzut oka wydawałoby się, że jak coś już istnieje wystarczająco długo, to przyjdzie taki dzień, że będzie musiało odejść. Jednak biorąc za przykład nasze podstawowe narzędzia, takie jak młotek, widelec czy łopata, to ciężko jest nam sobie wyobrazić, że ktoś stworzy coś innowacyjnego, co je zastąpi. Ich funkcjonalność jest jednoznaczna i wystarczająca, żeby w jakikolwiek sposób ją usprawniać - no chyba, że pomalować je na czerwono - bo wiadomo, czerwone szybciej kopie i szybciej wbija gwoździe.

Na kolejny przykład weźmy pokrętła i przyciski w samochodzie. Zaraz po 2020 roku, kiedy wybierałem nowe auto, zaskoczyło mnie, że niektóre z popularnych marek zrezygnowały z nich do sterowania klimatyzacją i głośnością muzyki. Nowoczesność - gdzie się człowiek nie obejrzy dotykowe ekrany. Tylko, że z tym rozwiązaniem jest podstawowy problem: nie patrząc na ekran ciężko jest go użyć, bo nie czujemy pod palcami żadnych przycisków zanim je wciśniemy. Zapytałem się więc sprzedawcy, czy to oznacza, że za każdym razem jak będę chciał coś zmienić, to muszę spojrzeć na ekran zamiast na drogę? Ku mojemu rozczarowaniu potwierdził (i swojemu chyba też, bo na przekonanego do tego pomysłu nie wyglądał). W 2025 roku w kilku markach nastąpił powrót do antykruchych, fizycznych elementów sterujących, do których tak bardzo jesteśmy przyzwyczajeni. Takie rozwiązanie okazało się Lindy Proof - sprawdzone w bojach, intuicyjne i bezpieczniejsze, bo łatwiej obsłużyć przycisk i pokrętło na nierównościach, a uwaga i wzrok pozostają skupione na drodze. Co więcej, to rozwiązanie istnieje w samochodach odpowiednio długo, że zgodnie z przyjęta zasadą, ma szansę przetrwać kolejnych 100 lat!

Lindy Effect działa przy założeniu, że nastąpił przełom, który zmienia sposób działania lub wręcz umożliwia daną czynność. Gdyby nie wynalezienie silnika spalinowego, to dziś, zamiast tapicerki i koni mechanicznych, wybieralibyśmy kolor siodła i badali drzewo genealogiczne naszego rumaka, aby upewnić się, że jest dość żwawy i nie będzie “rdzewiał” za szybko. Gdyby nie rozwój sieci komórkowej, to wciąż z zaciśniętymi kciukami wybieralibyśmy numer telefonu licząc, że rozmówca jest aktualnie w zasięgu swojego telefonu stacjonarnego. Chodzenie po ulicy z dużą ilością gotówki, na drogi zakup w sklepie, bywało ryzykowne i nieporęczne. W dobie globalizacji, płacenie fizyczną walutą za zakupy on-line, robione często na drugim końcu globu, byłoby co najmniej niewygodne i czasochłonne. Cyfrowy zapis transakcji i pieniądza musiał prędzej czy później stać się codziennością, aby cały proces działał sprawnie i bezpiecznie.

To często wynalezienie nowej przełomowej technologii jest głównym powodem upadania antykruchych rozwiązań, gdyż wpływa na podstawę działania aktualnego rozwiązania. To jakiś wynalazek, który rozwiązuje ten sam problem, ale wygodniej, ekonomiczniej lub szybciej. No bo kto spodziewałby się w 1880 roku, że transport konny, praktykowany już co najmniej od 4000 lat, nie przetrwa kolejnych tysiącleci? Domyślam się też, że kilkadziesiąt lat temu, większość posiadaczy tomów Britannica, nie wyobrażało sobie takiego powszechnego dostępu do wiedzy, jaką zapewnia nam dziś Internet. To wszystko tak jak i sekstant, dzisiaj głównie spotkany w krzyżówkach i muzeach, staje się mniej wygodnym, hobbystycznym lub awaryjnym sposobem działania. Tak, są rozwiązania zdecydowanie bardziej Lindy - mniej zawodne, sprawdzone w bojach i niezależne od innych czynników, takich jak prąd czy zasięg sieci, ale ich popularność “pokruszyła się” na rzecz nowoczesności lub zmiany podstawowego sposobu podejścia do danego tematu.

Lindy Proof w IT

Ciężko porównywać tutaj samo IT do rozwiązań, które przetrwały kilkadziesiąt pokoleń. Za początek układu odniesienia dla IT-Lindy, umownie uznajmy 1945 rok, czyli powstanie pierwszego powszechnie znanego, w pełni elektronicznego komputera ogólnego przeznaczenia, ENIAC. To nie jest długi okres, to nawet nie jest jeden wiek, jednak, na szczęście, Lyndy Effect można liczyć prawem potęgowym, co wykazał Mandelbrot, a to w uproszczeniu oznacza, że tych samych wniosków można spodziewać się w dowolnej skali odniesienia, nawet dużo mniejszej.

Pomijając “starożytną” historię komputerów, przenieśmy się do lat 70. XX wieku. Wtedy to Dennis Ritchie, ułożył życie programistom na kolejne dekady, tworząc jeden z najbardziej IT-Lindy-Proof bytów - język programowania C. Ramię w ramię z językiem bazodanowym SQL (we wszystkich jego smakach i kolorach), przetrwali popularyzację PC, wprowadzenie interfejsów graficznych, rewolucję mobilną, Cloud Computing i niezłomnie weszli w kolejną erę oraz kolejne zmiany, które dyktuje dzisiaj AI. Język C, po ponad 50 latach istnienia, jest fundamentem znanego nam dzisiaj świata cyfrowego, chociażby jako Kernel Linuxa, czyli najbardziej podstawowe oprogramowanie systemu, dzięki któremu działa prawie każdy serwer w sieci. Każdy miał z nim jakąś styczność, chyba że na codzień do pracy dojeżdża dorożką, nie używa smartfona i żyje 100% off-line.

Każdy programista zna co najmniej jeden język z “dynastii C” lub jego obiektowego następcy C++, bo stoją one u podstaw większości aktualnie dostępnych na rynku rozwiązań. Dla jednych języków, to środowisko uruchomieniowe lub interpreter, innym towarzyszył na początku ich powstania, a jeszcze inne języki wżeniły się w rodzinę, przyjmując składnię C za wzór do naśladowania. Przez dekady żadne inne narzędzie nie oferowało takiego balansu między wydajnością a przenośnością między procesorami i ich architekturą. Pierwszą rzeczą jaką implementuje się w większości nowych chipów, to właśnie obsługa języka C. Jest on swoistym lingua franca do komunikacji między fizycznymi podzespołami komputera. Aktualnym pretendentem do tronu, lub przynajmniej części królestwa, jest Rust. Jednak C, ma nad nim 50 lat przewagi rynkowej i z dużym prawdopodobieństwem go przeżyje. Wprowadzenie procesorów kwantowych (QPU) również nie zapowiada osłabienia jego dominacji, gdyż pomimo przełomowości, nie zmieniają paradygmatu podstawowych operacji logicznych potrzebnych do działania systemu. Przewiduje się, że prędzej będą działać we współpracy z klasycznymi procesorami (CPU) jako ich akceleratory obliczeń - więc i tu łatwo możemy się domyślić, co najprawdopodobniej posłuży do komunikacji między tymi jednostkami.

Język C dzięki swojej dostępności, szybkości i uniwersalności działania, reprezentuje te cechy trwałości, które w świecie IT są najbardziej pożądane. Nie jest, ani najnowocześniejszy, ani najgłośniej komentowany. On po prostu działa, spełnia swoją rolę i jest w tym wszystkim wręcz nudny. Nie musi niczego udowadniać i nigdzie się nie spieszy, bo czas w jego przypadku działa na korzyść - coraz bardziej go utrwalając.

Co jest Lindy Proof w pracy programisty?

Możliwe, że runie zaraz jeden z mitów, ale praca programisty nie składa się tylko z cyklu: eat - sleep - code - repeat. Zanim faktycznie zacznie się układanie algorytmów i wpisywanie instrukcji, potrzebna jest analiza i doprecyzowanie wymagań, które zajmuje nawet do 25% czasu. Weryfikacja, testowanie, debugowanie, poprawki i tworzenie dokumentacji do powstałego oprogramowania, to kolejne 30% czasu. Do tego około 10% na prezentacje efektów, synchronizacje i planowanie zadań. Na samo pisanie kodu programista zazwyczaj poświęca nie więcej niż 40% swojej pracy. Te wartości nie sumują się od razu do 100%, bo to statystycznie maksymalne czasy jakie są poświęcany na dane czynności, a ich proporcje zmieniają się w zależności od etapu projektu, doświadczenia zespołu, wieku samej aplikacji i kilku jeszcze innych czynników. Patrząc na te liczby rysujemy pewien obrazek dający poczucie, jak ten czas się rozkłada.

W ramach tych bloków czasowych, wykonywane są działania przy użyciu konkretnych narzędzi i frameworków, z których jedne są chwilową modą, a inne przechodzą próbę czasu trafiając do kanonu pracy, ponad podziałami na firmy, projekty czy zespoły. To trochę tak jakby porównywać, dowolny muzyczny hit jednego lata, do nieśmiertelnego świątecznego klasyka, który zanuci praktycznie każdy, bez znaczenia jakiej muzyki słucha na co dzień. Pomimo zmiany nuty wybrzmiewającej z głośnika i narzędzi, które używamy do pracy, robotę trzeba wykonać i to najlepiej bez zaniedbania żadnego z wymienionych etapów. Jak nie przeanalizujemy, to nie będziemy wiedzieć co jest do zrobienia; jak nie przetestujemy wystarczająco, to będziemy poprawiać błędy; a jak nie napiszemy dokumentacji, to zostanie nam w głowach tylko, tak zwana “wiedza plemienna” i jak po czasie nam się z tego co nieco ulotni, to pominiemy jakiś szczegół i niedoszacujemy się z planowaniem kolejnych zadań.

Sprzęt i oprogramowanie też jest bardzo zmienne. Między 2000 a 2026 rokiem, wydano 9 wersji Windowsa, 11 głównych wersji Ubuntu i 22 wersje systemu MacOS. Co kilka lat zmieniają się najpopularniejsze narzędzia wspierające pracę programisty, Zintegrowane Środowiska Developerskie (z ang. IDE). Co kilka miesięcy, a czasem nawet kilka tygodni powstają nowe gotowe biblioteki kodu, z których funkcji korzystają programiści, aby zbudować większe fragmenty oprogramowania. Jak ktoś nie jest z tym na bieżąco, to dość szybko może wypaść z obiegu. Jakkolwiek, procesor w komputerze nie zwraca uwagi czy wykonuje kod napisany w notatniku na Windowsie, czy w IDE za $100 rocznie na Macu M4 o kolorze Space Gray.

Podsumowując, najbardziej Lindy Proof w pracy programisty nie jest bezpośrednia znajomość narzędzi pracy, ale umiejętność adaptacji, szacowania ryzyka i wyceny pracochłonności zadań. Ważne są też wzorce projektowe, architektura, metodologia testowania oprogramowania i umiejętność pisania kodu zrozumiałego dla innych programistów. Można by się też wspierać ogłoszeniami o pracę i wymienić popularną w nich umiejętność współpracy w “młodym dynamicznym zespole” i “zarządzania czasem”, ale nie są to unikalne umiejętności dla branży IT (ani przez kogokolwiek traktowane serio).

Przykład przemijającej mody w zarządzaniu IT.

Moim faworytem w tym przypadku jest Scrum. W skali IT-Lindy przeszedł on długą drogę: od pierwszego inspirującego artykułu w Harvard Business Review (1986 r.); pierwszą próbę sformalizowania ram postępowania (1995 r.); spisania Manifestu Zwinnego Wytwarzania Oprogramowania - Agile Manifesto (2001 r.), aż w końcu po wydanie Przewodnika po Scrumie - Scrum Guide i popularyzację na szeroką skalę (2010 r.).. Hype i ilość marketingu jakim obsypano wówczas metodyki zwinne, były nie do przejedzenia. Ubierano to w kolejne, lekko zmienione, odmiany frameworków i reklamowano jako nowoczesne podejście, które rozwiązuje wszystkie problemy zarządzania zespołem i projektami. Według niektórych, wystarczyło je tylko “wypakować z pudełka” i od razu cieszyć się efektami. W rzeczywistości nie było ani łatwo, ani zwinnie.

Scrum rósł na popularności w bardzo szybkim tempie. Jedną ręką rozwiązywał wiele bolączek, a drugą dopisywał więcej pytań niż dawał odpowiedzi. Jako że u podstaw metodyk zwinnych leży otwartość na samodzielną interpretację wszelkich wskazówek, to jego świeżo upieczeni ewangeliści zgrabnie dostosowywali pod swoje osobiste narracje hasła ze Scrum Guide’a i z Agile Manifesto. Tak oto naprzeciw siebie stanęli zawodnicy: “ledwo sprawdzony świeżak” oraz wielki jak góra: “feudalno-folwarczno-cechowy, system organizacji gospodarczo-społecznej”. Jeden z nich był IT-Lindy-Proof, a drugi po prostu Lindy-Proof (i to jeszcze w skali liczonej od średniowiecza).

Zespoły developerskie po czasie przekonały się do metodyk zwinnych, bo dobrze zadziałała w nich, zalecana przez Scrum, samoorganizacja, wspólna odpowiedzialność za wynik i iteracyjna praca. W bardziej ortodoksyjnych rozdaniach, zespoły nie miały już nawet jednego szefa, który rozdziela zadania, a sami specjaliści między sobą podejmowali decyzje, kto czym się zajmie, aby praca była dostarczona na czas i w wysokiej jakości. Od teraz każdy miał głos w każdej sprawie, a nad jakością samego procesu i facylitacją spotkań czuwali Scrum Masterzy. Woda płynęła - młyn się kręcił. Można uznać, że lepiej lub gorzej posmarowano bolące miejsca po wcześniejszej strukturze zarządzania i podejściu do prowadzenia projektów.

Top Management pozostał bardziej odporny na “zwinne” uroki, bo dalej rozliczał się z akcjonariuszami planami 4-letnimi i terminami raportów giełdowych. Wielu z nich, robiąc rachunek sumienia, nie wpisałoby na listę grzechów niechęci do zmian, bo w ich odczuciu poprzedni układ musiał działać i tyle. Niektórzy “mistrzowie cechów”, czyli najstarsi Seniorzy i Architekci, też początkowo podchodzili niemrawo do zmian. W ich oczach “młody” (Junior Developer) najlepiej jakby się przygląda, uczył, a przede wszystkim słuchał i nie wychylał za bardzo. Każdy z opornych miał już sprawdzony i wyrobiony przez lata praktyki sposób pracy. Jako że nie wszyscy byli gotowi i otwarci na zmiany, to spójna płaszczyzna porozumienia rozwarstwiła się, pozostawiając punkt tarcia na poziomie kadry zarządzania średniego szczebla.

W każdej firmie podejście do Scrum-a ewoluowało trochę inaczej, aż takie implementacje nazwano żartobliwie: ScrumBut (z ang. “Scrum, ale…”). Jedni mówią, że zawsze brano tylko to, co najlepsze z obu światów, a inni widzieli w tym próbę “posiadania ciastka i zjedzenia ciastka” - ważne, że nikt się nie czepiał, bo i było “agile”, i był dowieziony plan roczny.

Co tu jest Lindy Proof? Gdy trwający przez ponad dekadę początkowy entuzjazm nad Scrumem, już trochę opadł, pozostawił po sobie kilka sprawdzonych w bojach metodyk. Jeżeli są prawidłowo zaimplementowane i używane, służą dziś za wartościowe narzędzia dla zespołów deweloperskich. Przykładowo: regularne spotkania, w celu ciągłego usprawniania procesu wytwarzania; metody wskazywania niepewności, zanim przystąpi się do wytwarzania; efektywnie synchronizująca pracę między dużą liczbą zespołów. To, co było najbardziej dyskutowane i zmieniające nawyki, to dzielenie większych projektów na mniejsze, stałe odcinki, które umożliwiają systematyczne wprowadzanie poprawek i zmian decyzji, zanim finalny efekt trafi do klienta końcowego. Jest to bardzo korzystne, bo przy tak szybko zmieniającej się rzeczywistości, na końcu dostajemy to, co jest potrzebne tu i teraz, a nie to, co było potrzebne na starcie inicjatywy, kilka miesięcy wcześniej.

Po latach, w większych organizacjach, powróciła też struktura hierarchiczna i Liderzy Zespołów. Nie dla większej kontroli, ale dla ułatwienia ścieżki raportowania, rozwiązywania problemów bardziej technicznie i bezpośredniego wsparcia ludzi w rozwoju. Podejście “Lider Służebny”, jest teraz wpisane częściowo w obowiązki szefa-programisty, a nie tylko w coraz mniej spotykane stanowisko Scrum Mastera. Paradoksalnie branie tylko tego co działa i wszystkie “ale” w ScrumBut’cie, lepiej wpisały się w ideę stojącą za pierwszą z antykruchych wartości Agile Manifesto, czyli: “Ludzi i interakcje ponad procesy i narzędzia”. Kierując się intuicją opartą o Lindy Effect, możemy spodziewać się, że młodsze lub jeszcze nie powstałe frameworki przeminą, a mający 25 lat Agile Manifesto, przetrwa kolejne ćwierć wieku.

Czy AI to silnik spalinowy w erze zaprzęgów konnych?

AI nie jest taki straszny jak go malują - przełom jak każdy inny, tylko ambitniejszy i bardziej medialny, bo nie dotyczy tylko “podziemnego kręgu IT”. Żaden programista z powołaniem nie powinien się tego obawiać bardziej, niż kolejnego frameworka pracy czy zmian technologicznych zwiększających efektywność czy wachlarz dostępnych narzędzi i rozwiązań. Aktualne zmiany są szybsze, mają większy wpływ na pracę i mają potencjał jeszcze sporo namieszać w codziennych obowiązkach. Jednak programista z 10-15 letnim stażem, przeżył już tak wiele “rewolucji”, że przy podejściu ze strachem, mógłby stracić wszystkie włosy szybciej, niż dziecko bawiące się maszynką do strzyżenia.

To, co napędza strach, to przede wszystkim pokłosie kilkuletniej polityki zatrudnień firm z sektora IT. Doprowadziła ona do zatrudnienia bardzo dużej ilość osób znających ledwo podstawy programowania, a czasem nawet tylko odtwórczo. Takie umiejętności mogły wystarczyć tuż przed i w samych okolicach Covid’owego lock-down, by rozgościć się w szeregach specjalistów IT. Wtedy wystarczył kilkudniowy program szkoleniowy (Bootcamp) i wysłanie kilku CV - dzisiaj, umiejętności juniorów weryfikowane są bardziej skrupulatnie. Sprawdzane jest też, jaki progres przez ostatnie lata poczynili specjaliści i czy ich aktualny poziom jest adekwatny do obecnych zmian w branży. To prawdziwy egzamin z podstawowych cech dobrego programisty: myślenia przyczynowo-skutkowego, elastyczności i zdolności adaptacji, uporu w dążeniu do celu oraz radzenia sobie z frustracją wynikającą z jeszcze nie działającego kodu i nieustających zmian.

Duża część pracy programisty, to nie tylko rozwiązywanie problemów czy optymalizacja działania algorytmów, ale też pisania kodu w taki sposób, aby był łatwy do późniejszych modyfikacji i pozostawał czytelny dla innych. Istnieje bardzo dobrze znany akronim S.O.L.I.D, który wskazuje na 5 kluczowych zasad projektowania obiektowego, czytelnego, elastycznego i łatwego w utrzymaniu kodu. Czy to traci dzisiaj sens? Czy programiści nie będą musieli już zwracać na to uwagi? Wprost przeciwnie! Skoro dzisiaj, przy pomocy AI, jesteśmy w stanie w tym samym czasie wyprodukować statystycznie o 55% więcej kodu, to nigdy bardziej niż teraz, potrzebujemy porządku i czytelności. Co więcej, mniej czytelnego kodu, to tylko przepis na porażkę. Deweloperzy i LLM’y pracujący z kodem, aby spełnić oczekiwania biznesowe, muszą przecież rozumieć jak działa aplikacja, jeżeli mają ją utrzymywać i dalej rozbudowywać. AI nie zmienia samego celu programowania, którym przecież tak naprawdę jest przekładanie oczekiwań na działającą aplikację.

Programiści przechodzą od żmudnego wpisywanie poleceń dla komputera w postaci kodu, do instruowania niedeterministycznych modeli językowych (które przejmują tę rolę jako Agenci Kodowania). Przenoszą część swojej uwagi z “jak napisać efektywny kod”, do “jak napisać efektywny prompt, który napisze kod”. Specjaliści na co dzień wciąż rozwiązują problemy znane od lat, a dodatkowo jeszcze, te związane z kosztami i ilością danych, jaką musi skonsumować AI. Nie jest to darmowa usługa i wymaga nowych, konkretnych umiejętności, aby ją efektywnie wykorzystać. Ilość wysłanych do AI i wyprodukowanych przez nią treści jest liczona w tak zwanych tokenach - w podstawowej jednostce miary rozliczeniowej, którą posługują się firmy dostarczające modele oraz moc obliczeniową do ich działania. Wiadomo, mniej zużytych tokenów, to taniej wyprodukowane rozwiązanie. Jednak to również nie zmienia drastycznie nawyków dobrych programistów, gdyż zawsze posiadanie za dużej ilości, nieefektywnie napisanego kodu, było złe. Ktoś przecież musiał poświęcić cenny czas na jego przeczytanie, zrozumienie i utrzymanie - dzisiaj, ten koszt jest po prostu inaczej wyrażony.

Od początku przyjętej skali IT-Lindy, programiści kilkukrotnie przechodzili na wyższy poziom abstrakcji pisania kodu. Najpierw, zaczynali od programowania rejestru po rejestrze bezpośrednio w pamięci RAM. Później, przeszli przez coraz bardziej upraszczające pracę, wysokopoziomowo języki programowania. Aż doszli do momentu, w którym konstruują “algorytmy, piszące algorytmy”. Jednak paradygmat się nie zmienił. Ktoś musi w opłacalny sposób przerobić oczekiwania klienta, na działający zgodnie z nimi produkt. Niejeden wizjoner mógłby powiedzieć, że każdy może już dzisiaj napisać aplikację przy użyciu AI. Jednak na początku popularności Internetu, też każdy mógł stworzyć samodzielnie stronę WEB i umieścić ją w sieci - jednak niewielu się na to zdecydowało. Programiści byli wtedy, i teraz też będą potrzebni, chociażby po to, aby zweryfikować “dzieło” wyprodukowane przez AI, zaprojektować “lepsze AI” lub ułożyć efektywniejsze i tańsze metody współpracy z istniejącymi “narzędziami AI”.

Co dalej? W co inwestować w nowej erze?

Niezależnie od zmian jakie zachodzą w IT, praktyczna znajomość samego paradygmatu programowania zapewni programiście “antykruchość” w branży. Najbardziej IT-Lindy-Proof pozostaną jeszcze przez długie lata: fundamenty programowania, znajomość logiki oraz umiejętność budowania i rozwoju algorytmów. Nie obejdzie się też bez znajomości co najmniej jednego języka z rodziny C. Dalej rozwijana będzie dziedzina automatyzacji pisania kodu na polecenie programisty, a samych narzędzi będzie coraz więcej i będą coraz łatwiej dostępne. Jako że to dość młody i ekscytujący obszar, to niektóre z rozwiązań będą biły szczyty popularności, ale nawet to nie zagwarantuje im przetrwania - tu może nastąpić jeszcze wiele przetasowań. Przez dużą zmienność narzędzi, powinniśmy szybko ustandaryzować nowe uniwersalne zasadach pracy z nimi. To właśnie znajomość tych wspólnych mechanizmów i zasad, będzie najtrwalsze i uodporni specjalistów na kolejne zmiany związane z rozwojem sztucznej inteligencji.

Możemy spodziewać się, że w najbliższym czasie, firmy rozwijające AI, inwestować będą w specjalistów o bardzo wąskich dziedzinach, aby na ich głębokiej ekspertyzie oprzeć wykładniczo rozwijające się LLM’y. Z drugiej strony, wśród firm korzystających z usług tych pierwszych, coraz bardziej pożądanym “towarem” na rynku będą umiejętności z kategorii ogólnych (generalistyczne), dające możliwość działania na wszystkich warstwach wytwarzania oprogramowania. Dzięki presji na umiejętność systemowego myślenia oraz syntezy informacji z różnych dziedzin, zatrą się na powrót granice między specjalizacjami, jakimi w drugiej dekadzie tego wieku podzielono się w działach inżynieryjnych.

W działach programistycznych, przewiduje pragmatyzm i dalszy rozwój w oparciu o specjalistów dających silne fundamenty i doświadczenie. Kierując się zasadami budowania rentownego i bezpiecznego portfela inwestycyjnego (60% bezpieczniejszych aktywów i 40% mniej przewidywalnych, ale dających większą perspektywę zysku), warto będzie skupić się na dalszym rozwijaniu umiejętności IT-Lindy-Proof oraz ograniczonej, ale konsekwentnej implementacji nowoczesnych rozwiązań. One zapewnią konkurencyjność, ale to te najbardziej “antykruche” kompetencje będą jak schody, gdy trzeba wnieść kanapę na 3 piętro, w czasie awarii windy.

---

Paweł Nejczew