#197 AI-assisted development w praktyce - na przykładzie Open Mercato z Piotrem Karwatką

Piotr Karwatka Spec-Driven Development okazało się, że to jest chyba obecnie najlepsza metoda. Założenie na samym początku projektu było takie, że nie piszemy ani jednej linii kodu, nie piszemy jako ludzie, że będziemy generować kod AI-em. Najgorsze co można zrobić, to zerknąć. Bo on, ten agent, w międzyczasie on zazwyczaj robi jakieś głupie rzeczy. I ja zawsze mam takie coś: ej, nie rób tego, tam nie ma tego błędu, nie, tam nie patrz. Czemu to robię ciągle? Dlatego, że ja chcę wiedzieć, co jest w moim systemie. Bo jak przyjdzie klient i mnie zapyta, czy my mamy tam szyfrowanie czy coś tam, to ja chcę wiedzieć, że faktycznie mamy, że to działa.

Szymon Warda: Cześć, słuchacie Patoarchitektów. Dzisiaj w trójkącie, prowadzą Szymon Warda…

Łukasz Kałużny: Łukasz Kałużny…

Piotr Karwatka I Piotr Karwatka. Cześć, dzięki za zaproszenie.

Łukasz Kałużny: Dzięki.

Szymon Warda: Cała przyjemność.

Łukasz Kałużny: To słuchajcie, dzisiaj nagrywamy, specjalna edycja infoShare’owa. Zostaliśmy zaproszeni do studia podcastowego i wzięliśmy Piotrka w tym miejscu z ciekawego tematu. Ja tak zacznę, Piotrek jednym zdaniem próbowałem Cię złapać, czyli założyciel i exit Divante, współtwórca Vue Storefront, partner w Catch The Tornado. I temat dzisiejszego odcinka Open Mercato, na którym będziemy bazować.

Piotr Karwatka Dzięki. Super! Myślę, że to fajne przedstawienie. W sercu przedsiębiorca i programista cały czas.

Szymon Warda: Potwierdzam, Claude wchodzi w tle teraz.

Piotr Karwatka Zaczynałem swoją karierę jako developer i gdzieś to jest cały czas bliskie mojemu sercu, a teraz z tym AI-em to kupę ekscytujących rzeczy nowych do poznania, więc super.

Szymon Warda: Dobrze, to teraz tak, jakbyś mógł powiedzieć czym właściwie jest Open Mercato? Czym się charakteryzuje? Jak powstało? Konkretnie.

Piotr Karwatka Open Mercato to jest framework do budowania aplikacji biznesowych. Mówimy, że zacznij z 80% gotowymi: start with 80% done. To znaczy, że to jest framework, który nie tylko ma takie jakby bazowe elementy do budowy aplikacji, jak nie wiem, moduły, routing, jakieś tam wzorce projektowe, migracje, bazy danych i tak dalej. To wszystko jest, ale over this mamy jeszcze po prostu funkcje biznesowe, czyli…

Łukasz Kałużny: To Piotrek, jakby, bo teraz narzuca mi się taka jedna myśl w tym miejscu, bo można byłoby to postawić, nie wiem, do Magento, Django, bo mamy też zupełnie inne takie elementy, które są na rynku gotowe. I czym to się różni tak naprawdę? Masz z tym, pewnie miałeś styczność biznesowo i technicznie.

Piotr Karwatka Wiesz co, Django to jest pewnie jakiś tam dobry też przykład. Mamy większość czy wszystkie takie elementy, które mają takie frameworki właśnie jak Django, czyli możesz sobie generować strony do zarządzania danymi, API. To wszystko jest w oparciu o takie solidne wzorce projektowe z Enterprise Architecture i tam jest szyfrowanie, wszystkie inne rzeczy. To jest jakby jeden taki bazowy element. Możesz Open Mercato postawić totalnie puste, bez żadnych dodatkowych modułów i zacząć sobie budować aplikacje tak jak właśnie na Django od zera. Ale większość osób wybiera Open Mercato właśnie przez ten promise, że tam jest 80% rzeczy, które potrzebujesz gotowe. Co to znaczy w praktyce? To znaczy w praktyce, że mamy tam CRM-a, mamy tam katalog produktów OMS-a, WMS jest teraz w trakcie budowy, jakieś zarządzanie zasobami, system workflow, dużo takich biznesowych modułów. I my jakby obstawiamy taki bet, że ludzie wcześniej korzystali z różnego rodzaju SaaS-ów, na przykład, nie wiem, CRM, to jakiś tam HubSpot albo coś innego. One często były niedopasowane do ich potrzeb, miały funkcje, których nie używałeś, musiałeś za to płacić i tak dalej. I że teraz w czasach AI lepiej się może sprawdzić takie podejście, że ok, dostajesz te wszystkie funkcje, takie jak mają SaaS-y, ale możesz dzięki AI-owi i przez to jak jest Open Mercato zbudowane dopasować to do swojego biznesu, czyli te brakujące 20% dostawić. I ostatnia rzecz, jest to zdeliverowane w taki sposób, że te bazowe moduły są dystrybuowane jako paczki npm. Jesteśmy w technicznym podcaście, to mogę mówić…

Szymon Warda: O tym jeszcze będziemy mówili.

Łukasz Kałużny: To mamy specjalny punkt na to, więc nie martw się, bo…

Piotr Karwatka Dobra, to tylko podsumuję, że po prostu jakby idea jest taka, że możesz to zmieniać, ale bez modyfikacji tego core’a, ciągle możesz to aktualizować, co nie?

Szymon Warda: Tak.

Łukasz Kałużny: Dobra. Następne pytanie, które leci, bo powiedzmy zrobiliśmy dosyć duży research, macie różne przekazy marketingowe w różnych miejscach. Też postawiłem Open Mercato i zrobiłem pewną zabawę, więc w tym. Słuchaj i podejdźmy, pierwsza taka rzecz, która nas interesuje w kontekście i to jest dobra rzecz dla słuchaczy, bo jesteście jednymi z pierwszych, którzy bardzo mocno publicznie mówią, że prawie wszystko jest robione promptami, prawie całe podejście generowania kodu. I słuchaj, jeżeli popatrzymy, określiliście to jako AI Engineering Foundation Framework i słuchaj, teraz tak, co to do diabła, tak z Twojej perspektywy znaczy, że to jest właśnie build with an AI and design for AI?

