To jest 263. odcinek podcastu Porozmawiajmy o  IT, w którym z moim gościem rozmawiam o tym, jak projektować systemy informatyczne w dobie generatywnego AI. 

Sponsorem tego odcinka jest Finture. 

Wszystko, co potrzebujesz, notatka, linki, transkrypcja czekają na Ciebie na porozmawiajmyoit.pl/263. Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, której tego słuchasz lub podzielenie się odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

 

Cześć! 

Mój dzisiejszy gość to absolwent Wydziału Elektroniki i Technik Informatycznych Politechniki Warszawskiej. Otwarty na nowości, profesjonalista IT z ponad 17-letnim doświadczeniem w różnych stanowiskach, w tym programista, lider techniczny zespołu, kierownik produkcji oprogramowania, architekt rozwiązań oraz doradca IT. Zafascynowany postępem w dziedzinie generatywnych sztucznych inteligencji. Próbuje znaleźć sposoby, w jakie może ona wygenerować wartość w obszarze inżynierii oprogramowania. Moim i Waszym gościem jest Adam Skąpski. 

Cześć, Adam, bardzo miło mi gościć Cię w podcaście. 

 

Mnie również bardzo miło. Cieszę się, że mogę wziąć udział. 

 

Dzisiaj, myślę, skorzystamy bardzo z Twojego doświadczenia w dziedzinie właśnie wytwarzania, oprogramowania i połączenia tego z generatywną sztuczną inteligencją, o której się bardzo dużo oczywiście ostatnio mówi. Niektórzy obawiają się, że stracą przez to pracę, niektórzy nie widzą w używaniu generatywnej AI żadnej wartości. Pewnie gdzieś oczywiście jak zawsze prawda leży pośrodku, natomiast my w tej dzisiejszej rozmowie skupimy się na projektowaniu systemów informatycznych, na projektowaniu rozwiązań software’owych i na bazie doświadczenia Adama spróbujemy sobie popatrzeć, jak GenAI może nas w tym aspekcie wspomóc. 

Zanim jednak do tego przejdziemy, to chciałbym Cię, Adam zapytać, czy słuchasz podcastów i ewentualnie poprosić o Twoje rekomendacje w tym temacie. 

 

Tak, od kiedy posiadam psa, chodzę na spacery i bardzo często towarzyszy mi przy tym albo podcast, albo nawet bardziej audiobook. I w tym kierunku staram się rozwijać. Jeżeli chodzi o podcasty, to regularnie słucham właściwie tylko dwóch. Jednen, ten bardziej techniczny Latent Space, który to jest podcast z informacjami, nowinkami z obszaru AI. Mają te informacje z pierwszej ręki. Bardzo ciekawe. Drugi to z kolei już bardziej takie prywatne zainteresowania geopolityczne, czyli Raport o stanie świata Dariusza Rosiaka, który regularnie co tydzień albo nawet czasem częściej zdarza mi się przesłuchać właśnie na spacerach. 

 

No tak, przyjemne z pożytecznym, jak najbardziej, dzięki za te rekomendacje. Dobrze, wiesz, na początku chciałbym Cię zapytać, czy w tym obszarze, w tej dziedzinie związanej z projektowaniem systemów informatycznych jest jeszcze jakiś brak narzędzi, jest jeszcze jakieś zapotrzebowanie, jest jeszcze coś, co nie jest zagospodarowane, czy potrzebujemy kolejnych rozwiązań w tej domenie? 

 

Może nie tyle, że jest jakiś konkretny brak, czy bardzo silne zapotrzebowanie, bo te narzędzia, którymi obecnie operujemy, czyli DDD, event storming, model C4, czy prototypowanie, one w sumie spełniają swoją rolę. Natomiast jeżeli mówimy tutaj o AI, to ono nie do końca wypiera, czy zastępuje którykolwiek z tych narzędzi. Bardziej stanowi swojego rodzaju łącznik usprawniający pracę z nimi. Pozwala bardziej efektywnie te narzędzia już istniejące wykorzystać. 

 

To właśnie może porozmawiajmy o tym temacie. Czy GenAI może być jednym z tych narzędzi? Jaką bolączkę tutaj nam adresuje? Czy też być może brak na bazie Twoich doświadczeń jak może nam ten tool box rozwiązań właśnie rozszerzyć? 

 

Może bardziej skupiłbym się na bolączkach związanych z obszarem projektowania systemów informatycznych. I takie trzy bolączki, które z mojego doświadczenia wynikają, to przede wszystkim projektowanie dobrych systemów informatycznych jest stosunkowo trudne. Jest to trudny problem po prostu matematycznie. Jest to próba uproszczenia złożonego zazwyczaj obszaru biznesowego, który na dodatek jest zmienny w czasie, i próbujemy go sprowadzić do statycznego de facto modelu. I to jest trudne zadanie, żeby to zrobić dobrze, żeby ten nasz model wytrzymał próbę czasu. 

Na dodatek, często, ponieważ jest to zagadnienie złożone, często uczymy się, jak nasze decyzje, jak nasze projekty zachowały się, jak się sprawdziły dopiero po ich uruchomieniu. Dopiero wtedy możemy wyciągnąć wnioski i powiedzieć sobie, o, to było dobre, a tutaj nie do końca. I w naszej karierze zawodowej nie jesteśmy w stanie projektować tych systemów każdego nowego co miesiąc. Tak naprawdę takie projekty się pojawiają raz na jakiś czas. 

