Case Study: Agentic SDLC w Open Mercato

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,

Robisz development za pomocą zdefiniowanych już maszyn, tak jak wcześniej, czyli faktycznie masz te kroki w procesie opisane i wybierasz sobie, OK, jestem w takim momencie, chciałbym na przykład z tego issue na GitHubie stworzyć pull request. Mamy do tego skill, mamy opisaną procedurę, jak to zrealizować, więc po prostu wybieram to, uruchamiam i ten task Wchodzi w kolejkę, jeżeli są zasoby na to, Cesar uruchamia jakiegoś runera, na przykład cloud code'a i to implementuje. Tytku mówiąc, zamiast odpalać to z konsoli, mam po prostu ładnego GUI'a. Masz ładnego GUI-a i ten GUI... To być może odroczy zrobienie pewnych rzeczy, bo nie mam zasobów. Tak, ten GUI właśnie daje kilka takich fajnych rzeczy, jak możliwość odroczenia, czyli ładujesz sobie na przykład 100 zadań w kolejkę. Jeżeli to masz na VPES-ie, tak jak my z tego korzystamy, no to ładujesz sobie 100, zamykasz laptopa i po prostu w momencie, kiedy w zależności od tego, jak to skonfigurujesz, ale załóżmy skonfigurujesz sobie na dostępność RAM-u, jak po prostu ten RAM się będzie pojawiał po implementacji tych czasów, to C0 będzie zlecał dalej.

Wszyscy tak robią przecież, bo ja na Twitterze to widziałem, że wszyscy tak robią. Tylko ja widziałem wpis, wiesz, jakiegoś słabnego gościa, youtubera, programisty i myślę, że wszyscy tak robią. No rzeczywistość jest inna. A nikt tak nie robi. I my robimy sobie jakieś skilla, ludzie mówią, wow, ale macie fajne te... Ja mówię, serio, nie? To jest takie, kurde, oczywiste, nie? Tylko wiesz, oczywiste jest, jak w tym siedzisz i spotkałeś te problemy, natomiast jak jeszcze ich nie spotkałeś, To jest to dla Ciebie ciekawe i jest tam po prostu dużo szans, że możesz zrobić naprawdę fajne rozwiązania, tylko no musisz to robić szybko i dlatego nam się ten projekt bardzo rozgałęzia, że cały czas robimy tego core'a. No 80% czasu nas wszystkich to jest core.

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.