Czy Open Mercato to AI slop?

TLDR: Open Mercato nie jest AI slopem. Wręcz przeciwnie. Po sprawdzeniu tego w praktyce widzę w nim jedną z możliwych przyszłości greenfield software developmentu - agentic AI engineering oparty na specach, reużywalnych skillsach, izolowanym wykonaniu, review i decyzjach człowieka.

Najbardziej użyteczny mały hack, jaki zrobiłem w tym tygodniu

Wczoraj wysłałem prawdopodobnie najmniejszy feature, jaki do tej pory zrobiłem dla Cezara, a mimo to zmienił mój sposób pracy bardziej niż wiele większych rzeczy. Sam w sobie nie jest rewolucją. Połączyłem trzy elementy, które prawie już do siebie pasowały: Cezar + kod QR + prywatna sieć mesh.

Cezar miał już webowy cockpit przyjazny dla telefonu. Brakowało mi tylko drogi od zdalnej instancji Cezara do telefonu, która byłaby absurdalnie prosta. Teraz uruchamiam Cezara na zdalnej maszynie, dostaję kod QR bezpośrednio w terminalu, skanuję go aparatem iPhone’a i - bang - mam cockpit na telefonie.

zdalna maszyna
      ↓
    Cezar
      ↓
prywatny mesh
      ↓
 QR w terminalu
      ↓
     📱

Implementacja dodaje jawny mechanizm trusted hosts dla prywatnego frontu oraz skanowalny adres startowy. Tailscale jest moją siecią z wyboru, ale design celowo nie jest związany tylko z Tailscale. Transportem może być tailnet, mesh WireGuard albo podobna prywatna sieć. Cezar może pozostać w local mode zamiast zamieniać się w publicznie wystawioną usługę z osobnym systemem logowania.

Ja używam Tailscale, bo plan Personal jest obecnie darmowy i wyjątkowo wygodny do takiej prywatnej sieci. Poszczególne rodzaje zasobów mają własne limity planów, więc przed budową prywatnego hyperscalera warto przeczytać pricing. 😎

https://tailscale.com/pricing

Dla mnie najważniejszy jest developer experience. Bez nowego konta Cezara. Bez nowego hasła do Cezara. Bez kopiowania URL-a z terminala do telefonu. Skanujesz, otwierasz, pracujesz.

Kiedy development odbywa się w chmurze, a agenci są rozproszeni po zdalnych maszynach, taki drobiazg zaczyna mieć duże znaczenie. Dzięki Tailscale. Zmieniliście zaskakująco dużą część mojego sposobu pracy. 🫶🏻

PR-y:

https://github.com/open-mercato/cezar/pull/1070

https://github.com/open-mercato/cezar/pull/1071

Pojechałem do Wrocławia sprawdzić pewną hipotezę

Kilka dni wcześniej byłem na Open Mercato HackOn we Wrocławiu. Razem z Mateuszem Wiatrzykiem, jako #aveCezar, wygraliśmy track Best Cezar Feature i zajęliśmy drugie miejsce w People’s Choice.

Mateusz opublikował bardzo dobry opis całego weekendu:

https://pl.linkedin.com/pulse/veni-vidi-vici-czyli-jak-wygrali%C5%9Bmy-hackathon-open-mercato-wiatrzyk-xtduf

Zabawne jest to, że rozwijaliśmy Cezara przy pomocy Cezara. Brzmi jak zdanie z marketingu. Niestety dla mojego sceptycyzmu naprawdę działało.

Po hackathonie zapytałem Patryka Lewczuka o możliwość dalszego rozwoju z Open Mercato Core Teamem. Odpowiedź była w skrócie: nie.

Co rozumiem. W momencie pisania tego tekstu mam dziesięć PR-ów do Cezara, z których tylko dwa weszły do upstreamu. Najwyraźniej zwycięstwo w tracku Cezara nie odblokowuje automatycznie sekretnego kontraktu o pracę.

Mam 36 lat i nadal jestem tak naiwny. 🤡😎

Byłem zdruzgotany przez około dwie minuty. Potem wróciłem do moich Cezarów.

