Case Study: Agentic SDLC w Open Mercato

Dzień dobry. Better Software Design to podcast o projektowaniu oprogramowania. Wraz z moimi gośćmi rozmawiamy o architekturze, szczegółach implementacyjnych i wyzwaniach z tym związanych. Jeśli interesujesz się tworzeniem oprogramowania, to ten podcast jest właśnie dla Ciebie. Zapraszam na odcinek. Nie ma w IT chyba obecnie gorączszego tematu niż AI SDLC, AI Assisted SDLC, czy jak to tam różne osoby nazywają.

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.

Dużo się bardzo ciekawych tam problemów po drodze pojawiło, bo jeżeli mamy czata, załóżmy AI-owego, no to ten czat jest wywoływany, ale natomiast poprzez człowieka, poprzez interakcję. Jeżeli agent coś robi w systemie z poziomu czata, to zawsze możesz zadanie jego przypisać do człowieka. Jeżeli mamy cały proces zautomatyzowany i on jest np. uruchamiany poprzez jakąś akcję w systemie, jakiś trigger, no to ten agent sobie już pracuje niezależnie od człowieka. W organizacji regulowanej na pewno się spodziewacie tego, że musimy mieć cały trace log tego, co się dzieje. Więc agent musiał dostać swojej identity, czyli musiał być na poziomie użytkownika w systemie. Musieliśmy wiedzieć dokładnie, który to jest agent, w jakiej wersji, jakie ma uprawnienia, każdy agent ma swoje role.

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,

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.

Ja jestem taką osobą też, nie? Kurczę, zawsze lubiłem tę technologię i teraz masz taki renesans, że mówisz, hakuję, nie? No dobra, nie piszę sam kodu, ale hakuję, bo agent ten. Ale z drugiej strony osoby, które właśnie są bardzo deep into tech, Też mają mega, mega ważną rolę i ważną funkcję, bo oni dzięki temu, że są te agenty, mogą... Skupić się na tej architekturze zarobiście, tak? Mogą iść w bardzo niskopoziomowe rzeczy związane z AI-em. My na przykład mamy w teamie takie osoby, na przykład takiego Macieka mamy, który zaczął dotrenowywać QnA. Jako side project. Też coś tam pracujemy z tym, to nie chcę spoilować, ale działamy dosyć dużo na tym polu. Więc tam tych takich hardych rzeczy w technologii, gdzie mówisz, ja się zamykam i teraz będę nad tym pracował, jest bardzo dużo.

I dochodzisz do podstawowych jakichś takich zasad project managementu nawet, Tylko osobami w teamie są agenty na przykład. I project managerem jest skill AI, który project manager żywy stworzy, rozumiesz? Czyli dla każdego, kto pracuje przy software'ze, tu jest bardzo duże pole, żeby on przeniósł swoją wiedzę i doświadczenie na nurt tej inżynierii AI. I ludzie, którzy się boją tego AI engineering, bo ja też widzę, że jest taka grupa osób, która tak sceptycznie podchodzi. To wynika pewnie też z tego, że na przykład pracujesz w jakiejś firmie, gdzie ta adopcja AI jest taka trochę przyblokowana albo No bzdura, nie macie w ogóle za sobą, bo wy musicie cały zespół przenieść w ten nowy tryb pracy, nie?

Idzie taka analiza, gdzie my byśmy się chcieli wpiąć, z jakich ...primityw, jakich takich komponentów skorzystamy. To jest zapisywane właśnie w tym elemencie architektury. Tam są opisane, jakie powstaną nowe obiekty, jak będzie wyglądała struktura bazy danych tak naprawdę po tym. Więc możemy sobie to później zweryfikować. Następnie, jak mamy już tą architekturę ułożoną, to Powstaje element tego właśnie, jak użytkownik będzie wchodził w interakcję z tym systemem. To jest mega ważne, bo nam wychodziło, że bez tego elementu użytkownika tak naprawdę dostajesz takiego cruda. Czyli masz jakby system, są jakieś obiekty i AI tworzy taką najszybszą ścieżkę do korzystania z tego. Więc krócik ładny powstaje i trzeba opisać faktycznie jak użytkownik będzie wchodził w tą interakcję z tym systemem.

