Case Study: Agentic SDLC w Open Mercato

Dzień dobry. Better Software Design to podcast o projektowaniu oprogramowania. Wraz z moimi gośćmi rozmawiamy o architekturze, szczegółach implementacyjnych i wyzwaniach z tym związanych. Jeśli interesujesz się tworzeniem oprogramowania, to ten podcast jest właśnie dla Ciebie. Zapraszam na odcinek. Nie ma w IT chyba obecnie gorączszego tematu niż AI SDLC, AI Assisted SDLC, czy jak to tam różne osoby nazywają.

I chyba nie ma lepszej okazji, żeby porozmawiać o tym na hackathonie, gdzie tak naprawdę prawie chyba setka osób, jeżeli mnie tutaj Patryk nie myli, ta informacja, którą mi podrzuciłeś, próbuje właśnie z agentami dostarczyć coś do Open Mercato. A moimi gośćmi dzisiaj będzie Piotr Krawatka i Patryk Lewczuk. Witajcie. Cześć, cześć. Cześć, witajcie. Słuchajcie, w moim bąbelku LinkedIn'owym to wpisy o Open Mercato i od was to po prostu zalewają i wiecie, uola. Ale zakładam, że część osób, które słuchają mojego podcastu może was nie kojarzyć. Opowiedzcie, czym się zajmujecie i kim jesteście? Cześć, jestem Patryk Lewczuk. Ja do Open Mercato dołączyłem praktycznie na początku. Zacząłem budować razem z Piotrem ten produkt i zajmuję się w samym Open Mercato dwoma rzeczami. Z jednej strony pracuję przy produkcie i dobudowuję kolejne elementy.

Zajmuję się też, myślę, że o tym dzisiaj pogadamy, takim harnessem i tym, jak ręce czytają to repozytorium. A z drugiej strony już pracuje z klientami, także pomaga im to wdrażać, rozmawiamy, co oni by potrzebowali w tym produkcie, żeby móc na tym produkcie pracować. Forward deployed engineer. Tak, tak, tak. I nie wiem, czy jakby to hasło mi trochę tak średnio podchodzi, bo... Ale tak ta robota wygląda, że faktycznie z jednej strony się jest u klienta i zaraz wieczorem już się siada i coś tam do tego produktu można jako feedback dorzucić, więc to w ten sposób działa. Cześć, ja się nazywam Piotr i założyłem Open Mercato rok temu w ogóle, Mariusz. Wyobrażasz sobie, że to już rok przeleciał, 10 września i właśnie mega się cieszę, że udało nam się zbudować zespół świetnych inżynierów.

Patryk jest jedną z pierwszych osób, które Do nas dołączyły. No i wiesz, na początku challenge był taki, czy się w ogóle da zrobić duży system, korzystając tylko z agentów do kodowania bez pisania kodu ręcznie. Okazało się, że się da i że przy milion osiemset linii kodu chyba przekroczyliśmy, to nadal wiesz, się trzyma kupy i co więcej ludzie tego używają i rozwijają. Mega fajna przygoda. No i tak tutaj dziękujemy Ci za zaproszenie do podcastu i mam nadzieję, że nam się uda trochę powiedzieć więcej o tym, jak to zbudowaliśmy. Bo to tak skromnie się przedstawiłeś, jak na osobę, która ma za sobą Diwantę, Kostaka i parę innych ciekawych tematów, które grzeją na LinkedIn i w biznesie. Ale słuchaj, to już wszystko za mną.

Odpaliliście maszynę i zaczęło się toczyć. No tak, tak. Toczyliśmy to cały czas jeszcze pchami, nie? Także wiesz, skromnie, bo my tu jesteśmy w ogniu po prostu walki, wie. Ja jestem bardzo zobowiązany, bo tutaj jesteście rozchwytywani i mamy tutaj dosłownie chwilę, żeby porozmawiać i ponagrywać. Natomiast wiecie, hasło Open Mercato, zakładam, że części osób może niewiele powiedzieć. Co to w ogóle jest i skąd to się wzięło? Jakie problemy rozwiązuje? Słuchaj, Open Mercato to na początku był framework do budowania aplikacji biznesowych, czyli chcesz na przykład zbudować CRM, ERP albo dowolną inną aplikację, która ma jakiś taki backend, gdzie się logujesz. Są różne uprawnienia, role, całe to RBAC, zarządzanie, wiesz, uprawnieniami, funkcjami, dodawanie nowych modułów, czyli taki framework, coś jak, nie wiem, Retool.