Osobiście miałem przyjemność zaprojektować jedynie kilka, max kilkanaście takich systemów, co nie jest dużą próbą, żeby osiągnąć wiedzę ekspercką. Natomiast te wnioski, które uzyskałem, pozwoliły mi poszukać tej nowej metody. I tutaj może nie tyle jest to nowa metoda, bo prototypowanie było już zaproponowane przez Erika Evansa w swojej znanej niebieskiej książce. Natomiast AI pozwala nam zrobić to wielokrotnie szybciej. Możemy dzięki wykorzystaniu prototypowania możemy dużo szybciej uzyskać efekt zwrotny, dowiedzieć się, jak nasz projekt, jak nasz model systemu się zachowuje, jakie ma właśnie bolączki, co jest dobrze zrobione i decyzje podjęte na tym etapie są wielokrotnie tańsze niż kiedy musimy je podjąć na faktycznym etapie implementacji.

 

To są bardzo ciekawe doświadczenia, o których tutaj mówisz i nauka, którą wyniosłeś właśnie poprzez łączenie różnych metod, m.in. DDD, o którym wspomniałeś właśnie z GenAI, ale jestem przekonany, że na początku nie wyglądało to tak bardzo różowo. Jestem ciekaw tych Twoich pierwszych doświadczeń z wykorzystaniem AI właśnie w projektowaniu systemów IT. Czy od razu zauważyłeś ten potencjał? Czy od razu dotarło do Ciebie, jak można w skuteczny sposób te rozwiązania ze sobą porządzić i wspólnie wykorzystać? 

 

No nie, nie od razu się to zdarzyło. Początki oczywiście były nie do końca optymistyczne i napawające nadzieją. Miałem przyjemność brać udział w projekcie, który polegał na przygotowaniu architektury systemu dla jednego z naszych klientów. I to miało miejsce w tym roku. Ponieważ mam przyjemność być liderem tutaj działu R&D w naszej firmie również, to połączyłem te dwie role i próbowałem znaleźć sposób, jak można wykorzystać właśnie tutaj technologię AI do wsparcia tego zadania. Czyli trochę sobie uprościć pracę, a trochę właśnie z mojego wrodzonego lenistwa, żeby się nie narobić, a efekt był dobry. 

Początkowo próbowałem zasilić AI naszą tablicą event stormingową. Przeprowadziliśmy warsztaty, mieliśmy nasz proces zamodelowany na zdarzeniach i karteczkach i nakarmiłem AI naszą tablicą event stormingową i zacząłem z nim rozmawiać, co tutaj można z niego wyczytać. Natomiast AI, z którym wtedy współpracowałem, nie był w stanie przeczytać tej tablicy graficznie, więc nie umiał znaleźć tego wymiaru, był tylko wymiar 1 listy karteczek i ona była nieuporządkowana, więc za dużo z tej listy nie był w stanie wyczytać. Był mi w stanie zaproponować jakąś listę obiektów, może listę systemów zewnętrznych, które de facto były na tych karteczkach, więc nie było to jakieś bardzo wartościowe ćwiczenie. 

Dopiero kiedy wykonałem trochę pracy manualnej i na tej tablicy sam wypisałem, jakie obiekty mogłyby zamodelować tę domenę, i taką listę obiektów wprowadziłem do AI, plus jakieś tam kilka zdań, wymagań biznesowych, które zebraliśmy też w trakcie tych warsztatów, to wtedy zaczęło iść lepiej. 

Wtedy rzeczywiście AI wsparł mnie z uzupełnieniem mojej listy obiektów. Zaproponował swoje obiekty, które rzeczywiście trochę przegapiłem, czy to ze względu na to, że było to takie pierwsze bardzo szkicowe podejście, czy też może właśnie dlatego, że nie jestem ekspertem domenowym, więc niektóre zagadnienia domenowe też przede mną uciekały. 

To jest to, gdzie AI daje dużą wartość moim zdaniem, szczególnie przy projektowaniu systemów, czyli uzupełnia nam w takim dialogu naszą wiedzę. Jeżeli ja czegoś nie rozumiem, dlaczego ta faktura jest taka albo inna, on jest w stanie mi to wytłumaczyć. Inaczej musiałbym się posiłkować jakimś analitykiem, ekspertem biznesowym, który też nie zawsze potrafi jasno i przejrzyście odpowiedzieć. Tutaj mam takie coś pod ręką i od razu to zrozumienie domeny biznesowej jest dużo lepsze. Bo ja zadaję pytania punktowo. Tam, gdzie czegoś nie rozumiem, tam, gdzie czegoś nie widzę. albo też zadaje pytania typu: słuchaj, czy mógłbyś zaproponować, jakie jeszcze obiekty powinny wziąć udział w tym procesie? 

I tak to mniej więcej wyglądało. Zaczęliśmy od listy obiektów, następnie, ponieważ zadałem AI-owi, że operujemy w ramach DDD, więc zna wszystkie building bloki DDD, repozytory, agregaty, encje, więc łatwo się w tym nawigowało. I w ten sposób zaczęliśmy rozmawiać, jakie mamy agregaty, jakie mamy encje, jakie mamy value objecty. Widziałem czasem, że to nie jest tak, że on generował wszystko i było pięknie. Generował czasem rzeczy nie do końca sensowne, ale miał zadziwiającą umiejętność poprawienia swojej odpowiedzi po mojej sugestii. 

