99. O architekturze oprogramowania w erze AI-Assisted development z Łukaszem Szydło i Marcinem Markowskim

Może to jest okej, nie? Jeżeli używamy takiego języka i wszyscy, którzy będą to czytać, to są z tym okej, to może tak zostać, ale też trzeba trochę uważać i może przejrzeć, zanim się skomituje. To jest przynajmniej taka moja obserwacja, że do tej pory zespoły deweloperskie generalnie nie lubiły robić prototypów, bo jak pierwszy raz zrobili prototyp, Lądowało od razu na produkcji. O, dokładnie. To jest tak zwane protodaction, Łukasz, protodaction. A, protodaction, nie znałem tego. Prototyp na produkcję i żyjemy z tym, wiesz, forever. Właśnie, więc coś się okazało, że jak robimy ten prototyp kijowy, to jest ryzyko, że on wejdzie na produkcję, więc zespoły, które już to wiedzą, jak ktoś przychodzi do nich i mówi, ej, zróbcie nam prototyp. Nie robią prototypów. Albo mówią, że nie zrobimy tego prototypu, albo robią prototyp, tylko robią go dobrze. Od razu jak powiedziałaś o Agilu, to chciałem ci zadać pytanie, czy wieszczysz taki sam sukces wdrożenia AI jak wdrożenie Agila w korporacjach?

W ostatnich miesiącach dostałem od was naprawdę sporo zapytań, kiedy będzie kolejny odcinek podcastu, czy w ogóle ten podcast będzie się jeszcze pokazywał. I tak, BSD nigdzie się nie wybiera. BSD cały czas się będzie pokazywać. Mam nadzieję, że z większą regularnością niż to bywało w ostatnich czasach, no bo nie będę ukrywał, przerwa, którą potrzebowałem sobie zrobić, troszeczkę się przedłużyła. A w 2026, w lutym tego roku, podcast wraca na antenę z tematem, który mam nadzieję, że interesuje większość naszej branży, czyli AI. A moimi gośćmi będą Marcin Markowski i Łukasz Szydło, osoby, które zapewne kojarzycie z wcześniejszych rozmów na temat domain-driven design i architektury oprogramowania, chociaż... Naszym głównym tematem rozmowy oczywiście nie będą rzeczy typu domain design, event storming, a właśnie generatywna sztuczna inteligencja i to, w jaki sposób możemy ją wpleść w nasz proces wytwórczy oprogramowania i w jaki sposób AI wpłynie na pracę software architekta.

Wasz bombelek informacyjny też wygląda tak, że tylko AI, AI, AI. Czasami mam wrażenie, że jak patrzę na jakieś moje social media, na LinkedIn'a, na Twittera, to wygląda to tak, jak wycięte takie słowa z prezentacji pewnego CEO, z pewnej konferencji. AI, AI, generatyw AI, AI, AI. U was też tak to wygląda? No z grubsza tak. Jak się spojrzy na LinkedIna, to człowiek ma tylko wrażenie, że dlaczego on już chyba jest 10 tysięcy długości za wszystkimi, bo wszyscy tak zasuwają do przodu, że... No można FOMO dostać. No. A Łukasz, jak u ciebie? No niespodobnie. Ja cały czas mam wrażenie, że wszyscy nie robią nic innego, tylko piszą prompty. No właśnie, słuchajcie, bo tak chciałem troszeczkę podciągnąć ten temat, bo 2025, 2026, to gdzie człowiek nie obejrzy, gdzie człowiek nie spojrzy, no to ten AI wyskakuje.

No to niech jeszcze wyskoczy z tego podcastu. Ale tak chciałem się troszeczkę dotknąć tematu, może nie tyle, wiecie, takiego oprogramowania z wykorzystaniem AI na co dzień, chociaż chciałbym, żebyśmy od tego zaczęli, ale od tego, jak tego rodzaju narzędzia wpływają i też wpłyną na pracę architekta. No bo to, że w najbliższej niedaległej przyszłości ten zawód programisty odejdzie do lamusów, tak jak go dzisiaj znamy, no to myślę, że czas się zastanawiać, jak jednocześnie te wszystkie narzędzia wpłyną też na pracę, powiedzmy, wyższego poziomu. Ale zanim do tego dojdziemy, chciałem się was zapytać, jak w waszym otoczeniu wygląda faktycznie takie stosowanie narzędzi AI-owych, takiej codziennej pracy dewelopera. Tego architekta na chwilę jeszcze odłóżmy na bok. Wydaje mi się, że z większością zespołów, z którymi ja mam styczność, to jest po prostu używanie agentów w obrębie IDE.

