Zarządzanie zespołem AI, czyli przyszłość programisty

Znasz tego mema, o tym, że AI zastąpi programistów kiedy klienci będą wiedzieli, czego chcą, więc jesteśmy bezpieczni? Pewnie, że tak! Opowiadacie go sobie w zespole za każdym razem, kiedy ktoś podrzuci link do artykułu o AI i programistach.
To teraz odpowiedz mi, tylko szczerze, na drugie pytanie – kiedy ostatnio ustalałeś coś z klientem? Wyciągałeś od niego informacje? Omawiałeś wymagania? Projektowałeś dla niego plan rozwiązania?
Oh, akurat tak się złożyło, że też przy innych okazjach powtarzasz, że nie po to szedłeś na informatykę, żeby rozmawiać z ludźmi? Ajajaj. Szkoda.

Zobacz w takim razie, jakie są moje przewidywania w temacie konfrontacji programistów i AI.

Psst, wolisz oglądać niż czytać? Treść tego artykułu dostępna jest też w formie wideo: https://youtu.be/SWEf12VQbS4

Bo widzisz, to co obserwuję i testuję od dłuższego czasu, daje mi dosyć mocne sygnały mówiące o tym, że sztuczna inteligencja zastąpi w dużej części programistów. A przede wszystkim zastąpi tych, którzy są TYLKO programistami, a raczej osobami piszącymi po prostu kod.

Bo kod jest najprostszym elementem w całym procesie wytwarzania oprogramowania. A już na pewno najprostszym do zastąpienia elementem, bo jest logiczny, opiera się na jasno zdefiniowanych regułach i wzorcach. W razie potrzeby można też bardzo łatwo jeden język programowania zastąpić innym. Albo w ogóle pisać wprost w kodzie maszynowym. Także bardzo łatwo jest go oprzeć o statystykę i budować na bazie innych fragmentów kodu i zdefiniowanych. Jest to idealne zadanie dla AI, które właśnie bazuje na statystyce i kwantyfikowalnych regułach.

To co jest faktycznie trudne i czego dotyczy też wspomniany na początku żart, to kwestia ustalania CO ma być zrobione. Szukanie oczekiwanych rezultatów.
Bo w przeciwieństwie do kodu, biznes i otoczenie biznesowe, zmieniają się na podstawie bardzo wielu, często nieprecyzyjnych, wręcz całkowicie subiektywnych wskaźników.
Z resztą, stąd też wynikają wszelkiego rodzaju niekończące się przepychanki między programistami, a klientami. Bo z uwagi na to, że nierzadko trudno jest „na sucho” przewidzieć jak zareaguje rynek na nasze decyzje, klient potrzebuje przetestować swój pomysł, ale też przetestować inne rozwiązania, które być może zażrą lepiej. I programista się frustruje. Oczekuje jasno zdefiniowanych warunków początkowych i, co istotne, jasno zdefiniowanych warunków końcowych. I każdą zmianę decyzji odbiera jako atak na swoją wolność i zdrowie psychiczne.

Także faktycznie, z perspektywy programistów, klienci nie wiedzą czego chcą. Tylko, że to oznacza, że z całej naszej projektowej zabawy, tylko ten element będzie wymagał współpracy i wspólnego poprowadzenia w przypadku powstania sztucznej inteligencji, która będzie sprawnie generowała kod na podstawie zdefiniowanych wytycznych.

Co teraz?

Trzeba sobie w takim razie zadać pytanie – co teraz? Co nas czeka?
Moje przewidywanie jest takie, że dużo większą rolę będą odgrywały interakcje między zespołem dostarczającym oprogramowanie, a klientem.
Moim zdaniem deweloperzy będą najczęściej migrowali do roli Project Ownerów. Uwaga – nie chodzi o znanych Ci PRODUCT OWNERÓW.
Pod tym pojęciem rozumiem osoby, które zajmują się ustalaniem potrzeb klienta, dobieraniem pasującej architektury i dopilnowaniem, żeby to, co powstanie z dostępnych narzędzi, spełniało ustalone wcześniej potrzeby. Będą to osoby, na których bezpośrednio wisieć będzie odpowiedzialność za dostarczenie gotowego rozwiązania. Dokładnie w takim stopniu jak na programistach wisi odpowiedzialność za kod, który napisali.