Piotr Karwatka Wiesz co, już tłumaczę. Założenie na samym początku projektu było takie, że nie piszemy ani jednej linii kodu, nie piszemy jako ludzie, że będziemy generować kod AI-em. Co nie znaczy, że architektura też jest generowana AI-em, bo akurat nie jest, bo architektura jest tam mocno przemyślana i mocno za każdym razem ją weryfikujemy w takim core teamie developerów, który pracuje nad projektem. I tak samo code review nadal jest w dużej mierze też robiony przez ludzi, bo zależy nam, żeby nie wstydzić się tego, co tam dowozimy, co nie. I żeby te nasze doświadczenia, ja w Enterprise Software jestem, nie wiem, od 20 lat i te doświadczenia chciałem po prostu na to przełożyć. Pojawił się AI, pojawiła się taka możliwość, że bez nie wiem, zatrudniania 40 osób do zespołu, co by było strasznie drogie i pewnie trudne do zrobienia, można było się z tym zmierzyć. Więc tu jakby ten AI. I teraz, żeby wykorzystać to na maksa, bardzo szybko się okazało, że tak naprawdę to my mamy do rozwoju dwa produkty, a jakby tak popatrzeć, to nawet trzy. Pierwszy produkt, to jest Open Mercato samo w sobie, czyli my zaczęliśmy np. od budowy CRM-a, tak, to te funkcje biznesowe, taka biznesowa aplikacja, tylko że bardzo rozszerzalna i tak dalej. Druga rzecz, framework. Też od dnia zero dosłownie zaczęliśmy budować Open Mercato jako framework, czyli nie, że tylko tam budujemy fajnego CRM-a, ale żeby ten CRM, nie wiem, wykorzystywał takie reużyteczne mechanizmy, jak tam jakiś system eventów, właśnie te migracje bazy danych, wzorce projektowe takie jak command i inne. Dużo takich elementów, żeby one były we frameworku. Więc to już jest drugi produkt. I trzeci produkt, najciekawszy, to znaczy tak z mojej perspektywy, bo to jest coś całkiem nowego, to jest właśnie ten AI, taki harness. Czyli tak, to jest zbiór skilli AI-owych, które bardzo są rozbudowane w Open Mercato i w ogóle zachęcam, żeby każdy sobie tam w wolnej chwili popatrzył, się tym pobawił. Agents.MD, to jest duży skrót, bo to nie jest jeden plik, tylko to jest tam cała struktura, taki graf tych wszystkich plików Agents.MD i zapewnienie, żeby agenty kodujące followowały ten graf tak jak my chcemy, żeby one te instrukcje wykonywały. Później jeszcze cała taka infrastruktura CLI-owa, tak, że tam można sobie projekt nowy wystartować i tak dalej. Więc jakby to są takie trzy elementy. Obecnie się bardzo mocno skupiam na tym elemencie właśnie harnessu AI, żeby go zoptymalizować, żeby developer experience był jak najwyższy. Jak zobaczycie w Open Mercato, my siłą rzeczy staramy się nie nadbudowywać jakichś sztucznych tworów nad to, co dają takie super toole jak Calude Codex albo GitHub CLI na przykład.

Łukasz Kałużny: Wiesz co, to rozwinąłby właśnie, bo zahaczyłeś dobrą rzecz w tym, o co chodzi z tymi harnessami u Was, czyli jak Wy podchodzicie do guardrailsów i inne rzeczy, ograniczenia i walidacji tego?

Piotr Karwatka Wiesz co, nam chodzi o to, żeby po pierwsze, to było powtarzalne. Czyli jak wydasz polecenie, czy tam dasz prompta, nie wiem: zbuduj mi moduł do zarządzania na przykład zgłoszeniami serwisowymi, nie. Nam chodzi o to, że jak wydasz takie polecenie, to jeszcze tam, jakby rozkładając ten proces na czynniki pierwsze, to najpierw trzeba zrobić speckę. Więc do robienia specki też mamy skilla. Potem mamy skilla do planowania, czyli podzielenia tej specki na taski i na jakieś tam atomowe commity, różne rzeczy, a potem do implementacji tego. Więc nam zależy, żeby ten każdy etap był bardzo powtarzalny w tym sensie, żeby po pierwsze, trzymał się naszej architektury, żeby na przykład planowanie specki obejmowało takie rzeczy jak analiza ryzyka, analiza kompatybilności wstecznej, a kodowanie na przykład zawsze odpalało unit testy i zawsze pisało też unit testy i odpalało jeszcze testy integracyjne, czyli takie, że tam klika się automatycznie. My to rozumiemy jako harness, czyli jakby zapewnienie, że ten cały proces dostarczania softu on jest za każdym razem taki sam, albo jak to tylko możliwe zbliżony do tego samego procesu, bo wiadomo, że są różne też feature’y deliverowane i one mają różne wymagania specjalne. Na przykład coś, co dotyka security, pewnie ma więcej takich testów bezpieczeństwa i tak dalej, ale nam chodzi o to, żeby to był taki spójny proces. A celem jest to, żeby z jednej strony była jakość softu, bo my ten soft już budujemy dosyć długo, tam jest ponad 750 tysięcy linii kodu, to to jest kawał softu.

Szymon Warda: To jest dużo softu.

Piotr Karwatka To jest dużo softu i on jakoś nieszczególnie deterioruje jakościowo, co jest zarąbiste myślę i to jest dzięki temu harnessowi w dużej mierze. Natomiast druga rzecz, żeby developer, który przychodzi do Open Mercato i właśnie mówi: zrób mi tam moduł do tego na przykład zarządzania zgłoszeniami serwisowymi, w każdej nowej wersji Open Mercato dostał ten sam rezultat, taki benchmarking. My to też normalnie ewaluujemy, mamy do tego tool, który to sprawdza.

Łukasz Kałużny: On jest tam w repo publicznych?

Piotr Karwatka Nie, akurat tego toola nie ma. Członek core teamu, Patryk Lewczuk, nad tym pracuje. I właśnie naszym celem jest to, żeby to było bardzo powtarzalne. Teraz zaczęliśmy, ale to dopiero pierwsze kroki stawiamy, też optymalizować ten harness pod open source’owe agenty kodujące, znaczy modele kodujące, czyli na przykład Qwen albo inne. Bo wiecie co, to jest w ogóle też fajne, że ludzie używają tych turbo skomplikowanych, najnowszych modeli: GPT 5.5 albo Claude 4.7 i tak dalej. Na tych modelach większość rzeczy kurcze działa. One są tak dobre, że tam naprawdę jak coś nie działa, to on sobie poprawia i tak dalej. Natomiast cała sztuka polega na tym, żeby zacząć to optymalizować na takie, w cudzysłowie, głupsze i tańsze modele, bo jak na nich to działa, to na tych droższych to działa na pewno, natomiast jest to bardziej efektywne, nie.

Łukasz Kałużny: Raczej wiesz, ja bym patrząc w tym roku specjalnie wymieniałem pod to, M5 Maxa specjalnie wziąłem pod ten cel. Ty wiesz co, ale jak popatrzę, to jest ciekawe, ja już nie powiedziałbym, że one są takie głupie w ogóle, to tak…

Piotr Karwatka Nie, nie, to było w cudzysłowie.

Łukasz Kałużny: Ja wiem, wiem.

Szymon Warda: Są głupsze, może tak.

Łukasz Kałużny: Głupsze, tak, ale mi się co, to…

Szymon Warda: Może lepiej prostsze.

Łukasz Kałużny: Prostsze. Polecam tego nowego Qwena najnowszego. On naprawdę…

Piotr Karwatka On jest niesamowity.

Łukasz Kałużny: Tak, w sensie jakość tego i ten Gemma od Google’a też robi w ogóle ten.