Czyli jak mówię mu, że nie, nie, słuchaj, zdarzenia nie powinny się publikować z serwisu, wolałbym, żeby się publikowały z agregatów, przepisywał kod i ten kod działał. Był to dalej kod prototypu, więc taki oderwany kompletnie od infrastruktury. Niemniej działał, uruchamiał się, można było wprowadzić dane. Wyglądało to naprawdę ciekawie. 

Muszę przyznać, że te dwa tygodnie spędzone właśnie zajęłem przy projektowaniu tego prototypu wywołało u mnie taki efekt, że dawno nie byłem tak zaskoczony, że to jest w ogóle możliwe. To było tak, że gęsia skórka i wow. Byłem rzeczywiście zaskoczony. 

Od tego momentu, kiedy zadałem mu tę listę obiektów, do momentu, kiedy miałem już klikalny, no nie klikalny, bo to jeszcze wtedy było w konsoli, prototyp, który przyjmował dane, obliczał rzeczy, wystawiał rozliczenia, zajęło to dwa dni i byłem naprawdę zszokowany, jak szybko jestem w stanie to osiągnąć. Natomiast kiedy pokazałem to mojemu zespołowi, to pojawił się od lat zastrzeżenia, że no fajnie, Adam, tylko że nie, do czego nam się to przyda, skoro to jest w konsoli, biznes nawet na to nie spojrzy, przecież to są same cyferki i pismo, to się nie przyda do warsztatów z nimi. 

Okej, challenge accepted, więc wróciłem do EII, poprosiłem go o to, słuchaj, musimy wygenerować to jakiś frontend, żeby ludzie widzieli, co jest w tych repozytoriach, jak te dane wyglądają i żeby mogli sobie tutaj coś poklikać. I to też po właściwie trzech dniach dało radę. Więc w sumie tydzień na przygotowanie takiego klikalnego prototypu, który modeluje to zagadnienie, o którym mówimy i daje namacalny efekt, no muszę przyznać, że zrobiło na mnie wrażenie. 

Dopiero kiedy wykonałem trochę pracy manualnej i na tej tablicy sam wypisałem, jakie obiekty mogłyby zamodelować tę domenę, i taką listę obiektów wprowadziłem do AI, plus jakieś tam kilka zdań, wymagań biznesowych, które zebraliśmy też w trakcie tych warsztatów, to wtedy zaczęło iść lepiej. 

Wtedy rzeczywiście AI wsparł mnie z uzupełnieniem mojej listy obiektów. Zaproponował swoje obiekty, które rzeczywiście trochę przegapiłem, czy to ze względu na to, że było to takie pierwsze bardzo szkicowe podejście, czy też może właśnie dlatego, że nie jestem ekspertem domenowym, więc niektóre zagadnienia domenowe też przede mną uciekały.

 

Bardzo ciekawe. Już kilka takich myśli mi się tutaj pojawiło, jak o tym opowiadałeś. Po pierwsze to, że masz już duże doświadczenie z, nazwijmy to, klasycznym projektowaniem systemów informatycznych bez wykorzystania tego typu narzędzi. Więc myślę sobie i też jestem ciekaw Twojej opinii, że po prostu wiedziałeś mniej więcej, co chcesz uzyskać. W sensie traktowałeś GenAi jako takie narzędzie wspomagające, przyspieszające, nakierowałeś te kolejne rozwiązania czy sugestie, które otrzymywałeś, ponieważ mniej więcej wiedziałeś, czego się spodziewać. 

W przypadku osób, które nie mają tego typu doświadczeń, ta droga może być inna, niekoniecznie gorsza, być może znacznie dłuższa, ale z pewnością inna. To jest taka pierwsza myśl, która mi się pojawiła, a druga to taka, że właśnie tutaj istotne jest to, że w takich iteracjach do tego podchodziłeś, prawda? Nie, że napisałeś jeden wielki prompt, który ma być takim ultimate promptem, który pozwala uzyskać od razu gotowy wynik, tylko podchodziłeś do tego właśnie w taki sposób małymi kroczkami, prawda? Dodawanie czegoś, rozszerzanie, później ulepszanie itd. 

Tak że to są pewnie takie istotne aspekty tego procesu, który właśnie opisałeś. 

 

Tak, bardzo fajnie to zauważyłeś. Rzeczywiście to, co mówisz, to odkrywanie stopniowe, czyli takie iteracyjne odkrywanie modelu, to jest esencja DDD moim zdaniem. I właśnie też byłem zaskoczony, jak dobrze AI w tym jest w stanie pomóc. Szczególnie w takich projektach, gdzie zespół jest mniejszy albo czasem architekci pracują sami przy projektowaniu tego systemu, on pozwala przeprowadzić nam ten wewnętrzny dialog, który już nie jest wtedy wewnętrzny, jest zewnętrzny i na dodatek jest z bytem, który ma bardzo szeroką wiedzę. 

Więc przy tym iteracyjnym podejściu o odkrywaniu tego modelu prowadziliśmy też czasem krótkie dyskusje. Jak go pytałem właśnie, czy zdarzenia nie powinny się publikować z agregatów, a nie z serwisów, to odpisywał, no są zwolennicy i przeciwnicy obu podejść. Jasne, zrobię ci tak, że będą się publikowały z agregatów. A ja z ciekawości: to jakie są zalety i wady obu podejść. I zaczynał wypisywać. 

Większość dawała mi do myślenia. Czyli to, co wypisał, nie wszystko było może mądre, ale rzeczywiście dawało mi jakiś punkt zaczepienia, żeby rozważyć też ten aspekt. Czyli pozwalało mi ten problem obrócić od kilku stron, co normalnie pewnie nie miałoby miejsca, bo jeżeli pracuję sam, nie mam za bardzo możliwości przedyskutować tego, to tutaj rzeczywiście ten aspekt też był bardzo fajny i ciekawy. 