Czyli masz usystematyzowane to na maksa. Odpalasz skilla auto review PR i on zawsze zrobi to samo. Znaczy, dobra, wiadomo, że nie zawsze dokładnie to samo, bo to jest jednak AI. Ale w jakichś granicach. Ale w granicach. Te same zasady uwzględni, nada te same labelki pull requestowi, więc my podchodzimy do skili inaczej, myślę, niż często się wydaje, czyli my z niej zrobiliśmy maszyny. To fajną rzecz powiedziałeś, bo to może nie wybrzmiało, ale te labelki to bym zahaczył, że Ta komunikacja właśnie też developer-developer czy developer-repo, agent-repo jest usystematyzowana, więc wszystkie requesty czy issue wyglądają tak samo. Jeżeli są w odpowiednim statusie, to są tak samo oznakowane, czyli taki święty graal tego, żeby wszystko faktycznie było otagowane i można było z tego korzystać, to te skiery w tym pomagają.

Jak na przykład jeden agent pracuje nad jakimś pull requestem, robi review, to on sobie oznacza, że jest in progress i już drugi agent tego nie weźmie, bo widzi, że jeden się tym zajmuje. Więc to dodaje taką warstwę też zarządzania. One też zapisują na przykład w tych pull requestach sobie taki handoff, że zrobiłem już to i to z tej specki, a to i to jeszcze nie. Bo wiesz, często są case'y, każdy ma takie coś, że skończy się limit tokenu, Zamknąłeś przez przypadek laptopa i coś tam się przerwało. I dzięki temu, że masz to usystematyzowane, to możesz to wznowić, możesz kontynuować pracę. Po prostu nam brakowało systemu, bo na dużym projekcie to się na jolo nie da robić. Potem dalszy etap tego to jest ten program AI Tech Leaders, który teraz nagrywamy z 25 godzin takiego kursu, jak tą fabrykę zbudować u Ciebie w firmie na różnych polach, nie tylko dla deweloperów, ale QA-ów i tak dalej.

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

Pięć na raz. Każdy z nich stawia instancję twojej apki. Testuję czy to co zrobił działa, może używać Playwrighta, Agent Browsera albo innego frameworka do testów. I na końcu to po prostu wyłączę, kończę pracę, kasuję Workstream i masz zadanie zrobione. I wiecie, to na przykład było dla nas też strasznie uciążliwe, że myśmy już robili ten kodowanie z tym AI, te specki, to wszystko, ale na końcu wisiał pull request. Co trzeba było zrobić? Trzeba było tam wejść, zrobić No nie wiem, jak ktoś używał Github CLI to musiał zrobić GH, PR, check-out, check-outować sobie na komputer, yarn, 20 minut to wstaję, tam klikasz, baza stara, no to nie, to jeszcze bazę muszę wczytać, no bez sensu, nie?

Natomiast takie zorganizowanie bardzo ułatwia, bo ty patrzysz na tą infrastrukturę do AI engineeringu, tak jak w naszym przypadku, jako produkt. On ma być dobry, on ma działać, że jak przyjdzie nowa osoba do zespołu, to na dotyk mu to zadziała, więc w sumie to zadziała każdemu, nawet nie z naszego zespołu. I polecam takie rozwiązanie. I tak szczerze, to ja myślę, że jakby zebrać te wszystkie rzeczy, co my robimy w inżynierii oprogramowania, To tak pewnie ze dwie osoby na pełen etat miałyby co robić w naszym zespole, tylko to jest rozłożone. Osób jest łącznie trzynaście, więc no to dwie z trzynastu to jest ile procent? No parę procent, tak? To nie jest dużo, 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

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.

