AI nie zabierze roboty inżynierom

Jako niegdysiejszy miłośnik horrorów z ciekawością przyglądam się grozie rozlewającej się przez socjale, gdzie niegdysiejsi eksperci od #blockChain przenieśli punkt swojej eksperckości na #AI i straszą inżynierów niczym Jason Voorhees wczasowiczów.

No więc, jak to będzie? Czy #AI zabierze robotę deweloperom i inżynierom wszelakim? Czy staną się niepotrzebni, bo oto każdy kto chce wypromptuje sobie, co tylko chce?

Pierwsze wnioski nt. narzędzi AI

W trakcie eksperymentów z różnymi narzędziami:

• przygotowałem od zera strony michalbartyzel.pl oraz itspotykaklienta.pl,
• dobór kolorów, czcionek, zdjęć, css oraz prostych skryptów JS - wszystko wykonałem za pomocą AI,
• skonfigurowałem ww. stron na CloudFlare,
• wygenerowałem skrypt dla workera CloudFlare, bo trzeba wiedzieć, że michalbartyzel.pl, michalbartyzel.pl/blog oraz kursy.michalbartyzel.pl to 3 różne usługi stojące odpowiednio na: carrd.io, blogmaker.app i dedykowanym hostingu WordPress; dzięki workerowi całość jest spięta pod michalbartyzel.pl,
• potestowałem nieco Cursor.ai.

Do powyższego dodaję lekturę przeżyć moich kontaktów LI i tego, co robią z narzędziami AI.

Główny wniosek mam taki: musisz umieć ocenić to, co produkuje dla Ciebie tool. Generując kod musisz wiedzieć na przykład:

• że w kodzie mogą być podatności, 
• że nie wszystkie wyjątki używanej biblioteki zostały obsłużone,
• jak się ma html do css,
• jak przeczytać składnię języka programowania,
• kiedy model zaczyna gadać głupoty,

Ogólnie rzecz biorąc musisz mieć jakieś pojęcie o architekturze i o możliwościach technologii, żeby wiedzieć jakie polecenie wydać narzędziu i jakiego wyniku się spodziewać.

Demokratyzacja inżynierii oprogramowania

W trakcie projektowania i pisania oprogramowania wykorzystujesz następujące sposoby rozumowania:

• indukcję, czyli wnioskowanie od szczegółu do ogółu,
• dedukcję, czyli wnioskowanie od ogółu do szczegółu,
• definiowanie, czyli precyzyjne i jednoznaczne ujmowanie pojęć,
• dekompozycję, czyli rozkładanie problemu na elementarne części,
• analizę, czyli badanie czegoś, poprzez badanie składowych tegoż,
• syntezę, czyli łączenie części w całość,
• abstrahowanie, czyli operowanie pojęciami i ideami bez przyporządkowania im rzeczywistych odpowiedników,
• myślenie systemowe, czyli ujmowanie i rozpatrywanie problemów nieredukowalnych.

I wiesz co? Metody rozumowania, które wymieniłem nie są powszechne. Powinny być, wszak to cudowne zdobycze nauki od antycznych filozofów począwszy. Jednak nie są. Stopniowe odchodzenie do uczenia metodycznego rozwiązywania problemów na rzecz chłopskiej logiki w edukacji oraz scrollowanie kilometrów social mediów tylko ten stan pogłębia.

Drugą rzeczą, która nie sprzyja umiejętności zdyscyplinowanego myślenia, jest postępująca specjalizacja kosztem nauk ogólnych. 

Większość osób dla których będziesz tworzyć oprogramowanie nigdy nie przedstawi Ci całościowego spojrzenia na problem, który ma do rozwiązania. Przeważnie będzie opowiadała o poszczególnych przypadkach: gdy zrobiłem A, to stało się B, a gdy zrobiłem E i F, stało się C i A. Dopiero Ty, jako dostawca i inżynier musisz te wszystkie informacje przeanalizować, zsyntetyzować, wyabstrahować jeśli trzeba, wrócić z wdrożonym rozwiązaniem i wystawić fakturę.

Demokratyzacja inżynierii oprogramowania dzięki AI nawet jeśli się wydarzy, to jej skutek będzie analogiczny do tego, co wydarzyło się w minionych przełomach technologicznych poczynając od: FTP, serwerów plików firmowych, maili, na chmurze, SharePoint i modelach językowych skończywszy. Skutek ten wygląda tak:

• Budżet.xlsx
• Budżet_2025.xlsx
• Budżet_backup.xls.old

Tak to już jest, że jeśli masz bałagan w procesie i wdrożysz Jirę, wciąż będziesz mieć bałagan, ale w Jirze. Jeśli masz bałagan w testach i wdrożysz X-Ray, będziesz mieć dużo droższy bałagan w X-Ray. Natury nie oszukasz.

Potrzeba mniej czy więcej inżynierów?