Piotr Karwatka Ja testowałem właśnie Open Mercato ostatnio w ogóle na takim bardzo, bardzo małym modelu, gdzie można by było powiedzieć, że jest trochę głupi, czyli GPT-20-OSS od OpenAI. On działa na takich słabych, znaczy słabych, no nie wiem, 32 GB RAM-u to w czasach AI jest słaby komp, ale działa to dobrze na moim laptopie. I powiem wam, że on nie umie tak szerzej patrzeć. On bardzo mocno na te harnessy na przykład patrzy tak literalnie, jak tam jest napisane. I to jest super do testowania, dlatego, że jeżeli, ja wykryłem kupę błędów, nie, że coś mieliśmy pominięte, albo na przykład zmieniła się składnia polecenia CLI do, nie wiem, generowania migracji bazy danych i Claude, czego nikt nie zauważył, on zawsze się poprawiał, że wiecie.

Łukasz Kałużny: Wyszukiwał sobie.

Piotr Karwatka Tak, odpalał złe polecenie: aha, dobra…

Szymon Warda: I korekta.

Piotr Karwatka I korekta, nie. I tego nie było widać, bo to tak szybko działa. A ten open source’owy po prostu się na tym wieszał, nie.

Szymon Warda: Zahaczyłeś o jeden temat, który jest dla nas bardzo interesujący, właśnie ten flow developerski. Jak to wygląda? Czyli przychodzi osoba i mówisz: ok jest skill do pisania specki? A jakbyś mógł to rozszerzyć, po prostu jak to wygląda całościowo, ten flow? Gdzie są narzędzia, które pomagają i co wam ten harness daje i jak w ogóle on ewoluował? Bo na pewno nie był taki, że one man shot i generalnie zadziałało super, no nie. Te skille nas bardzo interesują.

Piotr Karwatka Słuchaj, to wszystko ewoluowało razem z naszą wiedzą, doświadczeniem, ale przede wszystkim też z tym, jak się zmieniają te agenty kodujące, bo sama idea Open Mercato, we wrześniu zaczęliśmy projekt, wtedy wyszedł Codex 5.1, tak mi się wydaje i Claude był chyba 4.5. Nie…

Łukasz Kałużny: Za szybko to idzie, zostawmy konkretne wersje.

Piotr Karwatka Tak.

Szymon Warda: Wersje są już nieważne.

Piotr Karwatka Ale koło tych wersji, to pewnie też słuchacze i pewnie Wy też potwierdźcie, że tam był taki jakiś, kurcze, przełom jakościowy.

Łukasz Kałużny: Było, wiesz co, Opus 4.5 był takim skokiem, takim…

Piotr Karwatka Tak, tam był skok.

Łukasz Kałużny: Taki już drastyczny, o tak.

Piotr Karwatka To był drastyczny skok, że po prostu od tego momentu kod, który te agenty generują, przyjmijmy, że one są jakościowo bardzo podobne do siebie, tam, to są drobne różnice, ale to, co one generują, to zazwyczaj zawsze działa, a wcześniej tak nie było. Wcześniej to się potrafiło nieźle tam rozwalić. Więc to był skok. I od tego skoku się jakby nasza przygoda zaczęła. Ja na przykład przez długi czas nie wykorzystywałem w ogóle skilli, w ogóle tego nie używałem. Używałem tylko Agents.MD bardzo prostego, gdzie była opisana architektura, że tutaj są takie naming conventions, takie wzorce projektowe: jak API robisz, to zawsze pamiętaj o autoryzacji. Takie proste rzeczy, nie.

Szymon Warda: Prompty.

Piotr Karwatka Takie prompty. I bardzo robiłem to w interaktywny sposób. Czyli prompt, on tam robił, ale fajnie, nie, testuję, zwracam mu co jest źle, on to poprawia, a napisz unit testy, takie, ping pong taki, interaktywny ping pong. Jest to fajne, trochę jak granie w grę, no nie, ta dopamina tutaj się wytwarza, więc każdego to mega wciąga, ale to nie jest do końca efektywny sposób.

Szymon Warda: Mikrozarządzanie.

Piotr Karwatka To nawet jest gorzej niż mikrozarządzanie i dużo się marnuje czasu potem na te poprawki. Więcej się marnuje czasu niż na te poprawki, niż na ten development inicjalny. Więc Spec-Driven Development okazało się, że to jest chyba obecnie najlepsza metoda, no nie?

Łukasz Kałużny: Znaczy wiesz co, ja zawsze teraz powtarzam, w szczególności tam klientom na prezentacjach, że myślenia nadal się nie da zdelegować.

Piotr Karwatka To jest prawda, to myślenia się nie da zdelegować i Spec-Driven Development jakby to myślenie wyciąga na ten pierwszy czy zerowy etap, że trzeba tą speckę napisać. I wiecie co? Myślę, że też jest fajnym podejściem, to nam tak jakoś wyszło przy okazji, my mamy ogólnie monorepo, więc wszystkie rzeczy, wszystkie tam paczki npm i tak dalej są po prostu w tym jednym monorepo. Co jest fajne, bo agenty kodujące, jak czegoś w tym harnessie nie mogą znaleźć albo w dokumentacji, to szukają w tym kodzie, a że mają cały kod, to naprawdę mogą znaleźć tam wszystko. I teraz jak robisz speckę w ramach tego repo, bo też mamy wszystkie specki też oczywiście są w tym repo, więc robisz speckę w tym repo, to ten agent robi tą speckę mega dokładnie, co nie? On tam używa tam tych właśnie konwencji wszystkich, linki są do jakichś przykładów i tak dalej. To jest jedna rzecz. Druga rzecz, bardzo dobrze się sprawdza odpalanie takiego refinementu tej specki. Czyli zrobił speckę i zadajesz mu takie filozoficzne pytanie: a czego tam brakuje? Albo na przykład: a co może pójść źle?

Szymon Warda: Samokrytyka.

Piotr Karwatka Tak. I on zaczyna to refine’ować. A że te agenty się mocno starają trzymać instrukcji, więc jak mówisz mu, że tam prawdopodobnie jest coś źle, to on tam kurcze znajdzie coś, co jest źle i ta specka się ulepsza. Dwie, trzy fazy, jest super. I teraz następnym etapem i wydaje mi się, że w tym momencie, obecnie, jak tak patrzę jak ludzie używają kodowania z AI-em, to to jest akurat, teraz co powiem, często pomijane i bardzo niedobrze, bo to daje super efekty - planowanie. Mamy speckę, to ja jeszcze do niedawna sam robiłem tak, że miałem tą speckę, mówię: to koduj, nie, zaimplementuj tą speckę. Potem czasami robiłem coś takiego: zobacz czy już jest cała zaimplementowana, tak jakby w tym drugim runie nowy kontekst oczywiście, nie, żeby on nie trzymał tego kontekstu starego, bo wtedy on jest bardzo pobłażliwy sam do siebie, ten agent. Więc nowy kontekst albo nawet inny model, że Claude vs GPT, weryfikacja czego nie ma i to też super działa. Ale jak są długie specki, takie kurcze no nie wiem, 3000 linii tekstu na przykład, to taka długa specka, a jeszcze jak tam są ASCII, arty, czyli na przykład mockupy…

Łukasz Kałużny: Tak, to jest w ogóle.

Piotr Karwatka To już w ogóle jest długa specka. To powiem Wam, że to się trochę też już przestaje sprawdzać. I wtedy najlepiej mi działa coś takiego, że mówię: podziel mi tą speckę na fazy, w ogóle każda w osobnym pliku MD najlepiej, żeby ten kontekst wciągany nie obciążać całą tą specką i jeszcze podziel mi tą speckę na takie atomowe commity…