Tak z drugiej strony to myślisz, że to tak się skończy, że te prototypy tak potem to zostaną jednak porządnie zrobione, a nie wylądują na produkcji i nie staną się najtrwalszą prowizorką na świecie? No właśnie wydaje mi się, że jeśli to deweloperzy ich nie robią, tylko robią je produktowcy sami dla siebie i mają świadomość tego, przynajmniej niektórzy, że to nie jest kod, który się nadaje do tego, żeby produkcyjnie działać, że on coś tam robi. Ale jednak, żeby kod był kodem produkcyjnym, to nie tylko musi dobrze robić to, co robi, tylko jeszcze ta operacyjna rzecz, też związana z atrybutami jakościowymi wokół tego, to ona też musi być dowieziona. A dwa, że to też nie wygląda tak idealnie. To też nie są takie prototypy, które mogłyby w pełni zastąpić taką produkcyjną aplikację. Nie wiem, jak to u was w waszej praktyce wygląda, ale w mojej praktyce jest tak, że AI jest w stanie bardzo przyspieszyć pierwsze 80% czy 90% roboty.

No ale później to ostatnie 10%, które zostaje, które trzeba jeszcze tam samemu doszlifować i dorobić, no to to wcale nie jest taki krótki czas. Czasami nawet i drugie tyle potrafi być. A Marcin, jak to u ciebie wygląda? To u mnie przynajmniej w tych projektach, przy których ostatnio siedziałem, to wygląda bardzo różnie. Od tego, że w ogóle nie używają i tyle, taką mamy politykę, do takich, gdzie w zasadzie całe SDLC jest automatyzowane już przy pomocy AI-a. Czyli to nie jest tylko praca dewelopera z Clodem czy z... Kursorem czy z czymś takim, która wspomaga pisanie kodu na samym końcu. Tylko od pierwszego spotkania z interesariuszami gdzieś tam ten AI wspiera produkcję różnych artefaktów pośrednich

I tutaj używam niemalże cytatu z kilku rozmów, gdzie faktycznie w projektach takie rzeczy się pojawiają. Gdzie wcześniej ten proces był relatywnie spowolniony tym, że okej, potrzebujesz chwilę czasu, żeby to przemielić we własnej głowie, oprogramować, przetestować i dopiero gdzieś tam wystawić na review, a dzisiaj 20 tysięcy linii kodu? Proszę bardzo, za pół godziny przyniosę kolejne 10 tysięcy. Wydaje mi się, że to jest problem, który mają wszyscy, którzy zaczynają korzystać trochę więcej z AI. Że ten środek ciężkości przeniósł się z tego momentu pisania na element review'owania. I wydaje mi się, że na ten moment chyba jeszcze nikt do końca nie ma... Dobrej odpowiedzi na to wyzwanie. Wydaje mi się, że my z Marcinem możemy mieć jakieś pomysły w tym kierunku i przemyślenia, ale takich produkcyjnych rozwiązań, które by się sprawdziły, nie ma.

Obie? Obie sytuacje. Kiedyś też sami sobie robiliśmy review. Nie wiem, przynajmniej ja robiłem. Zanim wpuściłem coś na repo albo dodałem do review, to sam zobaczyłem, co napisałem. I krytycznie to oceniłem. Ktoś inny, kto brał udział w procesie projektowania, też potem rzucał na to okiem i też musiał rozumieć, co się tam dzieje. W tym momencie ten element samoreviewowania, czyli zmian, które ja wyprodukowałem, nabiera dużo większego znaczenia, no bo AI to naprodukował, ja muszę zobaczyć, czy on w ogóle naprodukował to, o co mi chodziło. To jest dużo, dużo istotniejsze, ale ta inna osoba też dobrze byłoby, żeby rzuciła na to okiem i wyłapała rzeczy, których ja nie wyłapałem i do tego, żeby nie było wąskiego gardła,

