100. O AI w strategicznym Domain-Driven Design z Kubą Pilimonem

Wiesz, ile czasu minęło od naszej ostatniej rozmowy tutaj w podcaście? Od ostatniej rozmowy? Myślę, że przynajmniej 4 lata? Coś takiego? 3,5 roku. 3,5? Tak. A pierwszą rozmowę to mieliśmy prawie 6 lat temu. Także kawał czasu minął. To jeszcze w czasach przedpandemicznych musiało być. No i przed AI-owych. Wiesz, zupełnie inna rzeczywistość wtedy była. No i w sumie to też właśnie, dlaczego tego wspominam, wiesz co, bo chciałbym, żebyśmy teraz troszeczkę tak zajrzeli właśnie, co się pozmieniało jakby też w naszym postrzeganiu Domain-Driven Design, naszym postrzeganiu architektury i naszej codziennej pracy.

Pamiętam, w jakim szoku byłem, że komuś tak naprawdę, wiesz, się chciało w te wszystkie rzeczy, o których my tam dyskutowaliśmy, tak głęboko wchodzić i to jeszcze potem gdzieś właśnie na Githuba w postaci jakichś notatek wrzucać. Dzisiaj te notatki, wiesz, przygotowalibyśmy AI-em. Chciałem powiedzieć, że to komuś się chciało bez LLM-a, to w ogóle mega szacun, tak. Tak, więc tym bardziej szacunek. A właśnie, jak jesteśmy wiesz co, przy takim temacie. No bo przez te kilka lat udało nam się wspólnie zrobić parę rzeczy. I warsztatów takich otwartych i gdzieś tam zamkniętych, no i Legacy Fighter, który też gdzieś tam takim bardzo fajnym efektem się gdzieś tam odbił w community. Natomiast wiesz, tak sobie teraz myślę, pamiętasz ile czasu i wysiłku my włożyliśmy w przygotowanie tego kodu? Tego takiego, wiesz, zrypanego, na którym chcieliśmy tak naprawdę pokazywać. Jakie tam moglibyśmy pomysły, jak ten kod przygotować, no bo tam się zastanawialiśmy, czy nie zlecić go do tworzenia tego kodu w różnych, wiesz, okolicznościach przyrody.

No i teraz nawiązując do tytułu naszego podcastu, jak on się nazywa? Tak planowaliśmy nazwać ten odcinek. Na razie o AI to żeśmy jeszcze nie podyskutowali. I teraz archetypowe rzeczy na przykład już bym zdelegował do AI, ponieważ mam taki kod już napisany i byłoby mi łatwiej zająć się tymi specyficznymi. To chciałem nawiązać do... Do odcinka naszego, jeżeli pójdziemy w tę stronę oczywiście. No dobra, to cześć. I tak podsumowując, samo Domain-Driven Design takiego toolboxa mi de facto nie daje. No powiedzmy tutaj, jeżeli te warstwy odpowiedzialności, no to jest jakaś zajawka, nie? Natomiast mogę się wspierać tymi zewnętrznymi, powiedzmy, jakimiś tam konceptami. Zresztą tak jak w praktyce, nie? Nigdy nie używasz jednego narzędzia, zawsze używasz kombinacji narzędzi. Dokładnie. Czy to do analizy problemu, czy tego.

Natomiast gdzieś tam w rozmowach silniejszy nacisk właśnie kładziemy na samomodularyzację niż na rozumienie, gdzie jest dokładnie granica między bounded-kontekstem a subdomeną biznesową. Ale to się zmienia na przestrzeni lat, więc podejrzewam, że wraz gdzieś tam z zdobywaniem, mam nadzieję, wiesz, jakichś tam kolejnych doświadczeń i tak dalej, to też będzie gdzieś tam falować. No, to Mariusz po prostu jest na etapie czarnego rycerza DDD, czyli takiego, który już jakby widzi szeroki kontekst i nie walczy o te nazwy, które kiedyś powstały w fazie, nazwijmy to, czerwonego rycerza, który walczył z kijem czy tam z szablą. Jak rozmawiamy właśnie sobie o kontekście czasu, no to wiesz, od naszej ostatniej rozmowy wydarzyła się i się w sumie cały czas dzieje, cały czas ta AI-owa rewolucja.

I powiem ci, że też jestem bardzo ciekawy, jak to zmieniło twoją pracę jako architekta. Jak mocno ty wykorzystujesz właśnie AI w swojej pracy i jak to wszystko łączysz z Domain-Driven Design? To ja na początku powiem, że jak pojawiała się ta rewolucjonność, widać było, że jest u zalążków, że tak powiem, no to ja byłem sceptyczny, przyznam się. Bo ja mam takie podejście w naszej branży od wielu lat, na przykład sobie blockchain przeczekałem, stwierdziłem, że przeczekam. Dzięki temu nie masz, wiesz, straty na małpce w JPG-u. Tak, tak, tak. Dzięki temu byłem powiedzmy w tym czasie szczęśliwszym człowiekiem, nie musiałem się, nie musiałem szukać roboty, w której robiłem blockchaina, bo to teraz mi się do niczego nie przydało. Interesowałem się powiedzmy podłożem matematycznym pod tym, bo to jest ciekawe samo z siebie, ale nie z powodu naszej branży, tylko po prostu jest to ciekawe.

