AI-assisted development w praktyce - na przykładzie Open Mercato z Piotrem Karwatką
“Najgorsze co można zrobić, to zerknąć.” Piotr Karwatka o pętlach kodujących, w których agent pracuje 4 dni non-stop, a Ty masz siedzieć na rękach. Bo jak zerkniesz, trafisz na głupotę, przerwiesz mu tok myślenia i wszystko się posypie. Witamy w świecie, gdzie spec-driven development zastępuje ping-pong z Claude’em. 🎯 Open Mercato to 750 tysięcy linii kodu, z których żadna nie została napisana ręcznie. Framework do aplikacji biznesowych z hasłem “start with 80% done” - CRM, OMS, WMS w paczkach npm, monolit modularny inspirowany Shopify, stos wybrany pod to, co LLM-y znają najlepiej: Next.js, Postgres, Redis. Core team? 4 osoby full time. Koszt odtworzeniowy? ~20 developerów na rok. ⚠️ Harness AI, skille do specyfikacji, planowania i implementacji, atomowe commity z testami, refinement specek pytaniem “co może pójść źle?” - i open source’owy model monetyzacji, który Piotr porównuje do homologacji kampera na Fiacie Ducato. Bo “w zeszłym tygodniu pan Darek zrobił vibe codingiem jakieś ten, wszystko działało, a potem baza znikła.” Czy AI-assisted development na poważnie wymaga więcej myślenia niż tradycyjne kodowanie? Sprawdź, zanim odpalisz kolejnego agenta bez specki. A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia
Czyli nie, że tylko tam budujemy fajnego CRM-a, ale żeby ten CRM wykorzystywał takie reużytelne 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. 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-owy, 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ł. AgentsMD 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 AgentsMD 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, że tam można sobie projekt nowy wystartować itd. Więc jakby to są takie trzy elementy. Obecnie się bardzo mocno skupiam na tym elemencie właśnie harnessu AI, żeby go zoptymalizować i żeby developer experience był jak najwyższy. Jak zobaczycie w Open Mercato, my siłą rzeczy staramy się nie nadbudowywać jakichś sztucznych tworów na to, co dają takie supertule jak Cloud Codex albo GitHub CLI na przykład. Wiesz co, rozwinąłbym właśnie, bo zahaczyłeś dobrą rzecz w tym, o co chodzi z tymi harnessami u was, czyli jak wy podchodzicie do gate race'ów i innych rzeczy, ograniczenia i walidacji tego. 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 rozkładając ten proces na czynniki pierwsze, to najpierw trzeba zrobić specke, więc do robienia specke też mamy skilla. Potem mamy skilla do planowania, czyli podzielenia tej specke na taski, na jakieś tam atomowe komity, różne rzeczy, a potem do implementacji tego. Więc nam zależy, by 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. To jest duro softu. 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 deweloper, 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. On jest tam w repo publicznych? 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 harnes pod open source'owe agenty kodujące, znaczy modele kodujące, czyli na przykład QN, albo inne. Bo wiecie co, to jest w ogóle też fajne, że ludzie używają tych turbo skomplikowanych, najnowszych modeli, GBT 5.5 albo Cloud 4.7 itd. Na tych modelach większość rzeczy kurczę działa. One są tak dobre, że tam naprawdę jak coś nie działa, to on sobie poprawia itd. 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.
On bardzo mocno na te harnessy patrzy tak literalnie, jak tam jest napisane. I to jest super do testowania, dlatego że jeżeli No ja wykryłem kupę błędów, nie? Że coś mieliśmy pominięta, bo na przykład zmieniła się składnia polecenia CLI do, nie wiem, generowania migracji bazy danych i plot, czego nikt nie zauważył, on zawsze się poprawiał, że wiecie... Wyszukiwał sobie. Tak, odpalał złe polecenie, aha, dobra. I korekta. 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ł, no nie? Zahaczyłeś na temat, który jest dla nas bardzo interesujący. Właśnie ten flow deweloperski, jak to wygląda. Czyli przychodzi osoba, No nie? I mówisz, okej, jest skill do pisania specki. Tak. A byś mógł to wyśle rzeczy, po prostu jak to wygląda całościowo, ten flow? Jasne. Gdzie są narzędzia, które pomagają? 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ł super, no nie?
My mamy ogólnie monorepo, no nie? 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 specke w ramach tego repo, bo też mamy wszystkie specke i też oczywiście są w tym repo. Więc robisz specke w tym repo, no to ten agent robi tą specke 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 specke. Czyli zrobił specke i zadajesz mu takie filozoficzne pytanie, a czego tam brakuje?
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ć na osobne apki, bo te moduły mają bardzo zunifikowany standard i one w założeniach i w naszym harnessie nie mogą od siebie zależeć wprost. Czyli jeden moduł nie może z drugiego tam zaciągać. To do tego jeszcze może dojdziemy. To tylko mówię dlatego, że jakby jedną opcją jest takie skalowanie wertykalne tej apki. Czyli można, nie wiem, moduł produktów odpalić na jednym serwerze, tamten moduł na innym serwerze. Baza danych, no Postgres to też łatwa jest dosyć do skalowania takiego przez jakiś Sharding, Master Slave, albo w ogóle Sharding.
Eventy i tak dalej. Czyli inaczej, tych mechanizmów jest dużo. 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 z jednym plikiem TSX i package JSON wciąga przez npm całe Open Mercato po prostu jako pakiet npm. To w tym trybie, jak jesteś, to Harness AI jest inny niż w trybie Monorepo, czyli rozbudowy Cora, bo ten w Korze to jest taki pod Cora, że tam gdzie co jest. A w tym Standalone to jest bardziej opisane, że tu jest mechanizm eventu, tu jest mechanizm nadpisywania. Czyli jak chcesz coś zrobić, to ten agent będzie starał się nie modyfikować Cora, tylko właśnie użyć tych mechanizmów, żeby osiągnąć efekt.
Czy wiesz co? Harnessy jeszcze musicie popracować nad tymi harnessami od strony, jak nie masz dostępu, bo jak miał dostęp do Monorepo, jak wrzuciłem sobie z dostępem agenta, z dostępem do waszego Monorepo, 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 Monorepo, to jeszcze było problematyczne. O tak, to taki od razu feedback. Super feedback, ale finalnie co, udało się? Tak, udało się. Udało się. To mnie cieszy. Te harnessy właśnie, one cały czas ewoluują i powiem Wam, że tam jest właśnie takie wyzwanie, że chciałoby się jak najwięcej w tym harnessie opisać, ale nie można, bo jak jest za dużo, no to z drugiej strony się gubi. Czy wiesz co, ja się zastanawiałem, czy 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łu i dokładnie on 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.
Pokazano wszystkie 10 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Piotr Karwatka wyjaśnia, jak Open Mercato wykorzystuje AI do generowania kodu i dostosowywania się do potrzeb klienta.
Kontynuacja omówienia AI Engineering Foundation Framework i jego zastosowania w Open Mercato.
Piotr opisuje proces deweloperski, w tym role agenci kodującego i harnessu AI w Open Mercato.
Rozmowa o optymalizacji procesu deweloperskiego w Open Mercato, w tym użyciu małych modeli AI.
Piotr opisuje testowanie procesu deweloperskiego i ewolucję Open Mercato wraz z zmianami w modelach AI.
Kontynuacja omówienia spec-driven development i korzyści z monorepo w Open Mercato.
Piotr opisuje proces planowania i refactoringu speck w Open Mercato, w tym podział na fazy i taski.
Rozmowa o eksperymentach z procesem deweloperskim w Open Mercato, w tym użyciu serwera zdalnego do monitorowania procesu.
Rozmowa o planowaniu czyszczenia dokumentacji i zarządzaniu skillami w Open Mercato.
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.