To pewnie jest kolejny temat, ale taka mała zajawka, że kodowanie z AI może powodować to, że są wąskie gardła, takie pojedyncze punkty, które mogą zawieść. To znaczy, że wiedza jest bardzo zcentralizowana. Tylko jedna osoba wie, jak to zrobić, bo była w stanie bardzo dużo zrobić sama i nikt już nie wie. Jeżeli ktoś inny nie będzie robił tego review, to się nie dowie, co tam jest. W związku z tym, gdyby trzeba było tę osobę zastąpić z dowolnych powodów, to nie będzie miał kto tego zrobić. A kodu jest tak dużo, tak szybko jest produkowany, że bardzo ciężko jest zrobić to review, więc jest jeszcze mniejsza szansa niż dawniej, że ktoś to review uczciwie zrobi. Ale to jest właśnie temat, który, powiem wam szczerze, że tak sam się zastanawiam w tą stronę, to się potoczy, nie?

I teraz, co jest dla mnie problemem, bo to jest zarówno to, o czym mówiłeś z tym review, jak i z tym elementem, o którym ty, Marcin, wspominałeś, z tym właśnie centralizowaniem się wiedzy. Że dla mnie przed AI-em, jeżeli była akurat taka sytuacja, że ja byłem odpowiedzialny za jakieś tam zamodelowanie, a później ktoś inny był odpowiedzialny za implementację tego, no to ja też miałem problem, żeby to zreviewować. Bo co prawda ten kod powstawał nie w trzy godziny, tylko powstawał w trzy tygodnie. Albo nawet i dłużej. No ale ostatecznie ktoś mnie pyta, Łukasz, tak, czy to, co myśmy zrobili, to jest okej, tak? Czy to jakoś wygląda? Ja miałem dokładnie ten sam problem. Bardzo duża ilość kodu, która powstała, którą ja musiałem zweryfikować, żeby zobaczyć, czy ostatecznie ta architektura, ta struktura była okej.

My, tak jak mówiłeś, używaliśmy zwykle do tego DDD i to się dobrze sprawdza. Jeżeli ktoś modeluje używając jakichś innych building blocków, to też ma te elementy pośrednie. No i teraz z AI-em to po prostu te problemy, które mieliśmy od zawsze, one się po prostu wypuklają jeszcze bardziej, bo tempo się nakręca. W związku z tym, jeżeli się nie robi tego sprawnie i nie ma się tego sprawnego pośredniego poziomu, no to jest bardzo ciężko reviewować, bo po prostu fizycznie się tego już nie da zrobić. Tak, ale moim zdaniem właśnie to jest dobra rzecz, która idzie za AI-em, czy która wchodzi dzięki AI-owi, bo Ja AI traktuję jako swego rodzaju jakby kolejny proces automatyzacji. Przyspieszania pewnych rzeczy, które do tej pory były wolne. I jak były kolejne fazy różnego rodzaju automatyzacji, no przecież pamiętacie, tak, nie wiem, jak było wprowadzane CI-CD u nas, który przyspieszył proces wdrażania, nie?

Jeżeli będzie precyzyjny język w dobrze zdefiniowanych granicach, To tym modelom będzie się po prostu dużo łatwiej w tym odnaleźć, tak, niż w takim wielkim spaghetti, gdzie to samo słowo ma pięć różnych znaczeń i teraz no my być może już po długim czasie w projekcie to już bez problemu to rozróżniamy te znaczenia, ale... LLM? Niekoniecznie, tak? Więc zrobienie dobrze bounded contextów będzie też na pewno istotne w tym. Ja bym jeszcze wrócił do tego przyspieszania, bo my się strasznie skupiamy na tym przyspieszaniu. Teraz wszystko jest ten times, a już niedługo to nie wiadomo, ile times będzie. I też bym wrócił do tego, jak było... Jak było wcześniej? Czy przed całą AI-ową rewolucją to czasem nie dało się też czegoś robić 10 razy szybciej?