Nie wiem, czy zauważasz, nadążają. Tak jak skillsy były wprowadzone, to inni producenci starają się nadążać za tym. Nadal dla mnie przynajmniej takim wyznacznikiem jest Cloth, ale to nie znaczy, że za rok będzie tak samo. Przy tych zmianach może być zupełnie inaczej. To powiedziałaś o cieniach, to może zaczniemy od cieni, a potem odpowiem na twoje pytanie, które ciągle pamiętam od DDD i AI, bo tak haczyliśmy o te cienie. Widzisz jeszcze jakieś, oprócz tego FOMO? Strasznie mnie zastanawia, w którą stronę to pójdzie, jeżeli chodzi o wykorzystanie takich narzędzi zespołowo. No bo dzisiaj, wiesz, jak wchodzisz właśnie w jakąś interakcję z modelem, to zazwyczaj robisz to, wiesz, na swoim komputerze, sam sobie opisujesz kontekst. Nie tak patrzę teraz, wiesz, jak to faktycznie jest stosowane. No i tutaj się zastanawiam, w stosunku właśnie też do Domain-Driven Design, w jaki sposób jesteśmy w stanie tutaj zbudować to wspólne zrozumienie, jeżeli w bardzo wielu przypadkach każdy sobie rzepkę skrobię.

Dla mnie to narzędzie będzie genialnym stażystą chyba, jeżeli miałbym wyrazić taką Opinie co do tego, w którym miejscu sobie usadawiam takiego sparing partnera, to chyba jest to stażysta, ale na pewno nie dyrektor techniczny, który odpowiada za wizję i idealnie spina wszystko to, co musisz zrobić. Idealnie, jeżeli taki dyrektor istnieje, bo przynajmniej wystarczająco dobrze. Narzędzie potrafi mi pisać, dopinać jakieś tam szczegóły, generować warianty różnych rozwiązań, ale nie potrafi planować przyszłości. To jest ważne w kontekście tych spójnych decyzji, o których powiedziałeś. Mogę zaproponować jakieś funkcje, mogę nawet ładnie, w cudzysłowie, później się do tego pewnie odniesiemy w kontekście DDD, ładnie podzielić moduły, ale nie zaprojektuje mi AI system pod konkretną strategię, konkretne tempo zmian, czy np.

W dobie AI mogę mieć iluzję, podkreślam iluzję, redukcję tego procesu, iluzję, do kilku promptów i jeszcze mogę zapewnić się innym promptem, że moje rozwiązanie jest dobre, bo jak sam wiesz, to narzędzie świetnie podbija moje pomysły, jeżeli chce, żeby podbiło i wytłumaczyło komuś, czemu ten pomysł jest super, bo mogę tak go użyć, Żeby AI domknęło moją narrację, zamiast ją kwestionować. Oczywiście mogę też tak użyć, żeby kwestionowało na siłę, ale to kwestionowanie różnie się zazwyczaj kończy. Bo taki architekt, jeżeli nie widzi sprzeczności, to AI nie wyciągnie tych sprzeczności na wierzch, a nawet jak wyciągnie, to on je zignoruje. Mimo, że odpowiedzi tego narzędzia będą pod względem języka, mam na myśli polskiego czy tam angielskiego, jak to się nazywa taki język, nieprogramistycznego języka, normalnego, naturalnego chyba, tak się mówi, nie wiem jak się mówi.

Natomiast jeżeli się przytrafi błąd, a umówmy się, on się przytrafił wcześniej czy później, to jest tylko kwestia czasu, słynny paraben MTBF, Mean Time Between Failure, i to walnie na produkcji, to teraz z jaką szybkością będę w stanie się przez to przebić, zrozumieć, co faktycznie się stało i w jaki sposób mam poprawić specyfikację. Jeżeli mówimy o jakimś małym module, dobra, to mogę wejść i nawet czasami oczywiście sam AI może mi jeden czy drugi pomóc wskazać ten mój oczywisty błąd. Gdzieś tam faktycznie czy też błąd, który powstał w kodzie. Natomiast zaryzykuję stwierdzenie, że naprawdę w złożonych systemach to już przestaje być tak trywialne. I teraz jeżeli ja mam utrudnione wejście w zrozumienie, jak ten kod działa, żeby po prostu poprawić specyfikację, która być może go wytworzyła, no to tutaj jest, wiesz, zaczyna mi się taka czerwona lampka zapalać.