Zauważ, że już teraz coraz wyraźniej przechodzimy w kierunku wykorzystania gotowych komponentów. Chociażby budując rozwiązania oparte o chmurę, nieraz bierzemy gotowe klocki, które wpinamy tylko do naszego projektu.
Dodatkowo, budując modularne aplikacje, niejako już definiujemy mniejsze fragmenty, z których składa się projekt. Każdy z modułów, czy to w postaci modułu w aplikacji monolitycznej, czy to w postaci niezależnego serwisu w przypadku aplikacji rozproszonej, ma zdefiniowane swoje publiczne API i kontrakty, które określają sposób komunikacji z tym modułem.

Definiowaniem kontraktów i podziałem na moduły zajmują się w dużej mierze architekci albo doświadczeni deweloperzy. Tylko obecnie, to co zaprojektują, jest wypełniane przez pozostałych programistów w zespole. Jednak, jeżeli te definicje modułów będą wykonane poprawnie, co stoi na przeszkodzie, żeby dla warunków początkowych i końcowych, wypełnił nam te klocki kodem automat, korzystający z AI?
Możesz powiedzieć, że taki kod będzie pewnie niskiej jakości, nie będzie pokrywał wszystkich warunków brzegowych, albo będzie trudny w utrzymaniu. Jednak czy to będzie problemem? Skoro AI może wygenerować nowy kod w ciągu kilku minut, to równie dobrze, po każdej zmianie wymagań, wnętrze metody może być generowanie od nowa. Wystarczy, że wiemy jakie jest wejście, wyjście i na jakich już istniejących danych mamy bazować, żeby ich nie zepsuć.

Koniec juniorów?

Czy to oznacza koniec pracy dla junior deweloperów? Niekoniecznie. Ale na pewno dla nich najmocniej zmienią się wymagania. Osoby doświadczone, na wysokich stanowiskach technicznych, i tak często zajmują się już dużo bardziej projektowymi, albo architektonicznymi zagadnieniami. Więc pewnie część z nich nie będzie musiała praktycznie w ogóle zmieniać swoich codziennych obowiązków. Zmieni się jedynie samo wykonanie na samym końcu. Jednak dla mniej doświadczonych, którzy teraz są odpowiedzialni jedynie za generowanie kodu na podstawie wymagań (a nie ukrywajmy, że tak to właśnie wygląda), zmiana będzie ogromna. Sądzę wręcz, że na porządku dziennym będą takie stanowiska jak junior architekt, albo junior project owner. Praktycznie od pierwszego dnia będzie wymagana umiejętność wysokopoziomowego spojrzenia na projekt, praca z wymaganiami, czy rozumienie domeny problemu i myślenie projektowe.

Ale już miał nas zastąpić no-code…

Kilka lat temu swój boom przeżywały narzędzia low-code i no-code. I można powiedzieć, że boom był i minął. Jednak te narzędzia zostały i są z powodzeniem wykorzystywane. Być może na mniejszą skalę niż zakładano. Ale mimo wszystko część zadań od programistów przejęły.
Pewnie na co dzień tego nie widzisz, bo po prostu jedna czy druga firma, zamiast szukać programistów, to poszukała kogoś od narzędzi no-code, albo wyszkoliła osoby, które już w organizacji były. Więc nawet nie zobaczysz ich ogłoszeń, które by znikały.