To brzmi jak framework, no. Tak, tak, jak na przykład, nie wiem, jest Retool, nie? Część osób pewnie kojarzy, taki soft do budowania internalowych apek. To coś takiego, tylko open source na takich bardzo zaopiniowanych pozytywnie technologiach, czyli TypeScript, Next.js, Postgres. I to jest jakby jedna część tej historii. Do tego jest druga bardzo, bardzo, bardzo ważna i taka nierozerwalna, czyli te apki, jak chcesz robić tego CRM-a, ERP-a, inną backendową apkę, to robisz ją w 100% agentami. I my jesteśmy na to jakby przygotowani od dnia zero, czyli kontekst, o którym pewnie Patryk za chwilę dużo więcej powie, jest bardzo rozbudowany, przygotowany, ustrukturyzowany, skillsy, to wszystko tam już siedzi, więc wpisujesz prompta i dostajesz bardzo fajny efekt.

I to jest jakby najważniejsza część tego, co my robimy. Ale to jest już teraz jakby jeden z produktów i w międzyczasie przez ten rok powstało jeszcze kilka innych. Powstał Cesar, czyli taki open source'owy tool do automatyzacji i odpalania wielu sesji kodowania. Patryka dziecko, więc też nie chcę tutaj za dużo opowiadać, bo zaraz pewnie pogadamy. Mamy open source skills, które programiści mogą używać, żeby w taki podobny sposób jak my budujemy Open Mercato samemu budować projekty, czy to na Open Mercato, czy swoje własne. No i wiesz, jeszcze do tego, każdy z tych modułów, które są w Open Mercato, CRM, WMS, katalog produktów, moduł sprzedażowy, moduł planowania czasu pracy, agent orchestrator, że możesz takie agenty biznesowe tworzyć, no wiesz, tych modułów jest ponad dwadzieścia ileś, to każdy w sobie w sumie jest produktem też, nie?

Bo tam on musi... Bo to jest osobna domena w ogóle do rozwiązania. Jak wspominasz WMS-a, moje przycięcia z WMS-ami jest takie, że to są ogromne systemy do zarządzania często ogromnymi magazynami. Słuchaj, to jest w stu procentach prawda i my też nie porywamy się jakby z motyką na słońce, bo jakby naszą ideą działania w Open Mercato jest też od razu posiadanie partnerów i kontrybutorów. Razem to jest 140 osób, które coś do Open Mercato kontrybuują. I wiesz, jeżeli ktoś zna się super na CRM-ie, Mamy na przykład u nas w teamie Oliwię Maczka, którzy w core teamie są i super zaprojektowali CRM. Mamy też partnera, który super ogarnia biznesowo CRM i oni razem współpracują, żeby ten moduł jako produkt rozwijać.

I oni robią tylko to. Mamy też taki podział domenowy. Myślę, że to jest bardzo fajne, bo nie jesteś w stanie zrobić wszystkiego. Tak jak mówisz, WMS? Kurczę, temat rzeka. Przede wszystkim takiej domenowej wiedzy będą brakowało w tych wszystkich elementach, żeby to zbudować, więc partnerzy, którzy tą wiedzę mają, to oni się tym zajmują. A my dbamy o to, żeby to się jeszcze architektonicznie spinało na koniec. Jak miał zaryzykować takie jednoznaniowe podsumowanie tego, co ty powiedziałeś, to bym powiedział, że Open Mercato jest takim narzędziem do budowania wewnętrznych systemów opartych o pewien framework, ale z takim zacięciem AI-first. Tak, tak można powiedzieć i dla nas właśnie bardzo ważna jest ta inżynieria tego frameworka, bo wiesz, problem jaki z AIM był w takiej pierwszej fali zachłyśnięcia się, że to jest takie super, no to chyba każdy się z tym spotkał, no to te vibe kodowane apki.

Robisz apkę, ona jest super, działa, a za dwa dni ulega implozji i albo wiesz, całkowicie się sama pod swoim ciężarem zapada, Albo nikt nad tym nie chce pracować, nie? A my mówimy w Open Mercato jest jednak trochę inaczej, dlatego że myśmy zaczęli, zaczęliśmy od zaprojektowania frameworka. Każdy z nas, Patryk, ja, Maciek i inne osoby z zespołu pracowali z jakimiś systemami takimi dużej klasy, nie? Na przykład Patryk dużo z Oro Commerce, ja na przykład dużo pracowałem Z Magento, z jakimiś CRM-ami i tak dalej. I wiesz, chodziło nam o to, żeby wziąć z tych wszystkich aplikacji te takie najlepsze smaczki, to co tam działało, bo w każdym takim dużym projekcie są rzeczy, które działały super i są rzeczy, które byś najchętniej ogniem wypalił, nie?