Pewnie też spotkaliście zespoły, które pracowały 10 razy szybciej od innych zespołów. One po prostu szły w dobrym kierunku, tak? Te, co pracowały 10 razy szybciej, a nie szły w złym kierunku, a potem meandrowały długo, żeby jednak na ten właściwy kurs wrócić i coś dowieźć. AI to jest narzędzie, które nam przyspiesza wiosłowanie, ale to nie gwarantuje, że wiosłujemy w dobrym kierunku. Z jednej strony nie, ale z drugiej strony dzięki temu, że ja jestem w stanie bardzo szybko wiosłować, to niedużo mnie kosztuje zboczenie na chwilę, nawet pójście w złym kierunku, zweryfikowanie, o, tutaj jednak, nie wiem, tam jest wodospad, tam jednak nie płyniemy. To zależy, jak długo wiosłowałeś w tym złym kierunku. Jak się szybko zorientujesz, to tak.

W każdej firmie czy w każdym projekcie będzie to trochę inaczej, bo ludzie po prostu też mają, używają różnych elementów do tego, żeby o tych rzeczach dyskutować, ale ważne moim zdaniem właśnie jest to, że teraz super cenną wiedzą dzięki właśnie AI jest to, co my lubimy robić, czyli myślenie na temat myślenia. Bo jeżeli ty zaczynasz myśleć o tym, jak myślisz i zaczynasz nagle dochodzić do tego, w jaki sposób twój umysł pewne rzeczy porządkuje, jak ty o tym myślisz, jakich używasz właśnie abstrakcji, jakich używasz elementów konstrukcyjnych, to jeżeli ty to potrafisz wyciągać ze swojej głowy, ale też z innych głów, I potrafisz to wyciągnąć dobrze, to wyciągnięcie tego i wrzucenie tego do LLM-a powoduje, że on naprawdę zaczyna ci dawać fajne rezultaty.

W jakiejś tam części jest na nas w stanie to zrobić perplexity, no to to już nie ma wymówki. Ja bym tu wprowadził poziom na dwa rodzaje wiedzy, bo to, o czym ty mówisz, Łukasz, czyli ta wiedza z takiego researchu, który jesteśmy w stanie zrobić AI-em, czyli na podstawie wiedzy, która jest publicznie dostępna, tak? Jest wszędzie i ona jest albo w wagach modelu, albo on sobie tam porobił searcha na szybko, tylko że po prostu był w stanie przeszukać i przeczytać setki źródeł w internecie, co nam zajęłoby tygodnie, to to jest taka wiedza, która jest publiczna. To jest trochę uśrednienie, tak? Tam możemy znaleźć problemy branżowe, tam możemy znaleźć różne jakieś tam standardowe wzorce i to była wiedza, którą my jako konsultanci przynosiliśmy na tego typu spotkania.

I to będzie to takie wspólne modelowanie. I chyba z tego względu ono po prostu nie wyparuje, tak? Właśnie ono nie może wyparować, bo to jest jeden z problemów, który ja widzę z tym, w jaki sposób jest AI wdrażany. Może wdrażany to jest duże słowo, ale co powoduje takie po prostu używanie AI bez jakiegoś takiego szerszego pomyślunku? Powoduje moim zdaniem to, że ludzie zaczynają obserwować, kurczę, to co wcześniej robiły trzy osoby, Teraz może robić jedna osoba. I zaczynamy wracać do tego, że zmniejszamy ilość osób pracujących naraz nad jedną rzeczą. Że tak jak kiedyś normalne było to, że jeden feature, jeden developer i on po prostu siedzi, on agreguje tą wiedzę, on staje się ekspertem, jeśli chodzi o ten fragment kodu, fragment systemu i lepiej, żeby się nie zwolnił.

