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

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.

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?

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.

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.

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 mi jedna odpowiedź po głowie, potencjalna, tak patrząc kontem oko na pioty, ale jestem ciekawy jakby waszego podejścia. Czemu własne implementacje z Kili? Wiesz co, wydaje mi się, że przez to, że chcemy mieć kontrolę nad tym, to jest jedna rzecz i dwa, chcemy rozumieć bardzo dobrze cały ten proces. Ten proces, myślę, że mega ewoluuje podczas tego, jak tworzymy Open Mercato i tworząc ten Ten nasz setup skilli, my tak naprawdę mamy pełną wiedzę o tym, co się będzie w danych krokach działo i mamy pełną kontrolę też nad tym, jak później nasi klienci budują na bazie Open Mercato, korzystając z tych skilli. Czyli nie dość, że mamy kontrolę w swoim procesie, to też dzięki temu, że my te skilli wydajemy w open source, mamy kontrolę nad tym, jak na naszym oprogramowaniu później jest coś nadbudowywane.

Ale tak z perspektywy powiedzmy takiego totalnie zewnętrznego dewelopera, który nie pracuje w ekosystemie Open Mercato, to znaczy mniej więcej tyle, niestety nie wezmę tych waszych skilli, bo są dopasowane do waszej architektury. Wiesz co, faktycznie dużo osób tak mówiło na początku, ale jakiś czas temu, myślę, że to dwa miesiące, trzy miesiące temu, myśmy te skille totalnie wyciachali z Open Mercato i one są dostępne w osobnym repo. Open Myślnik Mercato łamane na skills na Githubie. Zachęcam każdego, żeby sobie na to popatrzył. Te skille są totalnie jakby agnostyczne technologicznie. I one co więcej są zrobione tak, że jak je zainstalujesz i odpalisz tam taki pierwszy inicjacyjny skill, który się nazywa Setup Agentic Pipeline, to one wykrywają Twój tekst, czytają Twój cały kontekst, jakie masz coding standardy itd.

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.

Jest Cezar, chociaż Cezar byśmy chcieli go utrzymać typowo open source'owego, to jest też tool, który powstał z potrzeby, ale jeżeli nie moglibyśmy jeszcze na zbytce się zatrzymać, To podejście Spaced Event Development ma swoich gorących zwolenników, ma swoich gorących przeciwników. Gorąca debata jest, tak? Ja wiesz, debat w tym naszym środku jest dużo, nie? Ale serio? Jest taka debata? Jest debata? Tak, tak. A SDG jest debata? Oczywiście, że tak. Tutaj nie ma o czym debatować, słuchajcie. No właśnie. Kiedyś były tematy typu taby czy spacje, dzisiaj się będziemy naparzać o to właśnie, czy wiesz, czy stosować specyfikację, czy nie, czy przeglądać ten kod manualnie, który powiedzmy ten agent wypluje, czy nie. Linii podziałów jest zaskakująco dużo. Ale o jeden aspekt tych specyfikacji chciałem się dopytać, bo stworzyć specyfikację, taki powiedzmy start, żeby ten agent mi dostarczył pierwszą wersję, jakby ja nie mam wątpliwości.

Mogę to wykorzystać do tego, żeby niemalże doprowadzić to do produkcji, mogę to wykorzystać dalej, żeby jakby manualnie to rozwinąć. Tu różne są podejścia. To, co mnie interesuje, to jest dalszy cykl życia tej specyfikacji, bo dostarczamy funkcjonalność, ale teraz pojawiają się zmiany. Ignacy, jakie macie podejście do tego? Czy ktoś, wchodząc do Open Mercato, przy zmianie tych, powiedzmy, założeń, wyjściowej specyfikacji, będzie pracował nad tą specyfikacją, która kiedyś była? Po prostu będzie ją edytował tak, żeby teraz agent zobaczył tego DIF-a i zaimplementował mi właśnie tę różnicę? Czy wersjonujecie tę specyfikację, czy zapominacie o tej specyfikacji i teraz, że tak powiem, specyfikujemy tylko i wyłącznie tę różnicę, o którą nas klient prosi? Różne są podejścia, więc strasznie jestem ciekawy, jak wy do tego podchodzicie. Tutaj może też musimy wyjaśnić jedną rzecz, że my jak budujemy Open Mercato to oczywiście mamy inną perspektywę niż później jak klienci korzystają, bo klienci instalują sobie Open Mercato po prostu proste polecenie npx createmercatohub i oni dostają taką standalone aplikację, gdzie wszystkie nasze moduły są jako zależnie zewnętrzne.

I tu właśnie korzystając z tych specyfikacji wcześniej, stworzyłbym sobie taki bardziej wysokopoziomowy widok tego, jak to działa i dopiero na tej bazie podejmował decyzję w tej nowej specyfikacji. Jak ją tworzyć? Myślę, że to jest w ogóle problem, z którym się wiesz, jako branża zderzymy w najbliższych dwóch, trzech latach. A to też jest problem tego, co chcesz przyjmować do systemu, bo tak jak my pracujemy w open source, mamy tych 140 kontrybutorów, mamy kilkaset requestów na release, release wychodzi raz na dwa tygodnie. Trzeba podejmować decyzję, czy my chcemy to wziąć do systemu, czy nie. Tempo przebywania właśnie tego kodu jest bardzo duże, więc analizowanie całego DIF-a jest praktycznie niemożliwe. No trzeba sobie to powiedzieć szczerze, że nie ma możliwości usiąść i przeanalizować to wszystko. Trzeba mieć jakieś mechanizmy, które pozwolą ci wyciągnąć esencję tego, jak to wpływa, gdzie są zmiany w tym naszym systemie, jak to może oddziaływać na przyszłość, jakie ścieżki nam to blokuje, to sobie zwizualizować i na razie tego dopiero podejmować decyzję.