Czyli wiesz, ktoś dodaje funkcję i tak dalej, my sprawdzamy, czy to nic nie psuje. Jak coś na przykład, wiesz, Zaczyna być problemem w jakimś obszarze, no to tam od razu effort, refactor idzie i tak dalej. I to jest fajny podział, że wiesz... To jest ten effort i drugi effort to jest utrzymanie tej inżynierii kontekstu. Bo to jest tak naprawdę proces cały czas, od samego początku aż do teraz, to jest proces i cały czas mamy nowe pomysły, jak to dalej rozwijać. A to jest coś, co będę chciał tutaj, wiecie, żebyśmy dotknęli, nie? Bo masa ludzi kontrybuuje, a jednocześnie podejrzewam, że no chciałbym utrzymać taką, wiecie, wizję, w którą stronę w ogóle ten produkt będzie płynął. Ale zanim do tego dojdziemy, bo kilka rzeczy tutaj ciekawych wspomnieliście. Czy tutaj ktokolwiek w ogóle w tych systemach pisze cokolwiek z palca?

Nie wiem, czy to był sierpień, czy wrzesień. Pamiętam, że jak we wrześniu siadałem do tego projektu, stworzyłem repo na GitHubie itd., to mi się załadował chyba kodeks 5.1 albo 2. Tak zapamiętałem po prostu to. I pamiętam też, że przed wakacjami wtedy Ja pracowałem nad innym projektem Open Source, takim medycznym, Dr. Doc. I tam zacząłem z kolei tamten projekt na chyba GPT-4.1, no takim wiesz, wczesnym modelu. I on fajnie robił jakieś pojedyncze ekrany, ale jak chciałeś coś większego zakodować, to, to, to, to... Gubiło się to wszystko. Gubiło, nie? I rok temu właśnie ten 5.1 to był już, dla mnie to był obszałom, że puściłem jakiegoś takiego skomplikowanego dosyć prompta, że właśnie zacznę budować ten framework.

No postęp w tej branży jest po prostu niesamowity. Niesamowite to jest. Tak, to ma plusy i minusy, bo trzeba być ciągle na topie i to jednak zajmuje dodatkowe sekrety naszego... Ale wiesz co, to co Patryk przed chwilą powiedział, że ten kontekst był taki ważny, to my idziemy w ogóle w drugą stronę stary z tym. No to jest ciekawe. W sensie, że dzięki temu kontekstowi Open Mercato działa coraz lepiej na coraz słabszych modelach, a nie w drugą stronę. Czyli nie jest tak, że system ci się rozrasta, to ty musisz zawsze używać W ostatnich miesiącach udało nam się bardzo mocno zoptymalizować pod takie modele jak na przykład Luna. Działa tak samo dobrze jak na Solu i na Astrze i to mamy po prostu benchmarki, wiesz, że to tak jest.

Wtedy koszty idą znacząco w dół. O, tak powiem wam, słucham was i widzę, jak wy jesteście w to wkęceni. Ale wróćmy do początku. W jaki sposób w ogóle dzisiaj wy dewelopujecie taki system właśnie jak Open Mercato? Ktoś ma pomysł w głowie, nie wiem, Piotr na przykład, jesteś na spotkaniu z klientem, pojawia się jakaś idea, macie to w Open Mercato? Nie, nie mamy, ale możemy szybko dorobić. I co się dzieje? To super, jak ty byś to właśnie opowiedział, bo słuchaj Mariusz, ja mam taką sytuację, że ja właśnie z klientami oczywiście mam bardzo dużo kontaktu, ale to raczej Patryk jest tą osobą i nasz dział Field Engineering, który faktycznie ma tę sytuację, co ty mówisz, że jesteś na spotkaniu, pojawia się pomysł, nie? I co wtedy? Może być fajny właśnie taki, wiecie, push startowy do jakiegoś publicznego feature'a. Real case, firma z branży regulowanej.

Właśnie tak jak powstał, cała funkcjonalność powstała agent orchestratora, czyli takiej orkiestracji agentów, która jest ułożona na kręgosłupie faktycznie deterministycznego workflow'u wewnątrz aplikacji. I tam możemy sobie wywoływać agentów jako Takie krocuszki, czyli deterministyczny workflow mówi, poproszę inteligencję, bierze model agenta, robi jakieś zadanie i to idzie z powrotem i wykorzystuje tę informację, żeby deterministyczną akcję w systemie wykonać. Tak to w skrócie działa. No i teraz cała idea tego i pomysł, i potrzeba się pojawiła właśnie od naszego klienta, który mówił, że my byśmy chcieli zautomatyzować cały proces. Tam był proces rozpatrywania wniosków, może nie wchodząc w szczegóły.