Tam to będzie miało znaczenie, czyli może się tak okazać paradoksalnie, że techniczna zabawka jaką jest AI przypomni kluczowe tezy z DDD, że najważniejsze jest poznanie domeny. To się zgadza, ale ja na przykład bardzo pozytywnie, nie wiem czy wy macie dostęp do tej nowej wersji Miro, która jest taka AI-ready, że można właśnie robić tam flowy AI-owe, gdzie jakby ten agent jest wbudowany w tego kanwasa. To ja właśnie w tego typu narzędziach, ja widzę przyszłość, która umożliwi właśnie kolaboracyjną współpracę pomiędzy ludźmi, która jest wspierana przy pomocy agenta AI-owego, bo moim zdaniem takich narzędzi potrzebujemy, które Nie powodują tego, że właśnie jest jedna osoba, która zamyka się i jest odpowiedzialna za wszystko, bo brakuje często tej innej perspektywy, spojrzenia.

Ale absolutnie się z tym zgodzę, że ten dodatkowy element, czyli skąd te dane na tym Miro się wezmą, Do tej pory byliśmy przyzwyczajeni, że te dane się po prostu biorą z naszych głów, że tylko my rysujemy, jesteśmy na spotkaniu i po prostu coś trzeba na to miro wrzucić. A dzisiaj jest jeszcze dodatkowy uczestnik tego naszego warsztatu, którym jest właśnie jakiś agent AI-owy, który przez MCP jest podpięty do naszej bazy wiedzy, którą budujemy. Najlepiej opartą o jakąś sensowną ontologię. No i to już jest, że tak powiem, majstersztyk. Tutaj u jednego z klientów, dla którego teraz pracuję, właśnie próbujemy zrobić coś takiego. Jesteśmy, że tak powiem, w trakcie robienia tego, więc jestem ciekaw, żeby zobaczyć, jak to rzeczywiście wygląda, czy będzie wyglądało w trochę większym projekcie.

Bo też jest ciekawa rzecz, to jest taki trochę off-top dla mnie, Kto dzisiaj robi ciekawe, nowe, innowacyjne rzeczy właśnie w kontekście SDLC z AI? Małe zespoły. Małe zespoły, małe firmy. I to nie jest specyfika AI. To jest specyfika wszystkich, że tak powiem, ewolucji naszej branży, które były. Tak jak pomyślimy sobie, jak duży był zespół w Chryslerze, który robił XP i TDD. I tam było czterech chyba, nie? Sumarycznie. Wiesz, no nie jesteś zgnośniały, nie jesteś skostrzeniałą organizacją, jesteś wiesz, bo ty z winnej możesz szybko ewoluować, no to to jest oczywiste. Poza tym masz bodziec dużo mocniejszy, bo jak jesteś wielką korporacją, to cię po prostu stać na nieefektywność.

To wszystko się tak zaczynało. Małe zespoły, robił się pewien hype i w którymś momencie stawało się to na tyle wszędobylskie, że I jakby oczekiwane, że w dużych firmach też te rzeczy zaczynały się pojawiać. Już dzisiaj każda korporacja jest chyba zwinna. Nie wiem, czy ktoś widział już jakąś korporację, która nie jest zwinna. Wydaje mi się, że już chyba wszystkie. A z AI to się dzieje dużo szybciej. O ile w Agilu to zajmowało nam parę lat, żeby korporacje stawały się dzwinne, no to tutaj właściwie po roku już mamy wdrażanie tych rzeczy w dużych firmach. Duże firmy chcą to u siebie robić. I teraz problem, który ja obserwuję, jest właśnie taki, że mamy dużo praktyk, które zostały wypracowane W jedno, w dwu, w trzyosobowych zespołach, w których pewnych problemów nie jesteśmy w stanie zauważyć.

I tak samo jak w przypadku wdrożenia Agila, to jak ten Agile wygląda w małych zespołach, versus tu chłopaki widzą uśmiech na mojej twarzy, versus jak to wygląda, jak to jest wdrażane w dużej organizacji, no to widzimy różnicę. Od razu jak powiedziałeś o Agilu, to chciałem ci zadać pytanie, czy wieszczysz taki sam sukces wdrożenia AI jak wdrożenie Agila w korporacjach? W części firm tak. W części firm dokładnie tak i wieszczę, że jest bardzo dużo organizacji, które będzie traktowało AI jako po prostu szybszy samochód, taki szybszy koń. Tylko jedną rzecz może robić po prostu i tyle i nie będzie widziało jakiegoś takiego szerszego potencjału w tym, jak to może zostać wykorzystane, tylko jakby kultura organizacji pozostanie taka sama, procesy pozostaną takie same i będą jakieś tam punktowe elementy, które będą robione przy pomocy sztucznej inteligencji, które być może coś przyspieszą, a wieszczę to, że na pewno będą takie, które jeszcze spowolnią.