Mateusz założyciel teamu #aveCezar stworzył #1045 dodaje integrację trackerów Jira i Linear, w tym przeglądanie issue, uruchamianie workflowów z kontekstem ticketu i automatyzacje wyzwalane przez tracker. #1047 to kolejny duży element - workspace dashboard z aktywnością, raportowanym usage i cost, outcome’ami, eksportami i observability.

https://github.com/open-mercato/cezar/pull/1045

https://github.com/open-mercato/cezar/pull/1047

Autonomiczny development sterowany issue trackerami robi się niepokojąco bliski. A wszystko to może finalnie siedzieć w Cezarze na telefonie, podczas gdy prawdziwa praca dzieje się gdzieś w chmurze. 🤯

Moja fabryka robi się geograficznie rozproszona

Aktualnie korzystam z czterech publicznych cloudów:

• https://www.hetzner.com/
• https://upcloud.com/
• https://www.ovhcloud.com/
• https://www.digitalocean.com/

I mam własną rzecz w developmentcie. Prawdopodobnie będzie mieszkała tutaj:

https://tiny-cloud.dev

To absolutnie nie jest announcement, pomimo faktu, że właśnie ogłaszam jej istnienie na publicznym blogu.

tiny-cloud jest nadal bardzo WIP. Mój control plane i scheduler są bałaganem. Go jest dla mnie nowe. Więcej o tym będzie później. 🤓 Idea jest prosta: chcę mieć malutki control plane dla maszyn uruchamiających moje agentowe workloady.

W tej chwili moi agenci są już rozproszeni na trzech kontynentach.

Dlaczego? Lubię redundancję. Tyle. 🐳

A potem Open Mercato uruchomiło chmurę

Podczas HackOn Open Mercato pokazało także Open Mercato Cloud. To w praktyce dostępne z przeglądarki środowisko developerskie ukierunkowane na AI engineering - sandboxowa infrastruktura bez konieczności samodzielnego budowania i utrzymywania całej warstwy infra.

Jako zwycięzcy tracku Cezara dostaliśmy z Mateuszem trzy miesiące dostępu do Sandboxów. Po dodaniu miesiąca dostępnego dla uczestników hackathonu mamy całkiem wygodną przestrzeń do eksperymentów.

Dostaliśmy Developer tier. Moja pierwsza reakcja była taka, że cena wydaje mi się trochę wysoka jak na indywidualnego developera.

Z drugiej strony może po prostu nie jestem targetowym developerem. 🤣

Mam konta u czterech dostawców chmurowych i dla zabawy piszę własny control plane. To nie jest normalne zachowanie klienta. Dla kogoś, kto chce budować software zamiast spędzać sobotę na debugowaniu schedulera, Open Mercato Sandboxes mają znacznie więcej sensu.

I trzeba im oddać jedno: produkt wpłynął na moją własną architekturę. Po przetestowaniu Sandboxa zmieniłem kilka założeń w control plane i schedulerze tiny-cloud.