Bo tego nie możemy zrobić, ale był proces rozpatrywania wniosków, no i wiadomo, tam było kilka osób po drodze, które musiały zrobić pewnego rodzaju research i to w materiałach na zewnątrz firmy i w materiałach wewnątrz z różnych systemów i chcieli to całkowicie zautomatyzować tak, żeby agenty to realizowały. Więc siedzieliśmy na paru warsztatach i zbieraliśmy od nich wymagania i te wymagania później ja przerabiałem. Ja też mam taką tendencję, że bardzo dużo dyktuję, więc zbieram myśli tak w formie tekstu, dyktuję i układam to z agentami w formie ustrukturyzowanych elementów wymagań i później te wymagania sobie Przekładamy na faktycznie elementy systemu. I do tego ja w głowie układałem architekturę, bo takich systemów nie ma za dużo, nie ma gdzie podpatrzeć, jak to powinno wyglądać.

Dużo się bardzo ciekawych tam problemów po drodze pojawiło, bo jeżeli mamy czata, załóżmy AI-owego, no to ten czat jest wywoływany, ale natomiast poprzez człowieka, poprzez interakcję. Jeżeli agent coś robi w systemie z poziomu czata, to zawsze możesz zadanie jego przypisać do człowieka. Jeżeli mamy cały proces zautomatyzowany i on jest np. uruchamiany poprzez jakąś akcję w systemie, jakiś trigger, no to ten agent sobie już pracuje niezależnie od człowieka. W organizacji regulowanej na pewno się spodziewacie tego, że musimy mieć cały trace log tego, co się dzieje. Więc agent musiał dostać swojej identity, czyli musiał być na poziomie użytkownika w systemie. Musieliśmy wiedzieć dokładnie, który to jest agent, w jakiej wersji, jakie ma uprawnienia, każdy agent ma swoje role.

Jak się porusza po systemie, to odkładamy wszystkie informacje po drodze i to trzeba było tak naprawdę wymyślić, wykombinować i zaprojektować. I to w formie cały czas takiego dyktowanego procesu i researchu z internetu, czy już coś mamy, czy już gdzieś ktoś korzysta, czy już gdzieś są jakieś patterny, które faktycznie występują. I to jest taki element zbierania tak naprawdę wymagań. I później pewnie ci ciekawi, co się dzieje dalej. No tak, bo to wiesz, byś miał jak zostawić dobrych lat, nie? Teraz mamy już dosyć pokaźny plik z wymaganiami i to sobie rozkładamy na fazy tak naprawdę kodowania. I to będzie tak. Mamy już podzielone, jakie elementy byśmy chcieli stworzyć. Najpierw budujemy cały szkielet tej architektury i tutaj zaczynamy iść w tworzenie specyfikacji.

My pracujemy w Spectrum Development i to się nam bardzo sprawdza. I te specyfikacje traktujemy jako taki właśnie element tej inżynierii kontekstu. Czyli po prostu specyfikacja ma być takim wejściowym kontekstem dla tego agenta, tak o tym myślimy. I sobie wybieramy, ok, jak ja bym miał kodować takie zadanie, to co ja bym potrzebował na wejściu wiedzieć takiego technicznego, czyli jaki powinienem sobie taki tech research zrobić z mojej aplikacji z Open Mercato, żeby taki element zakodować. W taki ustrukturyzowany sposób, za pomocą skilla tworzymy taki dokument, Ten dokument później wchodzi do procesu developmentu. Znowu mamy skilla, o których pewnie pogadamy też, które cały ten proces developmentu nam prowadzą. I bierzemy i tworzymy specyfikację. Sam proces tworzenia specyfikacji też możemy oddzielnie omówić, bo to jest spore zagadnienie.

I tam też z naszą projektantką Oliwią dużo nad tym pracowaliście, jakbyś mógł o tym powiedzieć, bo to jest mega ciekawe w ogóle, słuchajcie, bo jest takie jakieś myślenie, że ten software to się będzie sam pisał, nie? A my kurczę znowu tutaj pod prąd, nie? Nie, nie, to tak nie jest, że on się tak całkiem sam będzie pisał, co nie? To jednak human centric jest cały czas proces. No to właśnie najpierw trzeba by było zacząć od Oliwii i powiedzieć o tym, że ona nam zaprojektowała cały design system, aplikacje też gotowe pod to. Raz, żeby gotowe pod to, żeby agent tylko czytał, a dwa, mamy znowu już takie, takie skille i nawet statyczne czeki, które weryfikują, nie? Czyli jest ta pętla zwrotna dla agenta, on może stwierdzić, nie trzymasz się tego naszego design systemu, weź popraw, nie? I specyfikacje, i design, i pętla feedbacku.

