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.

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?

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.

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.

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.

Rozumiem, że część pewnie tej fazy implementacyjnej to jest jakiś Jakiś harness, jakaś weryfikacja, czy to, co w ogóle wychodzi, jest zgodne z waszymi ustaleniami, ale na końcu jeszcze trzeba podjąć decyzję, czy to tak naprawdę chce włączyć do Core'a. Pochylimy się na ten moment. Piotr, jak analizujesz pull requesty, żeby zmerge'ować do Core'a? To jest, wiecie co, najtrudniejszy element, nie? To jest też powód, dla którego my mamy na przykład otwarte 160 pull requestów w Open Mercato, one tam progresują i pomału są merge'owane, ale nie są merge'owane, wiesz, hurtem, nie? I dokładnie dlatego, no po prostu my to robimy nadal ręcznie w pewnym sensie. To znaczy, wiesz, jak pull request ma 700 plików, bo są takie, a niektóre mają, kurczę, 1000 plików, Też są takie. To właśnie ostatni agent orkiestrator, co nie, miał tyle.

On miał swoje API, swoje formaty JSONa, to też musiało być w tym momencie, zaczęło się rozrastać. Sytuacja po pewnym czasie była taka, że przychodził deweloper, robił sobie Create Mercato App, bo mamy takiego CLI. Od tego się w ogóle zaczyna praca z Open Mercato, tylko o tym powiem szybciutko, bo to nadaje kontekst. Przychodzisz i tak jakbyś robił appkę Next.js, w Next robisz Create Next App, to tutaj robisz Create Mercato App, Dostajesz apkę, ona wciąga przez NPM pakiety Open Mercato, więc możesz cały czas update'ować Open Mercato bez dotykania swojego kodu i Ty w tym repo masz tylko swój kod wciągniętej Open Mercato. I my teraz jesteśmy w takiej sytuacji z tym kontekstem, że nie wiemy, co ten ktoś będzie robił, nie?

Bo ktoś może dodać do CRM-a pole, na przykład do klienta, może dodać nowy moduł w ogóle, jakiś biznesowy, a może chcieć wyłączyć jakiś moduł, albo na przykład w module do zarządzania czasem pracy, jak jest ekran do śledzenia czasu pracy, to zastąpić na tym ekranie jeden konkretny button w reakcie, wszystko inne zachować takie samo, nie? Open Mercato to wszystko umożliwia. Nie możesz takie rzeczy robić. Tylko że ten agent z MG, który dostajesz po Create Mercato App, nie jest w stanie tego wszystkiego utrzymać. I właśnie nasze najnowsze odkrycia, Na polu kontekst engineeringu, które jest polem minowym, są mega, mega ciekawe, bo właśnie zaczęliśmy badać, co możemy zrobić, żeby to zoptymalizować i pod use cases, i jeszcze jednocześnie pod słabsze modele kodujące, bo nam nie zależy na tym, żeby to działało tylko na A3, tylko my chcemy, żeby to działało na tej lunie, a może nawet na jakimś open source'owym QN 27B, czyli takim, co w sumie na MacBooku by mógł chodzić.

I teraz na bazie tych trzech axisów ten skill do budowania dynamicznego kontekstu wybiera konkretne skille, na przykład jest backend development taki skill i potem masz auto create PR jako delivery method i jeszcze masz skill tam właśnie, że na przykład database design. I one są konkretnie już pod Open Mercato zrobione tylko i wyłącznie, czyli zobacz, nie wciągasz wszystkiego, Tylko wciągasz z danej area, z danego obszaru aplikacji to, co tam chcesz zrobić, że np. bazę danych zmienić i potem, że chcesz to dostarczyć jako pull request. I w kontekście jest tylko to. Nie ma żadnych innych rzeczy, Plus tam są takie escape hatche, czyli takie sytuacje, że na przykład zadanie w trakcie się poszerzyło, czyli coś jeszcze by trzeba było zrobić, to on może tam sobie wczytać, jeszcze raz na przykład zrobić ten dynamic content.

Na przykład error tool call, że tool call był wywołany i zwrócił błąd. Albo użytkownik musiał cztery razy doprecyzowywać, co chce zrobić, bo agent nie skumał tego. I on na zasadzie takiej inżynierii odwrotnej patrzy, dlaczego tak się stało, co w tym kontekście było źle. No i na przykład to poprawia. I teraz zobacz, masz? Mamy teraz 200 takich evalsów zebranych z różnych tam źródeł, co ludzie robią z Open Mercato. Jasne, że to nie pokrywa wszystkiego i musimy to jeszcze dużo, dużo bardziej rozbudować, ale już jest baza. I my to puszczamy na każdym modelu, na który chcemy zoptymalizować kontekst i muszą przejść. To jest dwieście takich case'ów do zakodowania. Zadań. To są zadania programistyczne. Dodaj pole w CRM.

Mam tą specyfikację, masa automatów naparza. Co to jest największym problemem do rozwiązania z waszej perspektywy? Nie tylko pytam o Open Mercato, tylko tak ogólnie o organizację, która z tego sposobu wytwarzania programowania korzysta. Myślę, że najpierw warto by było się zastanowić, ile faktycznie korzysta na tym etapie. Załóżmy, że jest adopcja i korzystają. Kilka pól ja bym wymienił. Na pewno rozumienie i kontrola nad tym systemem. To jest jedna rzecz. Druga rzecz jest taka, żeby trzymać ten proces w rydzach. To znaczy, my zauważyliśmy taką tendencję, że ludzie jak pracują z AI, to trochę schodzi im ownership tego, co tworzą i oddają dużo agentowi. Więc ten proces wytwarzania, można powiedzieć, że przeniesiony musimy ciężar decyzyjny i tego faktycznie, jaki będzie efekt na agenta i przestajemy się tym aż tak zajmować i tak przejmować, jaki ten finalny efekt jest.