Łukasz Kałużny: Taski.

Piotr Karwatka Tak, taski, które w ogóle to można zweryfikować najlepiej, żeby za każdym był jakiś unit test, albo jak one dotykają UI-a, to testuj Playwrightem czy tam Agent Browserem. W ogóle chcemy przejść na Agent Browser, bo dużo jest wydajniejszy, nie, bo nie robi screenów tylko zrzut tego accessibility, więc to jest fajna sprawa. Ale jakaś weryfikacja każdego taska. I jak poświęcisz ten czas, żeby zrobić to planowanie, takie bardzo już granularne, to później naprawdę można odpalić to w pętli.

Szymon Warda: I go zostawić.

Piotr Karwatka Pętle można robić, tak, w różny sposób. Ja ogólnie robię pętle w ramach samego agenta. Czyli na przykład w Claude możesz powiedzieć coś takiego, że: jesteś koordynatorem zadań, odpalaj sobie sub agenty na taski, które ze sobą nie kolidują, albo po prostu po kolei, aż skończysz. Najdłuższa pętla - 4 dni. To cały czas kodował.

Szymon Warda: Moje takie ośmiogodzinne widzę, że wymiękają.

Piotr Karwatka Nie, powiem Wam, że to naprawdę była długa wtedy tam pętla i to był cały jakiś tam framework taki duży do Open Mercato doimplementowaliśmy. I kurcze, powiem Wam, że eksperymentuję z tym, używam coraz częściej takiej metody, ale ona jest trudna z tego powodu, co powiedziałeś, że to myślenie musi być. I teraz wiesz, każdy ma inny sposób pracy. Ja zawsze miałem taki sposób pracy, że mi się dobrze pracowało iteracyjnie, czyli robię wersję MVP, poprawiam, robię kolejną wersję.

Łukasz Kałużny: Raczej wiesz co, wiesz dlaczego się śmieję? Bo wiem, do czego trochę chyba dążysz, bo ja mam taki problem, że lubię zerknąć w trakcie co się dzieje i…

Piotr Karwatka A w tej pętli nie można tego robić.

Szymon Warda: Właśnie totalnie nie robię tak.

Piotr Karwatka Ale wiecie co? Jak jest taka pętla kodująca, to najgorsze co można zrobić, to zerknąć. Bo on, ten agent, w międzyczasie on zazwyczaj robi jakieś głupie rzeczy. W sensie, że…

Łukasz Kałużny: Tak i trafisz na tą głupotę.

Piotr Karwatka Kurde, czemu ty to robisz, co nie? I ja zawsze mam takie coś: ej, nie rób tego, tam nie ma tego błędu, nie, tam nie patrz, nie. Ale wtedy jemu się ten cały jego tryb myślenia przerywa i on się gubi.

Łukasz Kałużny: Wiecie co…

Szymon Warda: On czasami robi rzeczy głupio, ale wynik ma dobry.

Piotr Karwatka Ale wyniki ma dobry, tak.

Łukasz Kałużny: Słuchajcie, to jedna dla wszystkich podpowiedź, to dla Ciebie nie, ale wiesz co ja zacząłem robić? Mam specjalnie serwerek do kodowania zdalny. Odpalam Tmaxa, a potem się rozłączam.

Piotr Karwatka No tak.

Łukasz Kałużny: I mam pinga, żeby mnie na Telegramie pingnął jak mam ostatni, żeby pingnął mnie na Telegramie jak skończy.

Piotr Karwatka To słuchaj, to jest w ogóle inny temat, bo ja sobie dorobiłem taki mały softwarek i…

Łukasz Kałużny: A kto nie?

Piotr Karwatka Tak, który ma webowy interface i tam odpalone te Claude’y i mi pokazuje z jakim promptem był odpalony i który to jest pull request, bo ja się w tym po prostu gubię, nie, że odpalam sobie 10 tych CLI i ja nie wiem, który robi co. Głupia rzecz, ale nie macie tak? Bo to nie jest do końca.

Łukasz Kałużny: Mamy, oczywiście.

Szymon Warda: Ja mam wirtualne desktopy. Każdy desktop to inne zadanie.

Piotr Karwatka Właśnie.

Szymon Warda: Tak lecę.

Łukasz Kałużny: Każdy ma inny ten. Ale słuchaj, pociągnijmy sobie teraz jeden wątek projektowania pod agenta, bo bardzo dużo już powiedziałeś, trochę wyczerpałeś te pytanie wcześniej. Ale zostaje coś, o czym nie złapaliśmy, czyli stos technologiczny. Bo u Was parę rzeczy się przewija, że stos technologiczny jest wybrany pod to, co LLM-y umieją.

Piotr Karwatka Tak.

Łukasz Kałużny: Przy czym są tam też wyjątki, jak widziałem, mniej popularne.

Piotr Karwatka Tak, na przykład?

Łukasz Kałużny: Wiesz co, Wasz kontener DI czy Micro ERM zamiast Prismy, to rzucając. To może jakbyś powiedział o stosie, bo ja tutaj już w detale, to może opowiedz o stosie właśnie, czego macie, czego używacie?

Piotr Karwatka Wiesz co, totalnie tak, czyli wybraliśmy stos technologiczny pod to, żeby agenty umiały z niego korzystać. Czyli jakby kluczem była popularność technologii, co nie? Czyli totalnie najbardziej popularne technologie. Czyli co to jest? React, nie, na frontendzie. NextJS jako framework. Wiem, że są lepsze frameworki, pewnie takie enterprise’owe, jakieś tam NestJS-y i inne, ale ten kurde Next to jest totalny standard, więc Next. Postgres, kurcze, wiadomo, baza danych. Redis, Meilisearch jako wyszukiwarka i Docker jako wiadomo, kontenery, MikroORM i Awilix DI. Może nie są jakieś jakby turbo defaultowe obecnie, ale są dosyć rozpowszechnione. Na przykład MedusaJS jest z tego korzysta, gdzie też jakieś tam inspiracje z tej Medusy, jesteśmy też inwestorami z Tomkiem w MedusaJS, więc jakby siłą rzeczy jestem blisko tego softu i bardzo mi się podoba jak jest zrobiony. Więc jakby inspiracje stamtąd też były. Stąd te elementy. I tak wygląda nasz stack, czyli jest taki turbo, turbo standardowy. I też nam zależało, żeby on był jak najbardziej taki koherentny, nie? Nie chcieliśmy robić czegoś takiego, że na przykład, nie wiem, backend jest w Pythonie albo w Golangu, albo w czymś tam, a frontend to jest osobny serwer w Next’cie i tak dalej, bo postawienie tego projektu od razu jest trudniejsze, bo od razu jest wielkie pytanie o skille, tak, że ja umiem w Reakcie, a ja w Pythonie nigdy nic nie robiłem, co by the way jest teraz, nie jest żadnym problemem.

Szymon Warda: Żadnym.

Piotr Karwatka Nie trzeba tego umieć. Ale wiecie, chodzi o tą prostotę. Mi bardzo zawsze zależy, żeby jedno polecenie: masz projekt, a (…), nie.

Łukasz Kałużny: Tak, jest w tym. Wiesz co, to jedna taka rzecz jeszcze a propos Nexta. Zastanawialiście się w przyszłości jak to się będzie skalowało jak ktoś będzie chciał zrobić coś większego? Bo pewnie mieliście już taką rozkminkę.