Dokończę tą jedną rzecz i właśnie na podstawie tego teraz brakowało nam, dobrze, że Piotrek o to zahaczyłeś, bo w tym momencie zaczęło nam brakować takiego kroku pomiędzy specyfikacją a kodowaniem. Żeby zweryfikować, czy to będzie faktycznie od strony takiej użytkownika przydatne. I tam wymyśliliśmy zarówno coś takiego, żeby tworzyć bardzo szybko, to znaczy szybko w formie 30-minutowych na przykład takich developmentów agentowych, Klikalne już ekrany w Design Systemie Open Mercato, one w HTML-u powstają po prostu, nie? Ale są tak ułożone, że są ułożone tak naprawdę w klikalną apkę i my na tym HTML-u możemy sobie dodawać komentarze. Tam jest cała struktura tej naszej aplikacji komponentów odwzorowana, więc możemy na każdy komponent sobie dodać komentarz.

Słuchałem prezentacji jakichś tam z Y Combinatora i mówili, jak wygląda teraz praca Zeja, nie? I tak sobie myślałem. Ale wiecie co, ja tak po roku W projekcie mam dużo bardziej elastyczne myślenie o tym wszystkim i ja widzę, że dla każdego jest miejsce w projekcie zarządzanym przez człowieka, ale takim kodowanym przez AI, dlatego że tu są bardzo różne aspekty potrzebne i u nas przez Core Team, Open Mercato i przez kontrybutorów, ta lista jest 140 ponad osób, To się przewijają osoby o naprawdę bardzo różnych zainteresowaniach, backgroundach i tak dalej.

Chodzi o urobek, kontekst, co tam jest tworzone itd. No to dobra, milion tokenów, jeden dzień pracy programisty. A przecież, żeby zrobić duży system, to kiedyś ci programiści pracowali w zespołach po x osób przez miesiące czy tygodnie. Czyli to były miliony tokenów, tak przekładając na to, razy wielkość zespołu. I zobaczcie, teraz ten milion tokenów jesteś pewnie w stanie wykorzystać, jak dobrego prompta zapuścić, to w pół godziny albo w godzinę, no to zależy od tam modelu i tak. Czyli jesteś w stanie to po prostu przyspieszyć. I to ludzi oszukuje bardzo. Bo myślisz, że przyspieszyłeś i że to już jest wszystko gotowe, ale to właśnie nie jest prawda.

Jak robisz duży system, taki poważny, to ty musisz robić ten proces składany, czyli nadbudowywać ten proces, żeby on potrafił ileś 10 milionów tych tokenów Tak je wykorzystać, żeby powstał z tego proces. Czyli na przykład, no nie wiem, wykorzystywać pętlę do kodowania, ale tam robić jakąś weryfikację. Dzielić zadania na równoległe agenty, ale tak jakbyś to robił w zespole. Nie dałbyś dwóm członkom zespołu konfliktujących się zadań, nie? No bo, no efekt murowany, że masz na gicie konflikt i jeszcze się pokłócili, nie? Do tego. Więc tutaj może by się nie pokłócili, bo to są agenty, ale konflikt by był. No i mnóstwo jest takich aspektów, że musisz tą starą inżynierię trochę przełożyć jednak na tą nową inżynierię i tu się za dużo nie pozmieniało tak naprawdę.

Krótko mówiąc, mam specyfikację takich wymagań funkcjonalnych, niefunkcjonalnych, tak klasycznie. I specyfikacja jest bardziej odpowiedzeniem jak i z jakich tak naprawdę informacji w systemie powinien skorzystać. Żeby agent nie wyciągał tych informacji na bieżąco, tylko żebyśmy mu już spisali to i mieli troszeczkę kontrolę nad tym, co on dostaje na wejściu podczas budowania. I to, co my robimy, to jest przede wszystkim w procesie wytwarzania tej specyfikacji trzeba uruchomić sobie skliz, dociągamy wymagania, Wymagania są analizowane, układane w nasz template. Jakieś tam podsumowanie, rozpisanie architektury, tego jakie będą historyjki użytkownika, czyli co tak naprawdę ten użytkownik będzie mógł na tej funkcjonalności wykonać. To jest robione poprzez taki formuł, że najpierw robimy research w aplikacji, u nas sprawdzamy, które elementy, znaczy agenty robią research w aplikacji, sprawdzają, które elementy tak naprawdę będą potrzebne do rozbudowy.