Jest bardzo duży problem z takim poczuciem osamotnienia deweloperów. Firma. Na pewno też to widzisz, jak zgadzasz z dużo większą jeszcze pewnie liczbą inżynierów, bo jesteś, kurczę, mega takim autorytetem, jak chodzi o inżynierię softu, ale my to też widzimy, że przychodzą ludzie i mówią tak, fajnie, nie? Tak mówicie o tym AI, inżynieringu, fajnie, a u mnie w firmie to dostałem kodeksa, kloda, kursora, kopailota, no you name it, jakiś tam agent dostałem, dostałem te tokeny I szef mówi, że ten, co zużywa najwięcej tokenów, to najlepiej się zadaptował, to w ogóle jest liderem i tam mój kolega to szuka przepisów na Bigos, nie? I jest liderem na tym AI-u, a nikt inny tego AI-a nie używa.

I teraz, wiesz, checked, tak? Mamy już AI development, a ten AI development to po prostu jest mega wielkie oczekiwanie, że ten developer, co jest w tym zespole i ma tego kodeksa, to on już wszystkie problemy rozwiąże, A to jest bzdura, bo nic się takiego nie wydarzy i wiesz, możesz się starać jakbyś tylko mógł i chciał i z 10 agentów korzystać na raz, ale ty tego nie przeskoczysz sam jako deweloper, że na przykład dostajesz za wolno taski, za wolno specki, albo one są źle opisane, albo na przykład To pewnie w mniejszych firmach, ale ja widziałem to wiele razy, że przychodzi do ciebie biznes, tak zwany biznes, nie? I mówi, że zrób to i to.

Całe SDLC zrobimy, żeby One nie musi być przecież całkowicie automatyczne przez tego AI, ale żeby wspierało tego AI, czyli będziemy teraz robić specki i tak, tutaj testerzy będą korzystać z testów i tak dalej, to to wtedy wyjdzie. A zostawienie tego tylko deweloperowi? Według mnie nie. O tym jest AI Tech Leaders, bo też dużo ludzi nas pyta, jaka jest różnica między 10xDevs a AI Tech Leaders. Oba programy ze Stainy Brave Education, więc Staramy się utrzymać ten mega wysoki poziom, co jest też mega inspirujące dla nas, bo my jesteśmy mega fanami kursu, który chłopaki w Tanex Devs nagrali. Myśmy się na nim uczyli tak naprawdę.

Ale w tym naszym to my trochę bardziej idziemy w team, automatyzację i pracę na dużej skali, bo w tamtym kursie te tematy po prostu nie były wiodące. Jest tam też o tym trochę, to trzeba jasno powiedzieć. Natomiast u nas to właściwie o tym jest bardzo dużo. Oczywiście takich hardcore'owych rzeczy DLDW też jest dużo, jakieś security rzeczy, jakieś tam open source'owe modele jak zaprząs na przykład, to też ciekawy temat. Więc jeżeli pytasz o jedną rzecz, w którą bym zainwestował, to zainwestowałbym w szkolenia, idąc dalej w AI Tech Leaders, bardzo polecam. No i myślę, że tak, że w taką edukację całego zespołu. Nie jednej osoby, nie programistów, nie jakiegoś, wiesz, zrobimy ewangelistę AI.

Jesteśmy na mega początku tej drogi i po prostu trzeba do tego podejść z pokorą i dużo w edukację teraz inwestować, ja bym tak powiedział, nie? No, historia lubi się powtarzać. Tym bardziej, że warto sobie też zwrócić na to uwagę, że ten AI, Tak myślę, że z tej dzisiejszej rozmowy mogłoby brzmieć, że jednak jest trochę roboty dookoła. Jak zwykle, nie? Że to puszczenie kodowania już na sam koniec to jest taka wisienka na torcie, ale jednak tej roboty takiej inżynierskiej dookoła jest bardzo dużo i też sobie dobrze z tego zdawać sprawę, że deweloperzy będą musieli przy tym posiedzieć, żeby to faktycznie fajnie działało, te godziny tam spędzić i się często bardzo dużo zmurzyć nad tym, jak to wypracować, żeby w mojej firmie to fajnie chodziło, nie? Być może po prostu wykonując inne zadania.