Case Study: Agentic SDLC w Open Mercato

Tworzy się taka fajna struktura w JSON-ie tych komentarzy, które opisują, do którego komponentu on jest. I to później można przekazać jako kontekst do agenta. Czyli siadamy sobie z klientem, patrzcie, tak by to wyglądało mniej więcej, a oni, kurczę, to by było może inaczej, to byśmy potrzebowali to. Oni jeszcze nie wiedzą jakby, co tam będzie pod spodem, ale mogą dać nam taki feedback już na bazie jakiegoś ekranu, który widzą. I to właśnie przez to, że to jest tak ustrukturyzowane w formie JSON-a i oznaczone są te elementy, to to bardzo fajnie później działa, żeby Agent się tego trzymał podczas kodowania. Ale z tego co mówicie, tak naprawdę rola dewelopera to jakby zupełnie się zmieniła. To już powiedziałbym, że to nie jest Software Developer, tylko Product Developer. Wiesz co, myślę, że tu dotknąłeś wielu aspektów. Ja na początku tej ewolucji z AI właśnie miałem takie myślenie, że teraz to deweloperzy muszą naprawdę zmienić swoją rolę w tym sensie,

i dopasowują się do Twojego SDLC. I to brzmi tak trochę jak science fiction, ale tak naprawdę w skillach to jest bardzo prosto zrobione, bo one tworzą pliki JSON z konfiguracją jakie ty masz, code review, standards, jakieś inne rzeczy. I wszystkie skille, które są w tym repo są zgodne z tą metodyką pracy, więc jak używasz na przykład skilla, który się nazywa OM Auto Create PR Loop, jest taki skill, Który tworzy pool requesta, tak jak nazwa wskazuje, w pętli, czyli może Ci zaimplementować autonomicznie całą specyfikację, to on będzie po drodze na przykład robił code review skillem OMAutoReviewPR na bazie tych zasad, które ten pierwszy skill jakby wy-setupował, a które możesz też sobie zmienić, nie?

Okej, w twojej architekturze będą dokonane, po zmerge'owaniu tego, będą dokonane takie zmiany. Tu masz widok przed, tu masz widok po i to są faktycznie budowane diagramy architektury. Takie komponenty zostaną dołożone. To się zmieni, Po tym, jak to zmergeujemy, takie się dobre rzeczy pojawią, takie będziesz miał minusy. Ja sugeruję to, ale podejmij sobie decyzję. To taki panel, będziemy też pewnie wypuszczać niedługo taki skill na testy do community, żeby sobie zobaczyć, jak to działa. Wyzwaniem tutaj było to, że dużo kosztuje zbudowanie czegoś takiego w tokenach. Więc my poszliśmy w taką drogę, że agent tworzy podsumowanie, generuje JSONa i później są skrypty Pythonowe, które ci ten cały widok graficznie budują, czyli jakby UI już jest zbudowany i Python tylko wykorzystuje tego JSONa, te informacje, żeby to wszystko zbudować, już ten na budowanie, za każdym razem tej grafiki nie wydajesz pieniędzy.

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?

Żeby to działało z kolei, musieliśmy wejść jeszcze głębiej w aplikację i zrobić taki generator faktów o modułach. Nazywa się module facts. I on na etapie kompilacji aplikacji, to jest po prostu taki skrypt, który przez AST przechodzi przez kod i wynajduje wszystkie interfejsy np. API, jakie są eventy emitowane przez te moduły, jakie są tam strony w React, jakie są komponenty. Takie fakty generuję do JSON-a, czyli format ustrukturyzowany, zawsze taki sam, bardzo optymalny jak chodzi o ilość tokenów, bo JSON dosyć mało tokenów w AI-u używa, bo te wszystkie nawiasiki są tam w ogóle usuwane, więc to działa bardzo dobrze. Dzięki temu

Masz mega konkretną wiedzę o konkretnym module bez żadnego fabularyzowania, bo to jest po prostu z JSON-a wyciągnięte, a wcześniej z kodu z AST. Potem masz instrukcję, jak tą konkretną rzecz zrobić i robisz. I zrobiliśmy to. Okazało się, że to już samo w sobie dało mega optymalizację na słabych modelach. Właśnie Luna zaczęła bardzo dobrze działać. Unikamy tego skanowania codebase'u, wszystko jest przygotowane. Takiego bloata w ogóle unikasz. I później jeszcze następny krok był na polu kontekst zenderingu, czyli zrobienie takiego mega wielkiego evala, który na bazie tego, co ludzie faktycznie robią, optymalizuje ten kontekst. Niektórzy nasi partnerzy albo jak W zasadzie każdy, kto chce, może z nami się podzielić swoją sesją.