I tak średnia. Tak jak jest podawana średnia, to średnia mówi, że spada nam produktywność. I biznes mówi, kurczę, po co nam takie narzędzia? Przecież ja nie potrzebuję płacić za dodatkowe narzędzie, które sprawia, że produktywność mi spada. Jak przeanalizujemy te raporty dokładniej i wejdziemy sobie do środka i zobaczymy to, jak się rozkłada... Dobra, to są raporty, które są oczywiście oparte o ankiety, nie o jakieś tam silniejsze badania, tylko ankiety deklaratywne na pytanie, jak bardzo AI wspomaga cię w pracy, o ile jesteś szybszy, kiedy używasz AI-a, to widzimy, że jest bardzo dużo odpowiedzi, że No, że tak nie przyspiesza mnie za bardzo, czasami nawet spowalnia, a jest trochę taki, które pokazują, jestem dwa, trzy, cztery, pięć i dziesięć razy szybszy.

I to jest to, o czym mówiłem wcześniej, że jeżeli firma ma zrypany proces, to jak wrzuci AI-a, to ten AI zamplifikuje tą zrypaność. A te firmy, które mają te procesy poukładane dobrze, No to automatyzacja spowoduje, że one jeszcze więcej zyskają na to, że te procesy zostały przyspieszone. Mamy teraz dużo manufaktur i część tych manufaktur Dobrze produkuje i jak im się wrzuci tego AI-a, to one będą produkowały jeszcze lepiej, a mamy dużo takich manufaktur, które mają te procesy nieoptymalne, nie zwracają uwagi właśnie na jakość, nie zwracają uwagi na architekturę, nie zwracają uwagi na atrybuty jakościowe, nie zwracają uwagi na zarządzanie wiedzą, na budowanie tej wiedzy, to to wszystko zostanie zaamplifikowane, jeśli dorzucimy do tego

Do tego AI. Jak w waszej ocenie będzie tak w przyszłości, może bliższej niż dalszej, będzie wyglądał proces projektowania architektury właśnie z użyciem, powiedzmy, narzędzi AI-owych, nie takich AI-assisted, AI-powered, jak sobie ktokolwiek to nazwiemy. No bo do tej pory zawsze, wiecie, mówiło się, czym jest architektura. Jedna z definicji mówi, dobra, to jest zestaw decyzji trudnych do zmiany. Dzisiaj żadna decyzja nie musi być trudna do zmiany. To jest kwestia prądu i przemielenia trochę danych w modelu. Oj, trochę chyba. Wiesz, rzucam troszeczkę tutaj... Taki nowy wzorzec palarnia tokenów. No, why not? Kto bogatemu zabroni, jak to mawiała moja mama. To może warto połączyć ze spec-driven, bo spec-driven coś takiego nam ma zapewnić.

Tylko będzie 200 tysięcy linii kodu na przykład albo milion linii kodu. No nikt tego nie przejrzy w żaden sposób, tak? I teraz pytanie o to, kto bierze to ryzyko na klatę. Ryzyko to jest jedna rzecz, ale to jest właśnie ten kolejny element ryzyka, który ja widzę podczas właśnie wdrażania AI, że znowu wraca ten sam, nie wiem, ja to nazywę marzeniem, że jak specyfikacja będzie właśnie wystarczająco dobra, No to później to już ten system, który powstanie, to jest tylko szczegół implementacyjny. Jest wielu analityków, którzy, przynajmniej tak w tym środowisku, ja to często widziałem wcześniej, że programiści to oni tam nie do końca się znają na tym wszystkim, tak naprawdę to analiza jest najważniejsza, a programista to powinien być tylko właśnie taki, jak to nazywałeś, kompilator.