A wracając do pierwszej części tego pytania, mówisz, że osoby z mniejszym doświadczeniem mogą mieć trochę inne doświadczenia. Zgoda. AI możemy traktować jako takie narzędzie i doświadczeni rzemieślnicy, korzystający z narzędzi, uzyskają lepszy efekt niż nowicjusze. Każdego narzędzia należy się trochę nauczyć. Niemniej tutaj pomaga to, że mam już to doświadczenie, mniej więcej wiem, czego oczekuję, więc umiem to zweryfikować. To nie jest tak, że ktoś z ulicy może przyjść i taki system zaprojektować, chociaż pewnie by dał radę, natomiast jakość tego będzie trochę niższa, tak? 

Więc przy tym iteracyjnym podejściu o odkrywaniu tego modelu prowadziliśmy też czasem krótkie dyskusje. Jak go pytałem właśnie, czy zdarzenia nie powinny się publikować z agregatów, a nie z serwisów, to odpisywał, no są zwolennicy i przeciwnicy obu podejść. Jasne, zrobię ci tak, że będą się publikowały z agregatów. A ja z ciekawości: to jakie są zalety i wady obu podejść. I zaczynał wypisywać. 

Większość dawała mi do myślenia. Czyli to, co wypisał, nie wszystko było może mądre, ale rzeczywiście dawało mi jakiś punkt zaczepienia, żeby rozważyć też ten aspekt.

Z pewnością. Czyli takie połączenie gumowej kaczuszki plus eksperta domenowego, który tutaj właśnie opisałeś. Myślę sobie, że przy takim zastosowaniu w firmach, które mają jakąś dużą bazę wiedzy, którą są w stanie niejako nakarmić Gen AI, to może to być faktycznie duża i przyspieszająca rzecz. W momencie, kiedy architekt próbuje zamodelować chociażby z wykorzystaniem DDD jakąś domenę i ma takiego, nazwijmy to, partnera, który dużo wie na temat tej domeny, to znacznie to skraca czas. 

 

Zdecydowanie. 

 

Jak już przy tym jesteśmy, to właśnie wspomniałeś tutaj, że opierałeś się w dużym stopniu na podejściu DDD. Czy jest coś, czego Ci brakowało, brakuje albo jakieś polączki, które zauważasz w DDD, które można w jakiś sposób spróbować rozwiązać przy wykorzystaniu AI? 

 

Nie, nie do końca. Jedyne właśnie to, w czym AI uzupełnił to moje podejście do DDD, to tę swoją wiedzę domenową mi zaoferował. Ja osobiście podejście DDD wykorzystuję od niedawna, od kilku lat. Staram się podchodzić w ten sposób do oprogramowania. I jeszcze nie miałem możliwości znaleźć luk czy niedoskonałości w tym podejściu. 

 

Czyli w samym podejściu nie, ale wspomniałaś, że kiedy dołożymy do tego ten klocek w postaci GenAI, no to wiele rzeczy się może zmienić. Mówiłeś tutaj o tym odkrywaniu domeny, jej modelowaniu. Gdybyś mógł się podzielić swoimi doświadczeniami, jak połączenie tych dwóch, nazwijmy to narzędzi, pozwala lepiej tę domenę odkrywać i modelować. 

 

AI pozwala nam szybciej prototypować nasz model domenowy. To jest jakby to główne zastosowanie, które teraz widzę. A pozwala nam szybciej zaprototypować, gdyż generuje nam kod do naszego modelu. Czyli AI jakby przyspiesza ścieżkę nam od naszej tablicy event stormingowej do naszego modelu domenowego właśnie tutaj z jednej strony działając jako ekspert domenowy, z drugiej jako właśnie ekspert DDD. więc pierwszy jakiś draft niedoskonałego jeszcze tego niedocelowego modelu jesteśmy w stanie bardzo szybko przygotować. 

Następnie jesteśmy bardzo szybko w stanie przygotować prototyp tego modelu, gdyż wygenerowanie takich prostych obiektów dzięki DDD, który nam wskazuje jakiego typu obiekty, z jakich on będzie złożony, też jest stosunkowo szybkie, a ten prototyp z kolei możemy przetestować, możemy z niego wygenerować sobie diagramy C4, CLASS czy NC,  i mamy właściwie gotowy projekt. Możemy go później weryfikować i modyfikować, szukając tego optymalnego modelu. Więc to przyspieszenie prototypowania dzięki AI jest moim zdaniem kluczową przewagą, którą jesteśmy w stanie uzyskać. 

 

Jestem ciekawy, jak patrzysz na ten proces, czy to jest bardziej taka rzemieślnicza praca, czy jest tutaj jakieś miejsca, jakaś przestrzeń na szeroko rozumianą kreatywność, tak to nazwijmy. Pytam dlatego, że taki zarzut swego rodzaju, który się często pojawia właśnie pod adresem GenAI jest taki, że to właściwie nic nowego nie odkrywa, że tutaj ta kreatywność Raczej bazuje na tym, co zostało już, że tak powiem, wstrzyknięte do modelu. 

Ale z tego, co tutaj mówisz, no to jak rozumiem, to nie jest taki niezbędny komponent czy aspekt, tak? Modelując tę domenę, odkrywając ją, no jednak wykonujemy pewną rzemieślniczą pracę i tutaj GenAI jest po prostu idealnym uzupełnieniem. 

 