Wyobraź sobie, że jesteś managerem albo managerką zespołu trojga inżynierów. Jesteście dobrze poukładani z biznesem i świetnie Wam się wiedzie. W pewnym momencie, biznes zaczyna narzekać, że za wolno pracujecie. Roboty jest dużo za dużo i zespół jest mocno przeciążony.

Żeby rozwiązać problem dogadujesz się z biznesem, że dorzuci kasy na kolejne dwa etaty. Masz zatem pięcioro inżynierów. Jednak po jakimś czasie okazuje się, że znów macie za dużo roboty. Dlaczego?

Otóż dlatego, że żaden biznes nie da Ci pieniędzy na dodatkowe etaty tylko po to, żeby Twój zespół wykonywał tę samą ilość pracy. Ponieważ biznes zwiększył nakłady na pracę Twoje zespołu, naturalnie chce zlecać więcej pracy do wykonania. Dalej z zespołu powstaną dwa zespoły, trzy zespoły, departament, oddziały, wydzielona spółka. Akcjonariusze, którzy zainwestowali kasę, też chcą wzrostu rok do roku, więc dążą do skalowania się biznesu. I tak to się kręci.

AI to sok z gumi-jagód

Była kiedyś jakaś bajka gumisiach, które produkowały sok z gumi-jagód. Po wypiciu soku, gumisie potrafiły skakać jak szalone. Natomiast na ludzi sok działał inaczej. Po wypiciu soku ludzie dostawali takiego pałera, że wyrywali drzewa z korzeniami. 

AI to sok z gumi-jagód dla inżynierów, zwiększa ich produktywność i poprawia jakość wykonywanej pracy. Po lekturze poprzedniego paragrafu z pewnością już się domyślasz, co będzie efektem zwiększonej produktywności biznesu. Będzie to zwiększone zapotrzebowanie ze strony biznesu i klientów. W kapitalizmie pieniądz musi krążyć, a apetyt rośnie w miarę jedzenia. Skoro można mieć więcej w tym samym czasie, to kto by nie skorzystał?

Wnioski praktyczne

Z tej krótkiej rozkminki wyciągam kilka wniosków.

Zapotrzebowanie na deweloperów będzie rosnąć, nie spadać. Gdy już posiadacze kapitału zorientują się, że na rynku istnieją inżynierowie opojeni sokiem gumi-jagód, będą chcieli ich zatrudnić, aby stworzyć i sprzedawać produkty i usługi pomnażając przy tym zainwestowany kapitał.

Zmieni się toolbox inżyniera. Technologia zastępują technologię. Nowe paradygmaty wypierają stare. Obecnie narzędzi AI przybywa w tempie porównywalnym do niegdysiejszych bibliotek JS. Część wejdzie do toolboxa każdego inżyniera, inne będą ciekawym eksperymentem i branża o nich zapomni. Gdy już narzędzia AI rozgoszczą się w swoich niszach, staną się nową normalnością.

Raczej nie czeka nas eksponencjalny wzrost nowych apek. Można by się spodziewać, że zwiększona produktywność inżyniera zaskutkuje lawiną nowych systemów. Co prawda deweloper będzie nak**wiał kod sporo szybciej, ale ponieważ wszyscy inni również będą nak**wiać, jak szaleni, relatywnie tempo produkcji i wypuszczania nowych ficzerów ustabilizuje się.

Wzrośnie konieczność dobrej analizy. Garbage in, garbage out, mawiali starożytni. Programowanie przez promptowanie wymaga precyzyjnego określenia oczekiwanego efektu. Bez analizy ani rusz.

Powróci temat zarządzania, skalowania i usprawnia procesów. Aktualnie hasło “agile” już nie sprzedaje. Moim zdaniem jest tak z tego powodu, że poczuciu kupujących “agile” stał się dobrem powszechnym w sensie mapy Wardley’a. Postępujące zwiększanie się produktywności wymusi powrót do tych tematów.

Przesunie się próg wejścia do branży. W latach 80-tych programista musiał znać architekturę procesora i pamięci, aby cokolwiek wydusić z komputera. Potem musiał mnemoniki, potem funkcje biblioteczne, potem modelować rzeczywistość, poznać wyspecjalizowane biblioteki, narzędzia IT. Można by pomyśleć, że bariera wejścia do branży stopniowo się zmniejszała i trzeba było umieć coraz mniej, aby zostać inżynierem oprogramowania. Faktycznie jednak ta bariera ulegała przeobrażeniu, zmieniały się poziomy abstrakcji, jedne przestały być obowiązkowe, a w to miejsce powstanie sporo innych. Narzędziówka AI również przesunie próg wejścia do branży. Nie będzie łatwiej - będzie inaczej, ale też dość trudno.

Ludzie wciąż będą ludźmi i wciąż będą mieć problem z myśleniem abstrakcyjnym, indukcją, dedukcja i wszystkimi innymi metodami zdyscyplinowanego myślenia. Bez tego jednak będziesz słabym inżynierem ze świetnymi narzędziami.