Case Study: Agentic SDLC w Open Mercato
Czy da się zbudować produkcyjny system o skali prawie dwóch milionów linijek kodu, korzystając wyłącznie z agentów AI i nie pisząc kodu ręcznie? Przykład Open Mercato pokazuje, że taki kierunek jest jak najbardziej możliwy i działa w praktyce, ale wymaga fundamentalnej zmiany w podejściu do procesów SDLC.W tym odcinku zapraszam na case study projektu Open Mercato, open-source'owego narzędzia do tworzenia rozwiązań klasy CRM/ERP, rozwijanego w duchu AI-First. Piotr Karwatka, founder i CTO Open Mercato, oraz Patryk Lewczuk, Core Developer / Forward Deployed Engineer, opowiedzą jak wygląda proces SLDC w tym projekcie oraz jakie techniki i narzędzia są do tego wykorzystywane.
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?
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.
To jest mega ważne, jak odpalasz bardzo dużo zadań, a jak masz duży projekt, to odpalasz dużo zadań, więc jakby musisz to mieć. Jest tam kilka takich ciekawych rzeczy, wspieramy multiprojektować, więc możesz mieć wiele różnych projektów, pracować jakby równolegle, więc zlecać pod każdy projekt. Masz taką tablicę, gdzie widzisz wszystkie projekty, możesz sobie filtrować, co tam chcesz zobaczyć. Jakoś tam graficznie przedstawiamy, w jakim statusie jest dany pull request, czy on jest skonfliktowany, czy nie, czy właśnie wymaga przejrzenia, więc kolorkami tam sobie to widzisz. Masz podgląd pod całego Bithuba. Jeśli masz na przykład te pull requesty już w Cesarza, możesz sobie wybrać, co chcesz z nimi zrobić. Tam jest jeszcze ważne to, że to domyślnie pracuje na WorkTrees, czyli te taski są od siebie totalnie niezależne, więc możesz ich naprawdę dużo odpalić na raz. I jeszcze taka fajna rzecz właśnie z tymi naszymi skillami jest taka, że one domyślnie jakby działają w takim trybie, że nawet jak tego nie masz w swojej aplikacji, to tam jest taki skill OM Integration Test, który ci to doda.
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,
Pokazano wszystkie 5 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Podcast zaczyna się, autor przedstawia gościa i ich role w projektowaniu Open Mercato.
Goście opisują Open Mercato jako framework do budowania aplikacji biznesowych i opisują sposób jego implementacji.
Goście rozwijają temat technologii i architektury Open Mercato, w tym opisania funkcji i modeli AI.
Goście opisują rozwój Open Mercato i rolę AI w jego implementacji, w tym opisywane są konsekwencje zmian w modelach AI.
Goście opisują proces tworzenia funkcjonalności w Open Mercato, w tym opisywane są specyfikacje, kodowanie i testowanie.
Goście dyskutują o roli deweloperów i inżynierów AI w projektowaniu Open Mercato, w tym opisywane są nowe wyzwania i perspektywy.
Rozmowa koncentruje się na procesie tworzenia specyfikacji wymagań i używaniu skille do zarządzania procesem SDLC. Podkreśla się potrzebę systematyzacji pracy i używania agencji do automatyzacji zadań.
Podróżnicy opowiadają o trzech kluczowych problemach, które próbują rozwiązać: CRM, Open Mercato i inne moduły. Rozmowa skupia się na optymalizacji kontekstu i generacji dynamicznego kontekstu, aby automatycznie wybierać odpowiednie skille. Podkreślone są wyzwania związane z adopcją i ownershipem, a także potrzebą testowania i zabezpieczenia kodu.
Wskazano na problem z poczuciem osamotnienia deweloperów w firmach, którzy korzystają z AI w procesie SDLC.
Porównano programy 10xDevs i AI Tech Leaders, podkreślając konieczność edukacji całego zespołu.
Podsumowano rozmowę, podziękowano za udział i zaproszono do podcastra.
Rozdziały i streszczenia generowane automatycznie. Pełna transkrypcja nie jest publikowana — wyszukaj frazę, aby zobaczyć dopasowane fragmenty.
Kliknij, aby znaleźć fragmenty, w których pada.
Czy da się zbudować produkcyjny system o skali prawie dwóch milionów linijek kodu, korzystając wyłącznie z agentów AI i nie pisząc kodu ręcznie? Przykład Open Mercato pokazuje, że taki kierunek jest jak najbardziej możliwy i działa w praktyce, ale wymaga fundamentalnej zmiany w podejściu do procesów SDLC.
W tym odcinku zapraszam na case study projektu Open Mercato, open-source'owego narzędzia do tworzenia rozwiązań klasy CRM/ERP, rozwijanego w duchu AI-First. Piotr Karwatka, founder i CTO Open Mercato, oraz Patryk Lewczuk, Core Developer / Forward Deployed Engineer, opowiedzą jak wygląda proces SLDC w tym projekcie oraz jakie techniki i narzędzia są do tego wykorzystywane.