Tak, nie oczekuję od GenAI zbyt dużej kreatywności. Raczej oczekuję wiedzy na temat projektowania systemów, na temat DDD, na temat właśnie domeny biznesowej, a od kreatywności wolałbym już zostać ja, jeżeli chciałbym tutaj coś zaczarować i jakoś inaczej zamodelować, inaczej poobsługiwać zdarzenia, czy wymyślić nowy sposób na komunikację między modułami, to oczywiście GenAI w tym pomoże, bo jeżeli ja rzucę jakiś mój głupi pomysł, to czasem pomoże znaleźć jego wady i zalety, zaproponować alternatywne podejścia i udoskonalić go. Natomiast nie widzę tutaj potrzeby na zbyt dużą kreatywność z jej strony.

 

Myślę, że może postaram się jakoś pociągnąć jeszcze to pytanie i zapytać Cię o różnicę pomiędzy tym, nazwijmy to klasycznym podejściem do prototypowania. Tutaj nawet szedłbym w kierunku spotkań z ekspertami domenowymi czy z pozostałymi architektami, kiedy faktycznie może ten pierwiastek kreatywności jakiś tam większy występuje, a takim podejściem, które tu właśnie przedstawiłeś, gdzie jedna osoba w postaci, powiedzmy, doświadczonego architekta stosując podejście DDD, wykorzystując Gen AI jako takiego partnera, może sparing partnera wręcz w różnych koncepcjach, jest sama samodzielnie właśnie dojść do tych rozwiązań. 

Jednym słowem mówiąc, jakie największe różnice pomiędzy tymi dwoma podejściami widzisz? 

 

Największą różnicą jest to, że mam historię mojej rozmowy z AI, czyli mamy jakby historię powstawania systemu, historię podejmowanych decyzji. Dużo z tych decyzji jest podejmowanych właśnie w ramach dialogu z AI, gdzie ja sugeruję, że coś zaimplementował nie do końca tak, on oczywiście się kaja i bardzo przeprasza i implementuje to dobrze. Następnie dochodzę do momentu, gdzie zastanawiam się, czy bardziej powinny to być dwa obiekty, czyli jeden obiekt i jakie jest zdanie AI w tej sprawie. 

I w momencie, kiedy nowa osoba, może nowy architekt po mnie przejąć ten system, ma de facto log mojej rozmowy i log wszystkich decyzji architektonicznych, czyli taki swoisty ADR. Coś, co nie we wszystkich projektach istnieje, a jest bardzo wartościowe. Czyli czemu właściwie podjęliśmy taką decyzję, jakimi się przesłankami kierowaliśmy. Oczywiście to pewnie nie jest zbyt przyjemne czytanie takiego logu czatu, bo tam nie wszystkie konwersacje są rzeczowe. Czasem po prostu zapędzamy się w ślepą uliczkę. Niemniej możemy wyprowadzić z tego bardzo dobrze udokumentowane decyzje architektoniczne dotyczące tego systemu. Więc tutaj ta główna różnica, że te ADR-y właściwie powstają same. 

 

To jest ciekawy tutaj aspekt, o który zahaczyłeś, ADR-u jako efektu końcowego, czy wynikowego powiedzmy takiej pracy właśnie nad zaprojektowaniem systemu informatycznego. I o to właśnie chciałbym Cię szerzej zapytać, czyli o nazwijmy to artefakty, które powstają właśnie w wyniku pracy, czy też współpracy z GenAI przy projektowaniu systemów informatycznych. 

 

Podstawowym artefaktem jest nasz prototyp, czyli zamodelowaliśmy domenę biznesową, przy pomocy AI zaimplementowaliśmy prototyp, potestowaliśmy sobie, wróciliśmy do modelu, stwierdziliśmy, że te obiekty muszą być jednak osobno albo razem, podjęliśmy jakąś korektę, znowu to sprototypowaliśmy, w końcu doszliśmy do czegoś, co uważamy za niezły kandydat modelu, i mamy nasz prototyp. 

I on pozwala nam uzyskać kolejne artefakty, już bardziej znaczące dla dalszej implementacji tego systemu, bo de facto jeżeli mamy prototyp zamodelowany, to możemy uzyskać logiczny diagram klas, łącznie z dokładnością co do każdego pola, każdej relacji. Mamy diagram modułów, mamy interfejsy, które są wymagane dla systemu. Możemy nawet przeprowadzić wstępne symulacje wydajnościowe, czy ocenić przyrost danych. Prostymi wręcz logami możemy zobaczyć, jak często dany serwis jest wywoływany albo ile czasu zajmuje przetworzenie pod jakimś obciążeniem. 

Modelując repozytoria, możemy zobaczyć, ile których obiektów nam przyrasta i jak ten system odpowiednio będzie się zachowywał w czasie, gdzie widzimy, że tych danych przyrasta za dużo, gdzie właśnie mamy jakąś redundancję albo nieoptymalnie zaprojektowany model danych. 

Dodatkowo dzięki prototypowi i dzięki temu, że zamodelowaliśmy frontem do niego, mamy makiety. Nie są to może piękne makiety zrobione w FIGM-ie, ale one są funkcjonalne. Klient czy użytkownicy biznesowi mogą w nie kliknąć, mogą powiedzieć, że tego im tu brakuje zaraz, a gdzie oni mają uzyskać taką informację i znowu mamy jakiś feedback do naszego modelu. I to podkreślam, decyzje na tym etapie są dużo tańsze w modyfikacji niż na dużo późniejszym etapie projektu. Więc tutaj ta wartość rzeczywiście moim zdaniem jest wysoka. 

