Case Study: Agentic SDLC w Open Mercato

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.

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ą.

Teraz jest nowa przygoda i zaczynamy od zera. I w ogóle wczoraj miałem takie mega fajne uczucie, takie przemyślenie, jak tak stanąłem i zobaczyłem te 100 osób, To wielka zasługa Patryka i Maćka z naszego teamu, bo to oni zorganizowali ten hackathon i dzięki nim są tutaj ci wszyscy ludzie, ale moje takie olśnienie było takie, że rok temu to byłem ja i pięć commitów, nie? O tym czasie mniej więcej, może tam dziesięć, nie? Ale nic nie było, nie? A teraz kurczę siedzą ci ludzie i to tutaj budują z nami, więc to było mega satysfakcjonujące i to jest taka przygoda, wiesz, startupowa, siedzimy, kurczę ciśniemy, Robimy wszystko sami. Super, super, super.

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?

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?

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.

My mamy też tak, że w procesie przed wypuszczeniem do naszego kodu mamy przy większej funkcjonalnościach faktyczne testy manualne otrzymane przez człowieka. To może też jest ciekawy temat, dlaczego to tak jest, ale Bardzo dużo rzeczy jest jednak testowane manualnie, nie? Przez wypuszczenie. No i później to wchodzi. Staramy się korzystać, staramy się korzystać z klientami i zbierać od nich feedback, jak to działa. Ja myślę, Patryk, że jeszcze fajnie, jakbyś tutaj powiedział o UI-u, co nie? Bo nawet ten Agent Orchestrator, ja to śledziłem bardziej, wiesz, tak read-only, jak ta funkcja powstawała. I tam mnie zafascynowało, wiesz, jak ty podszedłeś do UI-a, bo Bo tam nagle, wiesz, patrzę w full requesty, tam się pojawiają jakieś super high fidelity mockups, które wyglądają w sumie jak gotowa apka.

Za ciebie kodują inni, więc ty masz więcej czasu, żeby zebrać te wymagania. Ja widzę jak Patryka na przykład właśnie UX czasami jara czy coś, gdzie kiedyś nie miałbyś na to przestrzeni, bo kodowałbyś coś tam i nie miałbyś czasu, nie? Ja myślę właśnie, że to jest fajne, że te granice się zacierają. Zacierają się, nie? Troszeczkę, ale z drugiej strony ja bym dodał to, że widzę, że przy budowie takiego produktu, jak my budujemy, ta wiedza architektoniczna jest bardzo potrzebna. Dokładnie. Słuchaj, właśnie chciałem do tego, już kończę tą myśl, bo strasznie się rozgaduję, ale Zobaczcie, też na pewno to widzicie, dużo CTOsów, osób, które były tak trochę czasami wepchnięte w to, że teraz masz zarządzać, a oni byli ludźmi, którzy kochają technologię, nie?

I powiem więcej, wartość takiej inżynierii jest jakby dziesięć razy jeszcze wzmocniona przez to, że z tym agentem po prostu nie tracisz czasu na te pierdy wszystkie wokół. Ty się już skupiasz wtedy na tym. A z drugiej strony, zobaczcie jeszcze to, UX designerzy, graphic designerzy, QA'e albo Scrum Masterzy, project managerowie, Oni też dostają turbo fajne zadania, turbo fajne moce, bo teraz jak jesteś na przykład, to w ogóle bardzo często się pomija. Paterny pracy agentów, jak chcesz zrównoległać zadania. Patryk wczoraj miał o tym fajną prezentację na Hackathonie. Jest ileś tam różnych wzorców i tak dalej, ale na przykład zadania w projekcie, masz te epiki, masz specki, dzielisz to na taski, jak to najbardziej optymalnie zaimplementować, żeby było jak najszybciej, bez konfliktów i tak dalej.

Ogólnie nasza idea skilli jest taka bardzo pragmatyczna i ona wykuła się w toku pracy nad po prostu bardzo dużym projektem, jakim jest Open Mercato. Więc my nie chcemy konkurować skillami, które są dostępne na rynku, które są bardzo ogólne. Które, wiesz, są skille Matapokoka bardzo popularne, nie? Jakieś tam grillmi, coś tam o różnych metodykach pracy są skille i tak dalej. One są super i zachęcam, żebyście z nich korzystali, ale nasze skille to są bardziej przemyślane jako takie maszyny w fabryce, Jak chcesz zrobić fabrykę do software'u, to biorąc te skill'e, które myśmy wytworzyli i je dopasowując, bo ja też jestem zwolennikiem tego, co Patryk powiedział, że te skill'e muszą być dopasowane do projektu.

Każdy był totalnie inny. W weekend. Jedne były przetestowane, inne nie były. Ktoś zrobił sobie code review sam, albo ktoś mu zrobił, inne nie. I myśmy mieli z tym bardzo duży kłopot i myśmy skilla zaczęli normalnie z takiej pilnej potrzeby, Wdrażach do tego, żeby usystematyzować pracę. Mnie na przykład osobiście strasznie denerwowało to, że co, że ja mam za każdym razem, jak robię pool, sorry, code review, to ja mam tam temu agentowi pisać, zrób mi code review i zwróć uwagę na to, na... Wiesz, na pewnym etapie tam miałem w notatniku prompty i je wklejałem, ale nie możesz długo tak pracować, co się nie da. A zresztą ja robiłem taki prompt, a Patryk robił inny prompt. I za pomocą skilli żeśmy totalnie wyeliminowali taki problem.