Piotr Karwatka Wiesz co, mamy dużo takich rozkminek i ci więksi klienci to zawsze o to pytają. Tutaj tak naprawdę jest parę opcji. Jedna opcja jest taka, że można Open Mercato podzielić jakby na osobne apki. Bo te moduły, one mają bardzo taki zunifikowany jakby standard i one w założeniach też i to jest też w harnessie naszym, nie mogą od siebie zależeć wprost. Czyli jeden moduł nie może z drugiego tam zaciągać.

Łukasz Kałużny: Wiesz co, to do tego jeszcze może dojdziemy, bo to będzie w tym.

Piotr Karwatka Ale to tylko mówię dlatego, że jakby jedną opcją jest takie wyskalowanie wertykalne tej apki. Czyli można, nie wiem, moduł produktów odpalić na jednym serwerze, tamten moduł na innym serwerze. Baza danych Postgres, to też łatwa jest dosyć do skalowania takiego przez jakiś sharding master slave albo w ogóle sharding. Plus jest ten Redis, mamy kolejki, system kolejek, więc jakby tam nie ma raczej takich problemów, że to nie da się skalować, bo to jest mega standardowe. Plus jakby to co jest w repo, to co sobie ludzie odpalają i widzą, to jest jakby panel admina. Jeżeli ktoś chce zrobić aplikację frontendową z Open Mercato jako panelu admina, to w ogóle zajebiście i to super działa. I też jest taka opcja, że tamte rootsy takie frontendowe mogą być. By the way na Youtubie naszym jest tutorial właśnie z zeszłego tygodnia jak coś takiego zrobić, że landing page, gdzie leady wpadają do CRM-a w Open Mercato. Ale można też użyć Open Mercato w wersji takiej właśnie headless, czyli jakby ten frontend, to może być zupełnie inna apka, która się skaluje zupełnie jakoś inaczej i korzysta tylko z naszego backendu przez API. Bo wszystko, każda jedna metoda obsługi danych jest po prostu (…).

Szymon Warda: Jasne. Ja mam taką jedną rzecz, bo temat, który rzuciłeś na starcie i ja do niego chętnie wrócę, pytanie, czy miałeś takie obliczenia, takie powiedziałbym mentalne? Bo czuję taką opcję, że potrzebowalibyście czterdziestu developerów. Obecnie developerów nie macie wielu. Czy robiłeś takie proste obliczenia ile byście potrzebowali developerów, żeby dojść do tego miejsca, gdzie jesteście, gdybyście nie mieli AI-a?

Piotr Karwatka Wiesz co, robiłem takie ćwiczenie, z ciekawostek.

Szymon Warda: To jestem ciekaw. Dajesz.

Piotr Karwatka Bo, znaczy dobra, jeszcze tylko tak podsumowując, my mamy ogólnie w zespole 4 osoby full time - to jestem ja, Tomek, Patryk Lewczuk, Maciek Greń. Potem mamy zespół core kontrybutorów, czyli najbardziej zaangażowanych open source’owych kontrybutorów. To jest dodatkowo jeszcze z 5 osób 5-6 osób. Później jest szersze grono kontrybutorów, mamy partnerów, więc to są zazwyczaj pracownicy tych partnerów, którzy też kontrybuują do projektu. Partnerów jest obecnie 25, ale łącznie kontrybutorów wszystkich na GitHubie ja już naliczyłem ponad 100 takich, że minimum jedna kontrybucja. Zazwyczaj na release jest około 17 kontrybutorów. To też w sumie nie tak mało, co nie? Jest to wyzwanie pewne, żeby to pozgrywać jakby razem, nie, wszystko, ale mamy to dosyć fajnie ogarnięte. Natomiast koszt odtworzeniowy próbowałem oszacować i to za pomocą Chata GPT. Przecież wiadomo, że on mi prawdę powie.

Szymon Warda: I pochwali.

Piotr Karwatka I pochwali na koniec. I tam wyszły mi jakieś kurcze już na tym poziomie co jesteśmy jakieś miliony złotych tam w przeliczeniu na stawkę jakąś godzinową. Ja nie wiem, czy to są dobre rezultaty, czy nie. Liczby osób akurat nie estymował, ale tak jakbym sobie to przełożył to myślę, że pewnie to by było wiesz, z 20 osób pracujące przez, nie wiem, rok czasu, nie, coś takiego.

Szymon Warda: Ja też bym tak strzelał.

Łukasz Kałużny: Chciałem powiedzie właśnie, że tak, w zależności od skilli do dwóch, do czterech zespołów na rok trzeba, mieć właśnie taki rok czasu.

Piotr Karwatka Tak, tak mi się wydaje. Przy czym słuchajcie, tu by było też dużo jeszcze takiego narzutu na komunikację.

Szymon Warda: Organizację i tak dalej.

Piotr Karwatka Organizację i komunikację, bo przy takiej dużej ilości osób to się zaczyna robić problem.

Łukasz Kałużny: Tak, feature’ów, w sensie tak i też zbootstrapowanie tego. Gdybyś miał pewnie bootstrapować to samo, to i tak musiałbyś mieć team core’owy od modułów i inne rzeczy.

Piotr Karwatka Tak.

Łukasz Kałużny: A słuchaj, jak jesteśmy przy rozwoju takim. Bo to co macie w ciekawy sposób też rozwiązane to jest te podejście fork free, które jest takim dość, raczej jest bardziej właśnie pokazuje, że to nie jest framework, a nie to co, że… Inaczej, znam takie rzeczy, że niektórzy sforkowali sobie Jango, Magento i inne rzeczy i na tym robili swoje zmiany, bo nie chcieli, w żaden sposób nie pasowało to, żeby zrobić z tego pull request do właściwego. Jak Wy do tego podchodzicie, fork free, tego wzorca właśnie?

Piotr Karwatka W sensie, żeby nie modyfikować core’a, tak?

Łukasz Kałużny: Tak.

Piotr Karwatka Tak, przez to to rozumiemy, bo ogólnie forki to tam ludzie robią sobie…

Łukasz Kałużny: Tak, ale nie, bardziej forki przez zrozumienie, że właśnie rozwoju, jak ktoś chce customizować core potem.