I to, co wspomniałem przed chwilą, czyli mamy też nasz log decyzji architektonicznych dzięki właśnie prowadzonej konwersacji. Więc tak wyglądają te artefakty. 

 

Myślę, że to jest tutaj najfajniejsze, że artefaktem jest coś, co jest zrozumiałe przez innych członków zespołu, np. przez developerów, którzy później będą to w jakiś sposób już implementować przez UI, UX designerów, wreszcie przez biznes itd., więc tutaj efektem właśnie jest taki produkt, nazwijmy to, który jest jakimś standardem szeroko rozumianym i przyjętym właśnie w opisie i to jest według mnie duża przewaga czy duża wartość.

Bo gdybyśmy właśnie chcieli taki log rozmowy komuś podesłać jako wynik tej współpracy, to mogłoby być faktycznie dosyć trudne do zrozumienia, do dalszej pracy z tym materiałem itd. Natomiast kiedy mamy faktycznie coś, co jest zrozumiane przez innych, to faktycznie te osoby nie muszą nawet wiedzieć, że to powstało w wyniku współpracy z GenAI. Myślę, że to jest tutaj ta wartość. 

 

To jest drugorzędna właśnie ta komunikacja właśnie między ludźmi. To, co jest esencją DDD, czyli skrócenie tego dystansu między problemem biznesowym a jego implementacją, między developerami a ekspertami domenowymi. To właśnie postawienie czegoś między nimi, to trochę właśnie event storming miał na to odpowiadać i odpowiada, ale podanie im czegoś namacalnego, co mogą zobaczyć, jak się zachowuje, mogą kliknąć i się wypowiedzieć, zaczepienie dyskusji w jednym miejscu daje bardzo dużo pozytywnych wartości. 

 

Jestem ciekawy, jak oceniasz jeszcze potencjał, który tutaj w tym rozwiązaniu czy połączeniu tych dwóch rozwiązań drzemie właśnie w kontekście projektowania systemów IT. Jakie dalsze, powiedzmy, kroki integracji AI właśnie z tymi procesami projektowania jeszcze możemy osiągnąć? 

 

Potencjał jest właściwie olbrzymi, ale trochę zależy od tego, jak bardzo chcemy popuścić wodze wyobraźni, bo jeżeli się trochę ograniczymy, czyli na razie nie rozmarzamy się, gdzie możemy być za kilka lat, to już dzisiaj widzimy, że skoro jestem w stanie wygenerować prototyp takiego rozwiązania funkcjonalnego, dobrze przetwarzający dane, wystawiający jakieś interfejsy, to kolejnym naturalnym krokiem jest osadzenie go w infrastrukturze. 

Czyli przy wykorzystaniu np. modelu architektury heksagonalnej, gdzie w środku mamy to jądro modelu domenowego, to ten prototyp de facto przy pomocy odpowiednich narzędzi, może agentów AI, wpiąć już w infrastrukturę i uzyskać już jakąś wersję, nie prototyp, czyli uruchamiany lokalnie z bazami w pamięci i wszystko w powietrzu, tylko już coś bardziej namacalnego, co persystuje dane na stałe. Już można to wystawić na testy bardziej konkretne. Nie chcę powiedzieć na produkcję, ale jakoś tam w perspektywie czasu pewnie i to byłoby możliwe. 

I to jest przy taka, myślę, że nieodległa perspektywa. Już teraz myślę, że byłoby to możliwe. Natomiast jeżeli popuścimy trochę bardziej wodze wyobraźni, to te możliwości są olbrzymie i perspektywa systemów, których de facto się już nie do końca programuje, czyli system się składa jakby z dwóch warstw, takiej niskoponziomowej warstwy podstawowych usług, które pozwalają nam zapisywać dane, pobierać dane albo robić jakieś bardziej złożone obliczenia, do czego AI się nie nadaje i drugiej warstwy właśnie AI, który operuje na tych usługach, jakiegoś systemu wieloagentowego. 

Tak tworzone systemy z jednej strony gwarantują nam niezawodność dzięki tej swojej warstwie klasycznie zaprogramowanych usług, a z drugiej strony olbrzymią elastyczność, ponieważ programowanie tego systemu ogranicza się dodawanie instrukcji AI. Czyli jeżeli tworzymy system rezerwacji, to tłumaczymy AI, nasz tutaj lokal pracuje w takich i takich godzinach, rezerwujemy tam na godzinę, I w ten sposób definiujemy. Natomiast AI, jak dostanie zadanie z rezerwu i na najbliższy wtorek, byleby po 15, potrafi zaorkiestrować wywołanie kilku usług, żeby to zadanie zrealizować. I taka zmiana w takim systemie polega tylko na tym, że zmieniam instrukcję, o, rezerwujemy jednak już nie do 15, nie na godzinę, tylko na pół godziny i to wystarczy w sposób tekstowy przekazać alarmowi. 

I tego typu systemy wydają mi się też bardzo atrakcyjne, gdyż biznes, który by mógł sam modyfikować systemy, co jest jakby Świętym Graalem od zawsze, systemy no-code’owe, low-code’owe do tego dążyły, natomiast one nigdy jakby nie chwyciły, ponieważ użytkownicy biznesowi nie za bardzo lubią zajmować się programowaniem czy nawet instruowaniem. Tutaj mogliby swoje reguły biznesowe w sposób tekstowy przekazać do systemu i wydaje mi się, że to może zrobić olbrzymią różnicę. 