Cezar to jest Patryka sidequest, nie? Mój sidequest to są te skille. Wiesz, rozwijamy to gdzieś tam obok, Ale to bardzo chwyta, bo jest bardzo duża potrzeba, nie? Właśnie tak się zastanawiałem, jak to procentowo się rozkłada, nie? Ile w rzeczywistości pary idzie właśnie w te takie rzeczy, które trzeba budować dookoła, chociażby w Cezara, a ile to jest faktycznie taki development pod kątem, wiecie, jakby czasu i energii, nie? Włożony, żeby te funkcjonalności, powiedzmy, dla tych moich partnerów, którzy będą implementowali apki dla klienta, dostarczyć. Wiesz co, ja tu może tylko powiem, bo ja kiedyś bardzo dużo czytałem Technology Radar, nie? Tam, wiesz, Martin Fowler i ten jego team. No super jest ten raport, pewnie większość słuchaczy zna, no bo to jest taki klasyk. I oni bardzo mocno w pewnym momencie pchali taką metodę prac product teams, że robisz takie teamy produktowe w organizacji, żeby podzielić

Pięćdziesiąt pól requestów z tego co widzę otwartych i cały czas tam kurczę wiesz, ludzie kontrolują. Zaraz o tym porozmawiamy. A tak szybki off-top, bo Patek wspomniałeś hasło commandos. Bardzo mi się podoba taka metafora typu, okej, deweloperzy się dzielą na de facto dwie grupy. Komandosów i okupantów, nie? Komando wchodzi. Komando wchodzi z butami przez drzwi. Nieważne, jakie jest problem, po prostu wywalają te drzwi i idą dalej. A za nimi spokojnie wchodzą okupanci. Taka piechota, która zaczyna tak naprawdę uproduktować te rzeczy, które komando projektowało. To poczekaj, muszę tutaj zdradzić anegdotę jedną, bo mieliśmy... Z Cezarów mieliśmy w ogóle trzy wersje. Teraz jest trzecia. Pierwsze te się były, skupiały się na czymś zupełnie innym. I ja podesłałem Petrowi do przetestowania Cezara wersję numer dwa. I to po jakimś razie się mówi, Patryk,

A ja tego nie umiem zainstalować. Nie jestem w stanie tego zainstalować. To jest tak skomplikowane, że ja nie wiem, o co chodzi. To już widać, czy to u was jest komanda, a które są komandą. Ja mówię, dobra, hold my beer. I po weekendzie instalowało się tylko jedną komendą. Znaczy w ogóle się nie instaluje, tak naprawdę. No tak, wywołujesz jedną komendę i pyk. On wykrywa ci na kompie wszystkie twoje kodnik-agenty, łączy się, sprawdza czy masz GitHub CLI, podłącza się pod to sami. Jak mi to zaimponowało, Patryk, że nie ma tego instalatora, nie? Mówię, nie, no teraz to już kurde, to będzie hit, nie? I adopcja była w dobę, nie? Ktoś się przerzucił ze swoich tam jakichś zwipecodowanych rzeczy na w dobę, no. Ale dobra, to łącząc te wszystkie fakty, z tej pierwszej fazy przychodzę ze specyfikacją, w tej drugiej fazie mam narzędzie, które mi tak naprawdę dostarczy implementację tego wszystkiego, no i teraz trzeba tak naprawdę to jeszcze ocenić.

Zresztą to ja może powiem, bo to jest bardzo ciekawy temat. Ogólnie kontekst inżynieringiem u nas to zajmuje się w dużej mierze Patryk i on zaczął jakby tą inicjatywę, ale ja jakiś czas temu miałem okazję nad tym chwilę popracować i w związku z tym właśnie chciałem powiedzieć o tym... Najnowszych odkryciach. Na najnowszych odkryciach na tym polu, ponieważ jest to bardzo duże pole minowe, tak bym powiedział. Myśmy zaczęli prosto. Agents MD. Każdy agent go czyta. Potem odkryliśmy, że te agenty są takie sprytne, że jak masz podfoldery, czyli na przykład Monorepo z pakietami, to jak umieścisz Agents MD w tych podfolderach, to on będzie je czytał, jeżeli będzie dotykał tych folderów, więc już fajnie można kontekst trochę zacząć oszczędzać.

Agent MD ma ograniczenie chyba do 65 kilobajtów tekstu, czy coś takiego, 40, nie pamiętam. Od każdej agenty trochę inaczej. Ale jest ograniczenie, to jest najważniejsze. Jest ograniczenie, więc wiesz, jak mieliśmy w tym pliku napisane, że tam na przykład nazwy tabel w bazie danych to zawsze są w liczbie mnogiej, a nazwy modułów Pojedyncze, a jak na przykład robisz pole ID w tabelce, to ono ma być UID-em, a nie INT-em. No takie po prostu, wiecie, bazowe kurde standardy, a potem jeszcze trochę nadbudowane, że wzorzec projektowy, jakiś command, RBAC, szyfrowanie jakichś rzeczy. To to na razie tam działało dobrze dosyć, ale zaczęły dochodzić moduły. I teraz na przykład doszedł moduł Workflow. Patryk dodał kiedyś taki moduł zajebisty do robienia właśnie workflow'ów, zadań.