I warto tutaj dodać dwa punkty.
Po pierwsze, teoretycznie spokojnie można dać część narzędzi no-code swoim pracownikom i skoro umieją pakiet Office na zaawansowanym poziomie, to są w stanie poukładać klocki w takim narzędziu do budowania procesów itp. Tylko że firmy nie lubią musieć same testować i dobierać rozwiązań, a poza tym, chcą móc zrzucić odpowiedzialność na jasno określone podmioty, najlepiej takie, na których nie stracą, a więc na firmy zewnętrzne.
Po drugie, z narzędziami low-code/no-code, był zawsze ten problem, że jeżeli opieramy się na nich w pełni, to ostatecznie dochodzi się do momentu, gdzie zaczynają nas ograniczać. I zazwyczaj jest to moment, kiedy teoretycznie warto jednak wybrać firmę budującą software na zamówienie. Procesy poukładane w niewymagających kodu narzędziach, traktuje się wtedy jako prototypy, albo bazę pod własną aplikację.

Można więc korzystanie z no-code/low-code przedstawić na diagramie:

Biznesu nie obchodzi kod. Nawet nie chodzi o to, że nie obchodzi ich jakość kodu, o czym niedawno pisałem w swoim newsletterze (zapraszam do zapisów przez formularz obok).
Osoba czy firma, która potrzebuje software, tak naprawdę potrzebuje rozwiązania. Potrzebuje tego, co uruchomi, co zadziała i da oczekiwany rezultat, albo wykona oczekiwane zadanie. To, że piszemy w tym wszystkim kod wynika tylko z tego, że przekonaliśmy (tzn. zwykle firma, dla której pracujemy przekonała) klienta, że rozwiązanie uszyte na miarę będzie lepsze. I powyższy diagram pokazuje też, że bardzo rzadko w tej ścieżce proponowane jest rozwiązanie łączące oba elementy. Bo skoro już angażujemy zespół programistów, którzy muszą to wszystko przeanalizować to napiszmy całość po naszemu, od nowa.

Problem z no-code

Największym problemem rozwiązań opartych o gotowe komponenty jest to, że w końcu trafimy na fragment systemu, którego nie przewidzieli Twórcy rozwiązania no-code. I jeżeli taki fragment został znaleziony szybko, to prawdopodobnie firma całkowicie zrezygnuje z używania tego typu narzędzia na rzecz pisanego przez programistów oprogramowania. Jednak jeżeli problem pojawi się późno, to firma będzie musiała szybko szukać kogoś, kto dopisze brakujący fragment. Jednak zazwyczaj nie będzie to ani tanie, ani proste, bo mało programistów bawi się w dokładanie takich integracji (poza programistami PHP, gdzie jest to oczywiste, że coś się dopisuje do WordPressa czy Magento).

AI + Project Owner

Tak jak wspomniałem, biznesu nie obchodzi kod tylko gotowe rozwiązanie. Obecnie najczęściej sami muszą podejmować decyzję czy biorą firmę wdrażającą rozwiązania no-code, czy biorą firmę piszącą software rękami programistów. Przejście z jednego obszaru do drugiego nie jest takie tanie i proste.

Jednak sztuczna inteligencja jest tutaj brakującym ogniwem, które sprawnie połączy oba rozwiązania, jednocześnie nie generując większych kosztów, jak w przypadku zatrudniania mocno wyspecjalizowanych programistów, potrafiących dopisywać integracje dla konkretnych narzędzi.

Wspomniani wcześniej Project Ownerzy będą odpowiedzialni za branie odpowiedzialności za dobór narzędzi tak, żeby jak najlepiej spełnić wymagania. Prawdopodobnie będzie to połączenie dostępnych usług, narzędzi no-code i kodu generowanego przez AI, który będzie integrował dostępne narzędzia, albo będzie realizował te specyficzne przypadki biznesowe, których brakuje w gotowych rozwiązaniach. Tylko, że zamiast potrzebować kilku miesięcy na analizę i implementację, wypluje gotowy moduł, w dodatku integrujący się z dowolną kombinacją innych API, w ciągu kilku chwil.