Czyli przy wykorzystaniu np. modelu architektury heksagonalnej, gdzie w środku mamy to jądro modelu domenowego, to ten prototyp de facto przy pomocy odpowiednich narzędzi, może agentów AI, wpiąć już w infrastrukturę i uzyskać już jakąś wersję, nie prototyp, czyli uruchamiany lokalnie z bazami w pamięci i wszystko w powietrzu, tylko już coś bardziej namacalnego, co persystuje dane na stałe. Już można to wystawić na testy bardziej konkretne. Nie chcę powiedzieć na produkcję, ale jakoś tam w perspektywie czasu pewnie i to byłoby możliwe. 

 

Czyli taka rosnąca rola rozwiązań GenAI nie tylko w projektowaniu systemów informatycznych, ale też de facto w ich budowie czy w ich produkcyjnej wersji to jest coś, co faktycznie jest coraz bardziej zauważalne. W związku z tym, jak w dobie właśnie tego rosnącego wykorzystania i potencjalnie jeszcze szerszego wykorzystania GenAI widzisz rolę architektów, programistów? Czym się będą zajmować? Jak się zmieni ich dzień pracy?

 

To jest trudne pytanie. Wydaje mi się, że rola i architektów i programistów za bardzo się nie zmieni. Dalej będą odpowiedzialni za to, żeby zamodelować jakieś działanie, zachowanie biznesowe w kodzie, w systemie. Więc będą mniej więcej zajmować się tym samym i odpowiadać mniej więcej za to samo. Dalej będą niezmiernie potrzebni. Natomiast ciężko mi sobie wyobrazić, że będą pracować bez wykorzystania narzędzi AI. 

Już teraz, jak w i w niewielkim wymiarze czasowym coś tam koduje, to dużo tego kodowania polega na dawaniu instrukcji. Potrzebuję metody, która posortuje mi wszystkie dane z tego pliku w ten i w ten sposób. To jest jedno zdanie i ten kod wygenerowany działa. Praktycznie w 99% przypadków działa. Nawet jeżeli nie zawsze jest to, co chce, to wymaga małych modyfikacji, żeby zadziałał tak, jak chcę. 

I ciężko mi sobie wyobrazić, mając takie doświadczenia, że programiści i architekci właśnie przy projektowaniu systemów, na zbieraniu wymagań biznesowych, na implementowaniu funkcjonalności będą pracować bez narzędzi AI. Wydaje mi się, że tutaj jest to nieodłączna część naszej przyszłości. 

 

Jestem ciekaw, jak patrzysz na wykorzystanie tych szeroko dostępnych modeli językowych. Czy tutaj nie ma jakichś zagrożeń związanych z bezpieczeństwem, z prywatnością? Oczywiście mówię tutaj o projektowaniu systemów informatycznych. Czy w ogóle tego typu rozwiązania według ciebie wchodzą w grę, czy też raczej powinniśmy mieć jakiś wewnątrzfirmowy model działający lokalnie, bez dostępu do internetu?

 

Oczywiście ta druga opcja, czyli model uruchomiony lokalnie będzie preferowana przez większe instytucje, instytucje finansowe. Myślę, że tutaj, gdzie bezpieczeństwo gra olbrzymią rolę, to nie da się inaczej. Wysyłanie swoich wrażliwych danych na zewnątrz, nawet przy podpisaniu klauzul poufności, może być zbyt ryzykowne. I tutaj tego typu instytucje będą musiały poczekać na mocniejsze modele uruchomione lokalnie, co już de facto ma miejsce. Już teraz te open source’owe modele powoli doganiają te flagowce zamknięte w chmurze. Więc chyba kierunek jest jeden. Te modele lokalne będą bezpieczniejsze i będą wystarczająco dobre do tych zastosowań, do których je potrzebujemy.

Dodatkowo oczywiście te modele lokalne będą mogły być fine-tunowane na naszej bazie kodu obecnej, więc będą lepiej odwzorowywać to, co chcemy osiągnąć. I tutaj te narzędzia dla programistów, nawet programujących właśnie w bankach czy instytucjach finansowych przyjdą wcześniej czy później.

 

To jak się na to wszystko przygotować? Czyli jakie umiejętności powinni już teraz rozwijać programiści i architekci, żeby jak najefektywniej właśnie skorzystać z tych rozwiązań?

 

Wydaje mi się, że tutaj najważniejszą rzeczą, o której należy myśleć przy pracy z AI, to jest rozumienie tego, co chcemy osiągnąć. Czyli musimy umieć zdelegować de facto zadanie AI, a żeby efektywnie zdelegować zadanie, to musimy rozumieć, co my chcieliśmy osiągnąć. I dzięki temu będziemy w stanie kontrolować AI, czy idzie zgodnie z tym, co oczekujemy, czy gdzieś tutaj nas wyprowadza na manowce.

Drugą ważną, moim zdaniem, umiejętnością to jest dekompozycja. AI nam też może w tym pomóc. To jest tak, że jeżeli mamy złożony problem, czyli właśnie projekt systemu albo system, większą złożoność domeny biznesowej, która jest przed nami, no to nie wystarczy, stwórz mi tutaj system bankowy, bo AI nam tak w tym nie pomoże. Musimy zdekomponować trochę ten problem na mniejsze zagadnienia, z czym AI właśnie jest nam w stanie pomóc też zaproponować jakby składowe problemu i tymi mniejszymi właśnie zadaniami już AI sobie dużo lepiej radzi.