Piotr Karwatka No ja dużą część swojego zawodowego życia pracowałem z technologią Magento, gdzieś tam oglądałem jakieś inne Sylius i tak dalej. Tam zawsze jest ten temat, żeby nie modyfikować tego core’a, nie, bo się traci tą upgrade’owalność i to jest duży problem. Znaczy w każdym open source to jest problem. Więc myśmy do tego podeszli tak, że jest duży nacisk położony jednak na takie extensibility, nie. I tam jest do tego bardzo dużo mechanizmów. Można nadpisywać ze swoich modułów rooty, czyli całe URL-e. To jest taki już ostateczny element, bo to się traci w sumie tą updateowalność. Ale można jeszcze wcześniej, mamy taki system, injections się nazywa, że można wstrzykiwać swoje komponenty React w miejsce innych komponentów. Czyli nie wiem, mam CRM-a i tam są jakieś kurcze, nie do końca taki wygląd karty klienta jak ja bym chciał, to mogę tam sobie wszczelić swój jakiś komponent ze swojego modułu. Potem mogę robić na przykład w ogóle takie rozszerzenia w bazie danych Custom Fields, czyli to w ogóle nie jest żadna zmiana w kodzie, tylko po prostu takie bardziej słownikowe, ale różne typy danych są obsługiwane i tak dalej, eventy i tak dalej. Czyli inaczej, tych mechanizmów jest dużo i ten harness jest tak skonstruowany, że jak jesteś w trybie standalone app, czyli mamy takie CLI właśnie create Mercato app, nazwa apki i on wtedy stawia ci puste repo w sumie tam z jednym plikiem TSX i package JSON wciąga przez npm cały Open Mercato po prostu jako pakiety npm, nie. To w tym trybie jak jesteś to harness AI jest inny niż w trybie mono repo, czyli rozbudowy core’a. Bo ten w corze to jest taki pod core’a, że tam gdzie co jest. A w tym standalone to jest bardziej opisane, że tu jest mechanizm eventów, to jest mechanizm nadpisywania, tu jest ten. Czyli jak chcesz coś zrobić, to ten agent będzie starał się nie modyfikować core’a, tylko właśnie użyć tych mechanizmów, żeby osiągnąć efekt. I teraz jeszcze jest jedna ważna rzecz. Trzeba o tym pamiętać, że nasz framework jest pomyślany na zasadzie, że możesz użyć tych funkcji, ale nie musisz ich używać. Czyli na przykład jeżeli twój CRM totalnie nie pasuje do tego, co my mamy w CRM-ie, co by było akurat dziwne, bo mamy dosyć takiego ogólnego CRM-a. No ale powiedzmy, że…

Łukasz Kałużny: Raczej wiesz co, to powiem Ci tak, bo ja zrobiłem eksperyment, czy by nie użyć tego u nas w firmie, zupełnie pod tym. I faktycznie bardziej mi wyszło, że… Bo poszedłem tą drogą: stwórz aplikację. Stwórz aplikację i zacząłem kombinować z rozszerzaniem waszych formatek core’owych, bo potrzebowałem, dosłownie potrzebowałem parę rzeczy z naszej logiki biznesowej nie zmienić, tylko dorzucić po prostu, żeby…

Piotr Karwatka Jestem ciekaw jak poszło.

Łukasz Kałużny: Czy wiesz co, harnessy, jeszcze musicie popracować nad tymi harnessami od strony, właśnie od strony, jak nie masz dostępu. Bo jak miał dostęp do mono repo, jak wrzuciłem sobie z dostępem agenta, z dostępem do Waszego mono repo, poradził sobie od razu praktycznie. Tam parę razy trzeba było go kopnąć w tyłek, żeby się poprawił. Jak był puszczony bez dostępu do mono repo, to jeszcze było problematyczne, o tak, to taki od razu feedback.

Piotr Karwatka Super feedback, ale finalnie co, udało się?

Łukasz Kałużny: Tak, udało się.

Piotr Karwatka To super.

Łukasz Kałużny: Udało się.

Piotr Karwatka To mnie cieszy. No te harnessy właśnie one cały czas ewoluują i powiem Wam, że tam jest taki właśnie, takie wyzwanie jest, że chciałoby się jak najwięcej w tym harnessie opisać, tak, ale nie można, bo jak jest za dużo, to z drugiej strony się gubi, nie. Teraz gdzieś trzeba…

Łukasz Kałużny: Czy wiesz co, ja się zastanawiałem, czy na przykład, że macie też zestaw z tym po prostu skilli do architektonicznych, do użycia pewnych rzeczy, że jak chcesz rozszerzyć, to może użyj tej moduły i dokładnie w ten sposób działa. A tu masz na przykład plik źródłowy i linka do tego do GitHuba, że tu masz źródła, żeby do tego modułu zobaczyć, że właśnie w tym. To tak podpowiadając po tym, jak sobie potestowałem to.

Piotr Karwatka Jasne. Słuchaj, to dzięki za feedback, na pewno będziemy go uwzględniać.

Szymon Warda: Dobrze, to teraz kolejny element, który też jest bardzo ciekawy właśnie, bo poszliście bardzo praktycznie. W sensie macie monolit, to już nawet sam mówisz, który można skalować i tak dalej. W takim razie czemu monolit? Czemu nie mikroserwisy? Tak trochę rzucam to tak między pazury, bo doskonale sobie zdajemy sprawę, ale jakie było Wasze uzasadnienie tego wszystkiego? Bo tam też będzie element AI-owy, zakładam.

Piotr Karwatka Wiesz co, akurat chyba nie tutaj. Tutaj nie ma chyba elementu AI-owego. Tu jest element taki zdroworozsądkowy, co nie?

Łukasz Kałużny: Czyli najlepszy.

Piotr Karwatka Tak, kiedyś czytałem bardzo fajny, to był chyba blog post, ale on był bardzo długi, bo ktoś z zespołu Shopify opisał jak dokładnie jest zarządzane Shopify, które też jest chyba najbardziej znanym takim monolitem. I oni mają taki monolit bardzo sprytny, że te moduły są takie izoformiczne, że one od siebie właśnie nie mogą zależeć. I czy to się jakoś chyba nawet inaczej nazywa, już nie pamiętam, ale w każdym razie, że moduły są od siebie niezależne, mogą być osobno wydawane wersje tych modułów. I my poszliśmy dokładnie tą drogą, dlatego, że ja z mikroserwisami mam złe doświadczenia, bo…

Szymon Warda: Jak prawie każdy, kto ich używa.

Piotr Karwatka Tak, to był bardzo duży hype. Nawet e-booka kiedyś napisałem o mikroserwisach, więc no nie można powiedzieć, żeby mi to było obca, albo żebym tego w tamtym czasie nie lubił, bo byłem fanem. Ale jak się zważy ile to dodaje takiego overheadu, zwłaszcza takiego DevOpsowego, tych wszystkich różnych tam trudnych rzeczy, zależności, to się wszystko wypierdala na końcu, to kurde, to się w ogóle nie, to się najczęściej w ogóle nie opłaca, co nie?

Łukasz Kałużny: Czyli jest tak. Wiesz co, mieliśmy przedwczoraj, jak byliśmy na jednej konferencji, takiej luźniejszej, to ktoś rzucił coś, że mają 70 mikroserwisów i że to jest MVP.

Piotr Karwatka Kurcze.

Szymon Warda: Ale dzieje się.

Piotr Karwatka Wiecie co, ja myślę, że ludzie po prostu tak jakby zapominają, dlaczego te mikroserwisy się stały hot. A czemu one się stały hot? One się stały hot, bo były firmy takie, nie wiem, jak jakiś Amazon, Zalando i tak dalej, które miały potężne systemy monolityczne, bo one były tworzone bardzo, bardzo dawno. I tam był już taki problem, że tego już nie szło dalej dźwignąć, bo tam był dług technologiczny, bo tam były różne zależności i oni to refaktoryzowali na te mikroserwisy i każdy się tam jarał, że fajna metoda, bo teraz na przykład zespół, który był zblokowany ze swoją rzeczą…

Łukasz Kałużny: Nie musi czekać.

Piotr Karwatka Bo tam inny zespół, tak, nie musi czekać na przykład.