Devin to jeszcze nie to

Parę dni temu pojawiło się w sieci nagranie demo rozwiązania o nazwie Devin. Został zaprezentowany jako „wirtualny software inżynier”, który miał potrafić pracować na wielu narzędziach równocześnie i rozumieć złożone problemy.

Jednak na razie z analizy dem wynika, że prawdopodobnie jest to bardzo mocno naciągana narracja, nastawiona głównie pod zebranie finansowania od funduszy. Nawet pojawiają się wątpliwości, czy narzędzie w ogóle robi cokolwiek z tego, co zostało pokazane.

Polecam Ci w tej kwestii analizę nagrań przygotowaną przez ekipę DevMentors:
https://www.youtube.com/watch?v=dTf5oWUk1Us

Moim zdaniem Devin akurat nie jest czyś, czego w tym momencie mamy się obawiać.

Programiści nie wyginą. Na razie.

Oczywiście nie jest tak, że nagle w ciągu paru miesięcy programiści nie będą potrzebni.

Z jednej strony będą obszary bardzo niszowe, w których AI w ogóle nie miało na czym się uczyć i nie jest w stanie, przynajmniej w najbliższym czasie, dojść do produkcyjnej sprawności. Jednak to trochę jak z szewcami. Raczej powszechnie się uważa, że szewc zrobi dużo lepsze, lepiej dopasowane pod nogę klienta buty i takie osoby nadal pracują i wykonują zlecenia. Tylko powiedz mi – kiedy ostatnio kupiłeś buty u szewca? No właśnie, jest to gigantyczna nisza. I podobnie może być z programistami budującymi całkowicie szyty na miarę software.

Drugi obszar, który przynajmniej na razie ma szansę się trzymać, to programiści, którzy zajmują się budową niezależnych, zewnętrznych mikro-usługi, z których będą korzystać narzędzia budowane przez Project Ownerów, AI i no-code. Takie mikro-SaaSy, ekstremalnie wyspecjalizowane, wręcz zawierające pojedynczy endpoint, z którym można się połączyć i wstawić jako jeden z dziesiątek klocków w gotowym produkcie.
Bo większość budowanego oprogramowania można porównać do masówki, tak jak w przypadku butów – większość jest produkowana z gotowych komponentów, niskim kosztem. Nie szkoda ich wyrzucić. I po części taki produkt będą wytwarzać Project Ownerzy z użyciem automatów – software, który spełnia swoją funkcję, ale nie musi przetrwać wielu lat żeby się zwrócić. Jest na tyle elastyczny w zmianie, tani w wytworzeniu i zastąpieniu, że wręcz można regularnie eksperymentować i co chwilę go wymieniać, bo i tak poszczególne klocki są reużywalne, albo jednorazowo wygenerowane przez AI, które ponownie, na podstawie nowych wytycznych, zrobi to w kilka minut.

Co mam zrobić?

Jeżeli jesteś teraz w sytuacji, kiedy po prostu zajmujesz się zamianą user stories na kod, to moim zdaniem warto, żebyś zainteresował się takimi tematami jak:

• Wykorzystanie AI do generowania kodu i wsparcia programowania (np. używanie narzędzia Copilot)
• Rozumienie domeny biznesowej i jej implementacja (Domain Driven Design i techniki takie jak Event Storming)
• Dostępne narzędzia low-code/no-code i jak się z nimi integruje (np. make.com)
• Tematy związane z architekturą systemów
• Rozmawianie o wymaganiach
• Cele biznesowe projektów IT
• Automatyzacja procesów

Takie są moje przewidywania i przemyślenia. Ty podziel się swoimi w komentarzu, a jeżeli zgadzasz się z tym co mówię, albo chcesz publicznie ze mną polemizować – udostępnij ten materiał w swoich social mediach. Dzięki i powodzenia!