Więc z jednej strony rozumienie, co chcemy osiągnąć, z drugiej dekompozycja na mniejsze problemy.

A trzecią, wydaje mi się taką może dosyć oczywistą, jest umiejętność szybkiego pisania. To jest coś, co osobiście niedawno nabyłem. W końcu parę lat temu nauczyłem się pisać bezwzrokowo, bo przeszkadzało mi to w pracy trochę. I od kiedy udaje mi się pisać już szybko i sprawnie, ta przyjemność obcowania z AI, pisania z nim jest dużo większa i nie jest to dla mnie żadną barierą.

Oczywiście pojawiają się modele, z którymi można rozmawiać. Niemniej jednak pisanie pozwala lepiej przemyśleć to, co chcemy zadać modelowi, lepiej to sformułować. I nie wyobrażam sobie, żebym cały dzień gadał z AI, zamiast z nim pisać, to jednak byłoby bardzo męczące.

 

Z pewnością. Gdy to mówiłeś, to tak sobie pomyślałem, czy to przypadkiem nie jest tak, że jest to kolejny dowód na to, że umiejętności miękkie, np. w postaci formułowania swojej myśli, komunikacji, takiego dialogu wręcz, w który wchodzimy z GenAI, nie są coraz bardziej wymagane w IT, że jednak daleko nam już od tego zamknięcia w piwnicy i zajmowania się tylko niskopoziomowymi kwestiami technicznymi, a właśnie taki dialog, taka umiejętność odpowiedniego formułowania myśli i szeroko rozumiane umiejętności miękkie po prostu zyskują na znaczeniu również dzięki temu, że musimy się porozumiewać, kontaktować z Gen AI.

 

Zdecydowanie. I tutaj jest też taka ciekawa dyskusja, jak rozmawiać z tym AI, bo mówisz o umiejętnościach miękkich, czyli właśnie umiejętności komunikacji, i tutaj prosić go, dziękować, rozkazywać, to naturalnie mi przychodzi proszenie i dziękowanie. Natomiast jest to co najmniej dziwne, jeżeli korzystamy z narzędzia jednak, a nie rozmawiamy z człowiekiem. Niemniej tę umiejętność formułowania właśnie myśli i precyzyjnego definiowania tego, co chcemy osiągnąć, jest bardzo cenna. To właśnie jest różnica między tym, że AI jest przydatne, a AI generuje nam kompletne abstrakcje.

 

Czy myślisz, że każdy projekt informatyczny nadaje się właśnie do tego typu zaprojektowania przy wykorzystaniu GenAI, czy też są jakieś wielkości, może domeny tych projektów, gdzie, powiedzmy, nie aplikuje to się jeszcze tak dobrze?

 

Wydaje mi się, że przy bardziej złożonych albo wielokrotnie bardziej złożonych systemach może być tu zagadnienie, bo rzeczywiście tego AI pracują w ograniczonym kontekście. Nie jesteśmy im w stanie zadać całej wiedzy, a nawet te, które chwalą się, że mają bardzo długi kontekst i właściwie całą wiedzę jesteśmy w stanie tam załadować, to nie potrafią efektywnie korzystać z tego kontekstu. Im dłuższy kontekst, tym potrafią zgubić te informacje.

Dlatego rzeczywiście przy większych domenach, większych kontekstach wiedzy tutaj może być jeszcze nie do końca optymalne zastosowanie. Niemniej wymusza to na nas podział na moduły. Więc to jest dobre samo w sobie. Jeżeli problem jest za duży do AI, to pewnie jest to też za duży moduł. I to jest taka nieoczywista wartość z tego, że chcemy pracować z tym AI. Właśnie to zdekomponowanie naszego systemu na mniejsze klocki, co daje pozytywny efekt, pomijając tworzenie prototypu. Mniejsze, bardziej specjalizowane moduły to zazwyczaj lepiej. Ważne, żeby były po prostu ze sobą nie za mocno powiązane.

 

Bardzo ciekawe spostrzeżenie. Dodałbym jeszcze na koniec pewnie, że GenAI się nigdy nie zmęczy. Zawsze będzie cierpliwie odpowiadał na nasze prośby i zapytania, więc warto pewnie też w ten sposób właśnie na to patrzeć i wykorzystywać to rozwiązanie jako narzędzie.

Dobrze, Adam, bardzo Ci dziękuję za dzisiejsze spotkanie, za naszą rozmowę. Moim gościem był dzisiaj Adam Skąpski. Rozmawialiśmy o tym, jak wykorzystać GenAI do projektowania systemów informatycznych. Adam, bardzo Ci dziękuję.

 

Dziękuję bardzo.

 

Powiedz, proszę, jeszcze na koniec, gdzie Cię można znaleźć w internecie, gdzie możemy słuchaczy odesłać.

 

Aktywny obecnie jest chyba tylko mój profil LinkedIn’owy. Na Facebooku też już mnie nie ma, a portal Twitter powoli, wydaje mi się, upada, więc zapraszam do kontaktu na profilu LinkedIn. Ewentualnie na Twitterze można mnie followować. Czasem podaję jakieś wiadomości ze świata AI, które się przebijają.

 

Świetnie. Oczywiście linki znajdziecie w notatce do odcinka. Adam, jeszcze raz bardzo dziękuję. Do usłyszenia. Cześć!

 

Dziękuję pięknie.

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media. 

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, jak projektować systemy informatyczne w dobie generatywnego AI. 

Do usłyszenia w następnym odcinku.

Cześć!