Łukasz Kałużny: Na koniec dnia i tak to są rozproszone monolity, jak zaczniemy, patrzymy.

Piotr Karwatka Często tak, albo z kolei są tak granularne te usługi, że są za bardzo granularne.

Szymon Warda: I jest overhead komunikacyjny i to się wywala po prostu.

Piotr Karwatka Jak ktoś robi mikroserwis typu getdate na przykład, ja już widziałem takie rzeczy, to jest szalone.

Łukasz Kałużny: Ja wiem, wiem.

Szymon Warda: To są pikoserwisy.

Łukasz Kałużny: Czekajcie, wiecie co, ja wam zalinkuję taki filmik. Był kiedyś ten, taka parodia dlaczego nie możemy wdrożyć funkcji? Bo tamten jeszcze czegoś nie wystawia i koleś na tablicy rozrysowuje taką… Kurde, był kiedyś taki ten…

Szymon Warda: Był, wrzuciłeś.

Łukasz Kałużny: Był, wrzucimy to, jest świetne, rozrysowuje na tablicy tłumacząc przejście przez mikroserwisami czego gdzie brakuje i dlaczego nie mogą wystawić typu data urodzenia na frontendzie.

Piotr Karwatka No właśnie, właśnie.

Łukasz Kałużny: Dobra, słuchaj, w tym miejscu idąc sobie tak powoli do końca, takie przedostatnie grube pytanie, macie bardzo ciekawy model licencyjny, za który enterprise’owo bardzo szanuję, bo jesteście na licencji MIT, ale macie stwierdzenie o homologacji i certyfikacji. Więc tak jak z Szymonem dzisiaj jechaliśmy do Gdańska, się zastanawialiśmy, można powiedzieć, że jest to ciekawa myśl na monetyzację open source’u.

Szymon Warda: Która jest konieczna, to w ogóle bez dwóch zdań i open source szuka tej drogi od kilku lat już ewidentnie.

Piotr Karwatka Posłuchajcie, żaden projekt open source się nie utrzyma, jak nie będzie zarabiał w jakiś sposób kasy, bo to są po prostu duże nakłady czasu i czas to pieniądz. I teraz my eksperymentujemy, bo wcześniej jak właśnie pracowaliśmy nad Vue Storefrontem, teraz Alokai, to tam był prostszy model, bo on był na zasadzie clouda, że był cloud hosting tego frontendu. Ludzie to rozumieli i płacili za to i to działało dobrze. Teraz trochę wydaje mi się, że to już nie ma za bardzo uzasadnienia z różnych powodów, ale też z takiego powodu, że teraz ten DevOps jest też przez AI robiony często, łatwo można wystawić, są nowe usługi jak Railway albo inne, super hosting bardzo prosty. Nam się to przestało jakby tak spinać, że to chyba jest za mała wartość. I zaczęliśmy szukać tej wartości. I teraz w naszej wersji enterprise są tak naprawdę dwie wartości i to zaraz powiem, bo to jest też ciekawe. Są dwie wartości. Pierwsza, tam są po prostu płatne moduły. Tam są takie moduły typu, nie wiem, taki zaawansowany record lockings z optymistycznym merge’owaniem zmian, że jak dwie osoby edytowały ten sam rekord, to to tam się nie wypierdzielili, tylko pokazuje, że tutaj sobie zmerge’uj, coś jak Google Docs, że tam można pracować na jednym tym. I to jest fajna funkcja, dużo ludzi o nią pyta i ona tam faktycznie w tym enterprise jest. A druga, to jest tam z rzeczy związanych z security i jest tam kilka. Tu factor authorization, ale też SSO, takie wiecie, enterprise bardziej rzeczy, co nie? I to jest jedna rzecz. Druga rzecz, te audyty, homologacja. My mówimy coś takiego: słuchajcie, używacie Open Mercato, zajebiście robi Wam to partner albo sami sobie developujecie. Ekstra! To tak jakbyście budowali swojego kampera. Budujesz kampera, to kupujesz z Fiat Professional najczęściej. Najczęstszy camper to jest Fiat Ducato, wiadomo. Kupujesz Fiat Professional, takie nadwozie Fiata i tam jest w ogóle kierownica, siedzenia są. Ale nie ma obudowy. I to w sumie jeździ, bo to wszystko ma. Ale nie można tym jeździć na drogę. Dlaczego? Bo to nie ma homologacji drogowej. To będzie mało homologację jak się zamontuje nadwozie z pasami bezpieczeństwa, jakieś siedzenia tam, tyle, ile ma mieć tych siedzeń i w ogóle. I wtedy jakiś tam urząd daje pieczątkę po badaniu technicznym, że ten samochód ma homologację i on może jeździć po drodze. I my mówimy: tu u nas jest tak samo, możecie to budować sami, ale jak chcecie to tak pewnie wypuścić na produkcję, to my Wam tą homologacje zapewnimy. Czyli zrobimy code review, testy, sprawdzimy czy ten kod dopisany jest zgodny z architekturą Open Mercato, nie psuje core’a i tak dalej. I powiem Wam, że to trafia, w sensie ci klienci mówią: kurcze, ma to sens, bo w zeszłym tygodniu u nas pan Darek zrobił tam vibe codingiem jakieś ten, wszystko działało, a potem baza znikła. To teraz jak Wam zapłacimy, to Wy sprawicie, że nie zniknie. A my mówimy: dokładnie tak, bo my to w zasadzie zapewniamy, co nie? Więc jest do kogo się potem zwrócić w razie czego, jak jest problem.

Łukasz Kałużny: Gracie delegacją ryzyka po prostu.

Piotr Karwatka Trochę tak, ale to jest taka jakby faktyczna wartość, tak, że jakby ten support jest. A druga rzecz, myślałem, że to nie będzie tak dobrze działało, a dobrze to działa dosyć, że ludzie mówią faktycznie: ej, macie ten moduł od security, co nie, w tym enterprise. To my musimy kupić, bo nam to jest po prostu potrzebne. Ja myślałem, że to będzie mniejsza wartość, dlatego że…

Szymon Warda: SSO jest super ważne.

Piotr Karwatka Tak, ale ja myślałem, wiesz co, że ludzie będą nawet sami to jakoś budować.

Łukasz Kałużny: Ale wiesz co?

Piotr Karwatka Ale ludzie nie chcą tego dotykać. Nie chcą tego dotykać kurcze.

Szymon Warda: Super.

Łukasz Kałużny: Mnie rozwaliło jak zobaczyłem, że któreś ministerstwo, pewnie kojarzysz lepiej, bo ja tylko kojarzę jak zacząłem z któregoś ministerstwa, że szukają partnera do zrobienia jakiegoś rejestru czy czegoś takiego.

Piotr Karwatka Było zapytanie na zrobienie na Open Mercato, jako open source’owym systemie, jakiegoś systemu do obsługi kancelarii. I wiem, wiem, bo słyszałem od firmy, która wygrała jakby to ten, bo to nie był przetarg, ale takie zapytanie…

Łukasz Kałużny: Zapytanie, to było zapytanie, tak, w formie zapytania.

Piotr Karwatka I robią tego POC-a. W ogóle ja jestem mega dumny, że nasz software będzie używany przez rządową jakąś tam instytucję.