Ego, zakładając, że mamy taką specyfikację przygotowaną, rozmasowaną, wiesz, dokładnie co, gdzie, jak ma zostać zrobione, rozumiem, że teraz taką specyfikację wrzucam do tego Cezara, o którym wspomnieliście, czyli na przykład do Cezara jako orkiestratora napadeckich agentów i co? I czekam na wynik, ewentualnie na problem. To, co my jeszcze robimy jako taki krok pośredni, to jest weryfikacja innym modelem. Modele, może żart, ale lubią się krytykować nawzajem. Szczególnie między antropikiem a open AI-em jest jakaś taka miłość wzajemna. Możliwość wytknięcia problemu konkurentowi. Wynika z badań, że te same modele nawet z tej samej rodziny mają jakiś tam bajas, więc warto jest sobie je sprawdzić właśnie, żeby inny model wyszukał luk w tym dokumencie i wytchnął nam, co tam można jeszcze poprawić.

Czasami warto nawet to zrobić kilka razy, zobaczycie jak sobie popróbujecie, że tam się zawsze coś znajdzie do tego, co można jeszcze ujednolicić. No i później to faktycznie zapuszczamy. My korzystamy z tego narzędzia naszego Cesar, które pozwala pod spodem tak naprawdę uruchamiać cloud code'a, codex'a, jaki tam open code'a, API, jaki tam tool korzystacie. I Cesar wywołuje te nasze style. W dwóch słowach, czym jest Cesar? Bo ta nazwa tu, wiecie, wielokrotnie podała. Jak ktoś, że tak powiem, śledzi was na LinkedIn'ie, to pewnie wie, ale dla osób, które nie miało styczności? Ja bym powiedział, że CSR jest takim kokpitem zarządczym, może tak to można nazwać, agentami i on pozwala z jednej strony łatwo sobie wizualizować dużą ilość zadań, które realizowaliśmy, a z innej perspektywy pozwala uruchamiać te nasze skill-e, czyli on jest tak skill-oriented,

Tylko jeden to jest wiesz jakby CRM i Open Mercato, a kilka rzeczy dookoła tak naprawdę, które wam usłabniają pracę. Tak, no właśnie to chciałem powiedzieć, że my te problemy dla siebie rozwiązujemy. Mamy takie podejście, że lubimy open source. Ja się też wobec nas bardzo, dzięki Petrowi, wkręciłem tak naprawdę. Tytule chcemy po prostu dawać, korzystać do naszego community. Mamy też fajny feedback do tego, jak ludzie z tego korzystają i też usprawniamy to dla siebie, dzięki tej społeczności całej, która z tego korzysta. Więc zaczynamy od naszych problemów i później się dziwnie okazuje, że inni ludzie też mają podobne problemy. To jest magia tych czasów, które są teraz, że wchodzisz na pole, na którym jeszcze mało jest rzeczy, mówię o engineeringu i okazuje się, że dla mnie takim odkryciem jest to, że ja zawsze mam takie myślenie, że to, co my robimy, to jest absolutnie nic ciekawego.

To, co dostarczasz na mniejsze produkty, bo wtedy jest ten ownership, wiesz, możesz te wydania robić takie częste i tak dalej. Nam to bardzo też dobrze działa, że my dzielimy to, co robimy w Open Mercato właśnie na podprodukty. Jest CESA, są skillsy, są sandboxy, jest samo Open Mercato, a w Open Mercato jeszcze jest CRM osobno, jest WMS i to są też takie product teamsy. I ja bym na to tak popatrzył, że warto iść w tą stronę i Warto mieć product teamsy, który robi CRM, a robi te skillsy przy okazji part-time, to jest 20% czasu, ale patrzą na to jak na produkt, czyli za ilością tych produktów nie zawsze idzie full obciążenie czasowe,

Może na początku więcej, a potem... Tu też są takie side-questy, że wpadamy na to, że możemy sobie odsłonić pracę i tak naprawdę odblokować sobie jakieś znowu kolejne zasoby do tego, żeby poświęcić je na samo Open Mercato, więc deployujemy tam jakiegoś commandosa. Który tam przez tydzień załóżmy tylko to robi, żeby nam odblokować resztę zespołu, żeby im ułatwić pracę. I tak też było z Cezarem, z tą wersją, która jest teraz, że tam core tego wycinaliśmy przez trzy dni. Ja siedziałem trzy dni i budowałem core i później na tym jeszcze Piotr nabudował i tak właściwie w tydzień powstało taki zalążek tego, jak z tego korzystamy. A później już doszło community i też nasze kolejne pomysły i to już sobie nabudowujemy w trakcie.