Oczywiście w firmach, w których ludzie wykorzystują tego typu narzędzia, bo też chciałbym zaznaczyć, że Nie wiem, jaka jest twoja obserwacja, ale moja jest taka, że to ciągle nie jest standard, mimo wszystko. Zależy od organizacji, zgadzam się. W niektórych to, że tak powiem, jest powiedzmy jeszcze testowane, w niektórych w ogóle tego nie ma, a niektóre organizacje są już na tyle... Nie wiem, czy to słowo dojrzałe będzie właściwe? Innowacyjne. O, to zdecydowanie lepsze, dzięki. Gdzie te wszystkie narzędzia są już wdrożone w cały proces SDX. Zresztą znowu, Marcin Markowski o tym ostatnio też wspominał. A w niektórych jeszcze masz Shadow AI, nie? Czyli ludzie nie mogą, ale i tak to robią sobie na swoich własnych laptopach. Więc mówisz, że jakby tempo wyciekania tego kodu i tak dalej jest jeszcze większe niż było w przeszłości. A to zupełnie inne S-Tab, wiesz, w ogóle, no kolejny przy okazji, wiesz, taki cień, nie?

Jakby zagadnienia związane z security, no troszeczkę znowu tutaj wrócą, wiesz, na świecznik. Ale dobra, to jakby odkopmy to pytanie, wiesz, odnośnie wykorzystania AI w Domain-Driven Design. Jak ty dzisiaj wykorzystujesz tego rodzaju narzędzia w swojej takiej codziennej pracy? Dobra, to jeżeli podzielimy sobie tak standardowo fazy DDD na początku, może nie fazy, tylko narzędzia skategoryzowane są na strategiczne, prawda, i na taktyczne. Zacznijmy od strategicznych, bo tam moim zdaniem jest więcej dużo cienia z użyciem tego typu narzędzi jak LLM. Moja obserwacja jest taka, Oczywiście mogę używać tego narzędzia i ja to robię np.

Tak, ale to w takim modelu, wiesz, jakby sparing partner, nie? Dobra, poka, powiedz mi, o czym ty myślisz, bo może to teraz pchnie mnie do przodu. Chciałbym zwrócić uwagę na jedną rzecz, bo ja parę razy słyszałem już, że a mi to kurczę... AI pięknie podzieliło system na moduły. Ja absolutnie nie chcę podważać tego zdania, bo nie było mnie tam, więc nie wiem. Natomiast warto byłoby się zastanowić, a skąd wiesz, że pięknie? Jakie są metryki Twojej oceny, że ten podział jest dobry? Bo tak sam wiesz, w naszej branży te metryki po prostu są średnie. Może nie tyle są średnie, są średnio stosowalne. O, bo metryki jakieś istnieją. Często oparte na doświadczeniu, natomiast coś tam mogę zrobić, ale w naszej branży są rzadko dobrze używane i moja obserwacja jest taka, że nawet jak zaczynam dyskutować z narzędziem, w cudzysłowie dyskutować z narzędziem w tym kontekście, czy to jest dobry podział, to ono się zachowywało tak, żeby obronić lub podważyć moją tezę w zależności od tego, co ja faktycznie chcę zrobić.

Ktoś pisze o tym, że AI zastąpi wszystkich wszędzie i zawsze jest jakiś obrońca, moralizator, który mówi, patrzcie, nie, ten człowiek mówi bullshity i ja go sprawdzam teraz. Z komentarza oczywiście to jest, czyli bo ja jestem z kolei w zbawce. Jakbym sam nie widział, kurczę, że ten człowiek jakby przesadza. Nie potrzebuję tego komentarza. Ten komentarz moim zdaniem się dużo nie różni od autora. W sensie od inicjalnego komentarza, tylko jest w drugą stronę. Patrzcie, kurczę, ja też jestem mądry, bo widzę, że ty gadasz głupoty. I takie dwa obozy obserwuję, brakuje mi takiego wyważonego głosu. I wiem, że ludzie mają ten wyważony głos, tylko po prostu w tym samym ścieku na LinkedIn, przepraszam za słowo, już nawet nie chcę się tym ludziom niczego komentować. Po prostu. Ja nie widziałem twojego wpisu na LinkedIn już długo. Także ta predykcja, Nie mam, wiesz co, nie jestem jakby w świecie pod względem technicznym rozwoju tych narzędzi.

To wydaje mi się, że gdyby powstawały kolejne sezony, to one by dokładnie przewidziały przyszłość. Nie wiem, czy pamiętasz ten odcinek, w którym Son of Anton, ten model sztucznej inteligencji, postanowił skasować kod, który oni tam przygotowali? Tak, wiesz co, wczoraj mi mignął news, gdzie downtime Amazona został wytłumaczony tym, że faktycznie sztuczna inteligencja postanowiła usunąć całe środowisko, ponieważ to był najlepszy prawdopodobnie sposób na pozbycie się problemu i postawienie go od nowa. I tłumaczenie, które tam zostało pokazane, że to nie był błąd sztucznej inteligencji, tylko błąd człowieka, ponieważ człowiek dał AI-owi zbyt duże uprawnienia. Nie wiem, czy to faktycznie jest, wiesz, jakby tutaj prawdziwe, więc dzisiaj, wiesz, trudno niektóre, że tak powiem, newsy w internecie oceniać. Natomiast jeżeli to faktycznie się wydarzyło, to powiem ci, że tamten odcinek to dokładnie było przewidywanie przyszłości.