Dominik Pałatyński (https://pl.linkedin.com/in/dominik-pa%C5%82aty%C5%84ski-097029245), jedna z głównych osób stojących za Sandboxami, podziękował mi też bezpośrednio za auto-scaling governor, który zrobiłem dla Cezara podczas hackathonu:

https://blog.cygankiewicz.com/pl/cezar-agent-orchestrator/

To było miłe. 🙏🏼☺️

Może kiedyś napiszę porządny review Sandboxa.

Ten blog ma dwanaście dni

Założyłem ten blog 13 września 2026. Dwanaście dni później mam już czytelników w Europie, Ameryce Północnej, Azji i Ameryce Południowej.

2026 jest szalony. Może to tylko ja, ale nigdy wcześniej nie musiałem aktualizować swojego modelu świata tak szybko. Produkty się zmieniają, modele się zmieniają, ekonomia się zmienia i moje własne plany też się zmieniają. Velocity jest absurdalne.

Mój poprzedni tekst, Etyka eksploatacji agentów, dostał zaskakująco dobry feedback. Jedno zdanie szczególnie zostało z Mateuszem:

“Ale dla ogromnej klasy małych projektów marginalny koszt dojścia do pierwszej użytecznej wersji zbliża się do poziomu, który zaczyna przypominać zero. I moim zdaniem to jest świetne.”

Powiedział mi, że to zdanie go poruszyło.

Dla wielu developerów, programistów i szerzej ludzi z IT takie zdanie wcale nie musi brzmieć świetnie. Po kolejnych dwóch dniach myślenia dużo lepiej rozumiem tę dwuznaczność.

Nadal uważam, że zmierzamy w stronę niezwykłego dobrobytu

Nie jestem wyrocznią ani jasnowidzem. Mam jednak roboczą hipotezę.

Myślę, że możemy zmierzać w stronę poziomu dobrobytu, który jeszcze niedawno trudno byłoby sobie wyobrazić. Nie będzie rozłożony równomiernie. Nigdy nie był. Mam sporo zarzutów do naszej korporacyjno-kapitalistycznej rzeczywistości. 🤮 Ale narzekanie na mechanizm dystrybucji nie sprawi, że technologiczna zmiana zniknie.

Co więc robimy?

Ja założyłem blog. Wczoraj kolega powiedział mi: “Myślałem, że blogi umarły”. Nie ma racji, ale w tej obserwacji jest coś ważnego. Dla niego blogi są martwe, bo ich nie czyta. Dla mnie oczywiście żyją, bo je uwielbiam. Na całym świecie są fascynujący ludzie piszący na swoich małych kawałkach internetu, zamiast wrzucać każdą myśl na Instagram, Facebook, LinkedIn czy X.

Mimo wszystko blogowanie jest dla mnie trudne. Zacząłem pisać ten tekst o 04:40 CET. O 07:30 nadal był work in progress. Piszę najpierw po angielsku nie dlatego, że jest mi szybciej. Zdecydowanie nie jest. Robię to dlatego, że chcę być lepszy z angielskiego.

Nie każdy musi zostać blogerem. Nie każdy musi być programistą. Nie każdy potrzebuje dyplomu z informatyki. I wbrew temu, co może sugerować historia mojej przeglądarki, nie każdy musi zostać full-stack AI architectem. 🤪

W usługach nadal będzie ogrom pracy. Prawdopodobnie bardzo dziwnej pracy.

Potrzebuję concierge’a dla kota

Dam celowo głupi przykład. Mam kota. 🐈 Kocham go bardzo, ale mam lepsze rzeczy do roboty niż osobiste wożenie go na rutynową wizytę do weterynarza.

Czego więc tak naprawdę chcę? Cat concierge.

Człowiek odbiera kota, zabiera go do weterynarza i później wysyła mi uporządkowany raport. AI in the loop. Moje własne AI prawdopodobnie przetworzy ten raport jeszcze zanim kot wróci do domu.

Tak, mam coś z raportami. Nic na to nie poradzę. Prawie wszystko, co robię w życiu, ostatecznie zamienia się w dane.

Ta praca nie nazywa się “programista”. Nie nazywa się “prompt engineer”. To usługa oparta na zaufaniu, fizycznej obecności i odpowiedzialności, wspomagana software’em, którego stworzenie staje się niemal darmowe.

Podejrzewam, że takich rzeczy zobaczymy bardzo dużo.

Więc - czy Open Mercato to AI slop?

Właśnie dlatego pojechałem na hackathon. Chciałem doświadczenia z pierwszej ręki.

Open Mercato otwarcie mówi o agentic engineering. Projekt opisuje się jako AI-engineering foundation framework i mocno stawia na architecture-aware agents, reużywalne skills oraz spec-first development.

W README brzmi to świetnie. Chciałem zobaczyć, co się dzieje, kiedy ludzie naprawdę tego używają.

Moja odpowiedź po HackOn jest taka:

Nie. Open Mercato nie jest AI slopem.

I co ważne, nie mówię tego dlatego, że każdy fragment kodu jest idealny. Nie jest. Nic ciekawego nie jest idealne.

Mówię tak dlatego, że najciekawszą częścią Open Mercato nie jest “AI wygenerowało dużo kodu”. Najciekawszy jest system wokół generowania.

Samo Open Mercato

Główny framework Open Mercato to imponujący codebase do aplikacji CRM, ERP i e-commerce.

Idealny? Nie. Skończony? Też nie. To WIP i to widać.

Ale jego zakład architektoniczny ma dla mnie sens: jeśli agenci mają generować znaczącą część greenfield systemu, to architektura, konwencje i specyfikacje muszą istnieć zanim agent zacznie je wymyślać.

Projekt nazywa to spec-first development i architecture-aware AI harness.

To jest prawie przeciwieństwo slopu.

AI slop wygląda tak:

prompt
  ↓
wielka bryła outputu
  ↓
ship it 🤡

Agentic engineering powinien wyglądać bardziej tak:

intent
  ↓
spec
  ↓
architektura
  ↓
agent
  ↓
izolowana implementacja
  ↓
testy
  ↓
review
  ↓
decyzja człowieka
  ↓
merge

Ta różnica ma znaczenie.

Cezar

Cezar jest GOAT-em. 🐐

Napisałem już o nim cały osobny tekst, więc oszczędzę Wam kolejnego listu miłosnego. Uruchamia coding agents równolegle, daje taskom izolowane Git worktree, ma kolejki, workflowy i live visibility, a do tego działa lokalnie albo na VPS-ie.

Dla mnie stał się execution layerem mojej małej fabryki.

Nic więcej nie trzeba dodawać. 🐐

Open Mercato Skills

To jest prawdopodobnie największy mindfuck dla mnie:

https://github.com/open-mercato/skills/

Przed HackOn prawie nie używałem Skills. Nie miałem dla nich miejsca w swoim workflow. Widziałem też w internecie komentarze sprowadzające skills do czegoś dla amatorów i przez jakiś czas kupowałem tę narrację.

Myliłem się.

Open Mercato Skills opakowują powtarzalne procedury inżynieryjne w instrukcje czytelne dla agenta: tworzenie PR-ów, code review, stabilizację CI, pisanie speców, integration testing, merge management i więcej. Jedynym powodem, dla którego ukończyłem feature dla Cezara podczas hackathonowego weekendu w procesie przypominającym kontrolowaną inżynierię, były ich Skills.

To kompletnie zmieniło moje zdanie.

Model ma znaczenie. Prompt ma znaczenie. Ale coraz częściej prawdziwa dźwignia brzmi:

jakie procedury agent potrafi już niezawodnie wykonać?

To jest dużo bliżej wiedzy organizacyjnej niż promptowania.

Sandboxes

Sandboxes są trzecim elementem. Prawdopodobnie nie są optymalizowane pod kogoś takiego jak ja, bo lubię operować infrastrukturą i najwyraźniej traktuję pisanie schedulera w Go jako formę rekreacji.

Dla biznesów, zespołów i developerów, którzy nie chcą utrzymywać własnego control plane, propozycja jest znacznie prostsza.

To działa. To ma wartość.

Jeśli jesteś full-stack osobą, która lubi robić wszystko samodzielnie, płacenie komuś za tę część stacku może na początku wyglądać zabawnie. Potem uświadamiasz sobie, że sprzedają dokładnie tę warstwę, którą być może powinieneś przestać budować od nowa.

Nadal nie jestem pewien, czy to ja jestem klientem. Jestem za to całkiem pewien, że takich klientów jest wielu.

Co więc właściwie pokazuje Open Mercato?

Ta część jest dla mnie ciekawsza niż CRM czy ERP.

Open Mercato jest eksperymentem w tym, jak wygląda software engineering, kiedy agenci stają się normalnymi uczestnikami procesu developmentu. Nie autocomplete. Nie “napisz mi komponent React”.

Agenci dostają specy. Agenci korzystają ze wspólnych skillsów. Agenci pracują w izolowanych środowiskach. Agenci robią review innym agentom. Ludzie decydują, co trafia do upstreamu.

To właśnie tę tezę pojechałem testować do Wrocławia.

Mój wniosek jest taki, że greenfield software development przesuwa się w stronę spec-first, agentic engineering.

Nie każdy projekt. Nie jutro. Nie bez ludzkiego osądu. Ale kierunkowo - tak.

I to nie jest AI slop.

Slop to niekontrolowany output.

Tutaj ktoś próbuje zaprojektować fabrykę.

Jest jeszcze jedna rzecz

Skoro najwyraźniej nie ma dla mnie oczywistego job-shaped slotu w moim kraju 😎, uznałem, że czas sobie taki stworzyć.

Zakładam spółkę.

Przez lata miałem głowę w chmurach, jeśli chodzi o miejsce. Szwajcaria? Luksemburg? Malta? UAE? Delaware LLC?

Spędziłem absurdalnie dużą część życia na czytaniu o podatkach i handlu międzynarodowym. Dziwne zainteresowania jak na dzieciaka, wiem. Nic na to nie poradzę. 🤷🏻

Dzisiaj mam jasność.

Gliwice, Polska.

Polska sp. z o.o..

Podatki oczywiście ssą. Ale mój ojciec mówił coś, co zostało ze mną:

“Jeśli płacisz podatki - nawet wysokie - to właściwie świetnie. To znaczy, że masz przychody i zyski.”

W porządku.

Ventures Originals

Firma będzie AI-native.

9 sierpnia obejrzałem: “Aula Polska #194: Fireside Chat o Agentach AI | Bartek Pucek & Piotr Nowosielski:”

https://www.youtube.com/watch?v=w52Q64HXyOU

Został ze mną jeden podział z tej rozmowy: firmy pozostające w tyle z adopcją AI, firmy dokładające AI do istniejącego sposobu działania oraz firmy rzeczywiście AI-native.

Wiem, którą chcę zbudować.

Roboczy kierunek dla Ventures Originals to research wokół:

• safety
• operations
• inference
• economics

A pierwsza teza produktowa staje się coraz bardziej klarowna.

Orchestrator orchestratorów

Execution layer już istnieje. Cezar może być jednym runtime’em. Obok niego mogą działać kolejne.

Produkt, który mnie interesuje, siedzi poziom wyżej:

        Orchestration Control Plane

        ┌─────────────────────────────┐
        │ Desired state / Policies    │
        │ Scheduling / Routing        │
        │ Budgets / SLOs / Security   │
        │ Registry / Discovery        │
        │ Observability / Audit       │
        └──────────────┬──────────────┘
                       │
           ┌───────────┼───────────┐
           ▼           ▼           ▼
        Cezar       LangGraph    Temporal
        runtime      agents       workers
           │           │           │
      Claude/Codex  models/tools  services

Control plane dla orchestratorów. Nie kolejny agent UI. Nie kolejny wrapper na jeden model.

Policies, routing, scheduling, budgets, SLOs, security, observability i discovery ponad systemami wykonawczymi.

Wiem, że to nie jest łatwe.

Właśnie dlatego mnie to interesuje.

Szukam co-foundera

Nie spieszę się. Osoba, od której szczególnie chciałbym usłyszeć, należy do dość rzadkiej grupy:

• technical founder z realnym doświadczeniem exitów
• były CTO albo staff-level engineer z mocnej przejętej firmy
• ktoś naprawdę głęboki w distributed systems, AI infrastructure albo capital deployment
• albo, bo życie powinno pozostać ciekawe, Bitcoin whale lub Solana wizard, który naprawdę operuje infrastrukturą zamiast tylko wrzucać wykresy 😎

Najbardziej interesujący overlap kompetencji:

• distributed systems
• effective capital deployment
• digital transformation
• AI

Na tym etapie potrzebuję przede wszystkim ekspertyzy i około 20 minut rozmowy tygodniowo. Bez pitch deck circus. Nie ma pośpiechu.

Mój obecny szkic inkorporacji to 100 000 zł kapitału początkowego. Rozważam zarezerwowanie 5% udziału founderskiego dla właściwego co-foundera przy wkładzie 5 000 zł, oczywiście z zastrzeżeniem finalnych dokumentów spółki oraz setupu prawnego i księgowego.

Polska osoba fizyczna albo firma uprościłaby mechanikę, ale geografia nie jest twardym ograniczeniem. Jeśli jesteś w Azji albo Ameryce Północnej, to też jest OK.

To eksperyment.

Jeśli Ventures Originals nie będzie rentowne w ciągu roku od inkorporacji, zamknę spółkę.

Proste.

Małe okno offline

Przez najbliższy tydzień albo dwa będę z dala od komputera, więc mogę odpowiadać wolniej. Nadal będę zerkał na inbox.

Fabryka powinna przeżyć chwilę beze mnie.

Mam nadzieję. 🏭🤖💪🏻