Szymon Warda: Słuchaj, to teraz powoli kończymy i takie spojrzenie wstecz, bo sam mówiłeś, że zaczynaliście Open Mercato już jakiś czas temu. Teraz gdybyś miał zacząć teraz od zera, co byś zmienił? Jakie wnioski i jak by to wyglądało? Szybciej, wolniej? Co by się działo?

Piotr Karwatka Wydaje mi się, że bym przeszedł… Jedyne co bym zmienił, to bym zaczął od razu od Spec-Driven Development, bo zaczęliśmy to robić po dwóch, trzech miesiącach.

Szymon Warda: To i tak szybko.

Piotr Karwatka To i tak szybko. Ale gdzieś tam ileś rzeczy powstało bez tego. I teraz to nie chodzi o to, że one są jakieś złe, to jest wszystko git, tylko bardziej na tej zasadzie, że nie mamy na przykład tych specek, a by się przydały. Bo czasami jak robimy nowe specki, to faktycznie te stare specki są mega w użyciu. Przy czym jak sobie zobaczycie na repo, to ilość dokumentacji w Open Mercato wydaje mi się, że ona bije w ogóle jakieś wszystkie inne systemy, nawet enterprise, bo wiadomo było zawsze, tak, że jak się robi duży system, to trzeba utrzymywać, nie wiem, repozytorium ADR, nie, że Architecture Decision Record i tak dalej. Tylko nikt tego potem nie robił albo nie aktualizował. I tam były stare rzeczy, co jest jeszcze gorsze niż jakby nie było ich w ogóle czasami. A my to mamy, bo LLM to po prostu robi za nas.

Szymon Warda: I czyta.

Piotr Karwatka Czyta. No właśnie i czyta. I to jest właśnie niesamowite.

Łukasz Kałużny: Jestem ciekaw jednego, do czego dojdziecie, to co ja będę obserwował, czyszczenia tej dokumentacji, bo to będzie…

Szymon Warda: Bo to będzie zabijało kontekst.

Łukasz Kałużny: Wiesz, jestem ciekaw tego, bo będzie ten moment, że będzie trzeba pewnie usuwać z repo historyczną dokumentację.

Piotr Karwatka 100%, ja już myślę, że to już jest ten moment, że już część by trzeba było wywalić.

Szymon Warda: Albo skillami tym odpowiednio zarządzać generalnie, kiedy i kto ma tam zerkać.

Piotr Karwatka Albo skillami. Właśnie też jest takie podejście, to dyskutujemy, czy w to iść, bo mieliśmy taki pomysł, żeby w ogóle wszystko było skillami, nie, że tak jak jest task router i on u nas jest taką wielką tabelą i tam jak chcesz dodać moduł to tu, a jak tu to ten, to żeby zrobić do każdego takie malutkie skillki. Tylko też jest problem, bo Codex i Cluade, inne nie wiem, ale pewnie tak samo, one mają jakiś ograniczony budżet na wczytywanie skilli. Nie możesz mieć za dużo skilli.

Łukasz Kałużny: Tak, na tooli tak. I wiesz co to jest? Bo ja to sobie, trafiłem na to ostatnio i jest tak, że no niestety kurde, bo jak chcemy zlecić duży nawet sub agentami, to nawet ten orkiestrator zaczyna… On i tak teraz już w kontekst widzę, że stabilnie, powyżej około tych 400 tysięcy tokenów jest stabilny, ale on teraz zaczyna ubijać listę i ma taki tool do dynamicznego wyszukiwania skilli i dynamicznego wyszukiwania tooli MCP. I to zaczyna w tym. Druga sprawa, ja się boję potem o ten cognitive load, bo to jest rzecz, którą, też Szymon czasami się ze mną nie zgadzasz, ale wolałbym mieć jednak dość dobrze świadomość co tam siedzi, o tak, że wiesz, że jestem w stanie to jednak swoim mózgiem objąć, co tam może się dziać. To na tej zasadzie, że ja nie muszę tego znać dokładnie, tylko mieć tę mechanical sympathy do tego właśnie.

Piotr Karwatka No to na pewno jest też. Ten cognitive load jest ważny i wczoraj miałem dyskusję po tej prezentacji tutaj na infoShare i fajne wnioski były, bo jakiś taki wniosek się pojawił, że te agenty, jak chodzi o kodowanie, no to to już jest taki level naprawdę doświadczonych gdzieś tam kurcze devów, architektów i tak dalej. Ale czy możesz im wszystko zlecić? Pewnie możesz im coraz więcej zlecić, ale czy chcesz? Znaczy w sensie jaka będzie na końcu Twoja rola jako, nie wiem, architekta albo po prostu twórcy. Bo ja na przykład robię ten code review, to się łapię na tym, że ja go nie robię dlatego, że ja tam wychwytuję faktycznie błędy. Znaczy zdarza się, tak, zdarza się, że wychwytuję, ale to się bardziej zdarza. A czemu to robię ciągle? Dlatego, że ja chcę wiedzieć, co jest w moim systemie. Bo jak przyjdzie klient i mnie zapyta, czy my mamy tam szyfrowanie, czy coś tam, to ja chcę wiedzieć, że faktycznie mamy, że to działa, ja to dlatego czytam. I bez tego nie uważałbym Open Mercato za swój system, a dzięki temu mówię szczerze: tak, wiem co tam jest.

Szymon Warda: Ja tam osobiście widzę jako taką rolę właśnie takiego team leadera, który ma dowolną ilość developerów, kiedy chce i dalej trzeba tą pieczę trzymać mimo wszystko.

Piotr Karwatka Tak, to jest prawda. A zobaczcie też kiedyś, jak były duże firmy i ktoś miał na przykład zespół developerów, nie wiem, 20 osób albo 30 osób podzielony na jakieś tam, wiadomo, mniejsze zespoły często, ale czy tam ludzie na przykład robili ten code review, albo wiedzieli co tam wpada?

Łukasz Kałużny: Piotrek, miałem, właśnie zadałem pytanie takie ten, słuchajcie, też możecie u siebie znaleźć w zespole, albo przemyśleć, ile tygodniowo lub miesięcznie klikacie PR-ów, accept, bo kolega napisał: weź mi tu klepnij pull requesta.

Piotr Karwatka Kurcze, to chyba jest klasyk.

Łukasz Kałużny: Wiesz co, ja miałem nawet rozmowę gdzieś z klientem, bo chciał robić review kodu czy coś teraz tam w projekcie, w którym jesteśmy w takim momencie, nie jest jeszcze na produkcji, więc idą jeszcze weryfikacje biznesowe i iteracje. Powiedziałem: wiecie co, to zrobimy sobie pull requesty, ale one i tak będą szły automatem bez review, na zasadzie, żeby zostały. Jak chcecie widzieć większe paczki, co się działo, to i tak zróbmy ten, żeby agent mógł to sobie zaakceptować w tym, sam zmerge’ować te pull requesty, bo to nie ma wartości.

Piotr Karwatka No to prawda, często tak właśnie jest.

Szymon Warda: Dobrze, kończymy.

Łukasz Kałużny: Kończymy.

Piotr Karwatka Super.

Łukasz Kałużny: Dzięki za super rozmowę.

Szymon Warda: Dzięki wielkie.

Piotr Karwatka Dziękuję bardzo.