Is Open Mercato AI Slop?

A developer who won the Best Cezar Feature track at the Open Mercato HackOn in Wrocław concluded that Open Mercato is not AI slop, describing it as a plausible model of greenfield software development built around specs, reusable skills, isolated execution and human review. The author, who has submitted ten PRs to Cezar with only two merged upstream, also shipped a QR-code-plus-private-mesh feature that lets a remote Cezar instance open its mobile cockpit on an iPhone via Tailscale without a new account or password.

is-open-mercato-an-ai-slop Is Open Mercato AI Slop? I went to the Open Mercato HackOn to find out whether agent-built software is the future of engineering or just AI slop at industrial scale. A hackathon win, ten Cezar PRs and several clouds later, I have an answer. TLDR: Open Mercato is not AI slop. Quite the opposite. After using it in anger, my conclusion is that it shows one plausible future of greenfield software development - agentic AI engineering built around specs, reusable skills, isolated execution, review and human decisions. The most useful little hack I shipped this week Yesterday I shipped probably the smallest feature I have built for Cezar so far, and somehow it changed the way I use it more than many much larger features. Nothing here is revolutionary on its own. I connected three things that already almost fit together: Cezar + a QR code + a private mesh network. Cezar already had a mobile-friendly web cockpit. The missing part was making the route from a remote Cezar instance to my phone stupidly simple. Now I can start Cezar on a remote machine, get a QR code directly in the terminal, scan it with my iPhone and - bang - the cockpit is on my phone. remote machine ↓ Cezar ↓ private mesh ↓ QR in terminal ↓ 📱 The implementation adds an explicit trusted-host mechanism for private fronts and a scannable startup URL. Tailscale is my network of choice, but the design is intentionally not Tailscale-specific. A tailnet, WireGuard mesh or a similar private network can provide the transport. Cezar stays in local mode instead of becoming a publicly exposed authenticated service. My setup uses Tailscale because the Personal plan is currently free and extremely convenient for this kind of private network. There are separate plan limits depending on the kind of resources you use, so read the pricing page before deploying your personal hyperscaler. 😎 The important part for me is the developer experience. No new Cezar account. No new Cezar password. No copying URLs from a terminal into a phone. Scan, open, work. When development is happening in the cloud and agents are distributed across remote machines, that tiny change matters a lot. Thanks, Tailscale. You changed a surprisingly large part of how I work. 🫶🏻 PRs: https://github.com/open-mercato/cezar/pull/1070 https://github.com/open-mercato/cezar/pull/1070 https://github.com/open-mercato/cezar/pull/1071 https://github.com/open-mercato/cezar/pull/1071 I went to Wrocław to test a hypothesis A few days earlier I was at the Open Mercato HackOn in Wrocław. Together with Mateusz Wiatrzyk https://pl.linkedin.com/in/mateusz-wiatrzyk-91637516b , as part of aveCezar, we won the Best Cezar Feature track and came second in People’s Choice. Mateusz published a very good write-up about the whole weekend here: The funny part is that we were developing Cezar using Cezar. That sounds like a marketing sentence. Unfortunately for my skepticism, it actually worked. Afterwards I asked Patryk Lewczuk https://github.com/pat-lewczuk about potentially developing further with the Open Mercato Core Team. The answer was basically no. Which I understand. At the time of writing I have ten PRs for Cezar and only two of them have made it upstream. Apparently winning the Cezar track at a hackathon does not automatically unlock a secret employment contract. I’m 36 and still this naive. 🤡😎 I was devastated for approximately two minutes. Then I went back to my Cezars. Mateusz did too. His 1045 adds Jira and Linear tracker integration, including browsing issues, launching workflows with ticket context and tracker-triggered automations. His 1047 is another substantial piece - a workspace dashboard with activity, reported usage and costs, outcomes, exports and observability. https://github.com/open-mercato/cezar/pull/1045 https://github.com/open-mercato/cezar/pull/1045 https://github.com/open-mercato/cezar/pull/1047 https://github.com/open-mercato/cezar/pull/1047 Autonomous development driven from issue trackers is getting uncomfortably close. And all of this can eventually sit in Cezar on a phone, while the actual work happens somewhere in the cloud. 🤯 My factory is becoming geographically distributed Currently I use four public cloud providers: - https://www.hetzner.com/ https://www.hetzner.com/ - https://upcloud.com/ https://upcloud.com/ - https://www.ovhcloud.com/ https://www.ovhcloud.com/ - https://www.digitalocean.com/ https://www.digitalocean.com/ And I have my own thing in development. It will probably live at: This is absolutely not an announcement, despite the fact that I am announcing its existence in a public blog post. tiny-cloud is still very much WIP. My control plane and scheduler are a mess. Go is new to me. There will be more on that later. 🤓 The idea is simple: I want a tiny control plane for machines running my agent workloads. Right now my agents are already distributed across three continents. Why? I like redundancy. That’s all. 🐳 Then Open Mercato launched a cloud During HackOn, Open Mercato also presented Open Mercato Cloud https://openmercatocloud.com/ . It is essentially a browser-accessible development environment aimed at AI engineering - sandbox infrastructure without requiring the developer to build and operate the infrastructure layer personally. As winners of the Cezar track, Mateusz and I received three months of Sandbox access. Combined with the month available to hackathon participants, that gives us a rather comfortable playground for experiments. We received access to the Developer tier. My first reaction was that the price feels a bit high for an individual developer. Then again, maybe I am not the target developer. 🤣 I already have accounts at four cloud providers and I am writing my own control plane for fun. That is not normal customer behavior. For somebody who wants to build software instead of spending Saturday debugging a scheduler, Open Mercato Sandboxes make much more sense. And I have to give them credit: the product influenced my own architecture. After probing the Sandbox, I changed several assumptions in the control plane and scheduler for tiny-cloud. Dominik Pałatyński, one of the main people behind Sandboxes, also thanked me directly for the auto-scaling governor contribution I built for Cezar during the hackathon: https://blog.cygankiewicz.com/en/cezar-agent-orchestrator/ https://blog.cygankiewicz.com/en/cezar-agent-orchestrator/ That felt good. 🙏🏼☺️ I may write a proper Sandbox review one day. This blog is twelve days old I started this blog on September 13, 2026. Twelve days later, I already have readers in Europe, North America, Asia and South America. 2026 is crazy. Maybe it is just me, but I have never had to update my mental model this quickly. Products change, models change, economics change and my own plans change. The velocity is ridiculous. My previous post, Ethics of Agent Exploitation https://blog.cygankiewicz.com/en/ethics-of-agent-exploitation/ , got surprisingly good feedback. One sentence in particular stayed with Mateusz: “But for a huge class of small software projects, the marginal cost of getting to the first useful version is approaching something that feels very close to zero. And in my opinion, that is awesome.” He told me that this sentence moved him. But there is another side to it. For many developers, programmers and people working broadly in IT, that sentence does not necessarily sound awesome. After another two days of thinking about it, I understand that ambiguity much better. I still think we are heading toward extraordinary abundance I am not a prodigy or a fortune teller. But I do have a working hypothesis. I think we may be heading toward a level of abundance that would have been difficult to imagine even recently. It will not be distributed evenly. It never was. I have plenty of complaints about our corporate-capitalist reality. 🤮 But complaining about the distribution mechanism does not make the technological shift disappear. So what do we do? I started a blog. Yesterday a colleague told me: “I thought blogs were dead.” He is wrong, but there is something important hidden in that observation. For him, blogs are dead because he does not read blogs. For me, they are obviously alive because I love them. There are fascinating individuals all over the world writing on their own little pieces of the internet instead of putting every thought into Instagram, Facebook, LinkedIn or X. And still - blogging is difficult for me. I started writing this post at 04:40 AM CET. At 07:30 AM it was still work in progress. I write these posts in English first, not because English is faster for me. It definitely is not. I do it because I want my English to become better. Not everyone needs to become a blogger. Not everyone needs to become a programmer. Not everyone needs a CS degree. And despite what my current browser history may suggest, not everyone needs to become a full-stack AI architect . 🤪 There will still be an enormous amount of work in services. Probably very strange services. I need a cat concierge Let me give you a deliberately stupid example. I have a cat. 🐈 I love him very much, but I have better things to do than physically taking him to a routine veterinary appointment. So what do I actually want? A cat concierge . A human picks him up, takes him to the vet and sends me a structured report afterwards. AI in the loop. My own AI probably processes that report before the cat arrives back home. Yes, I have something with reports. I cannot help it. Almost everything I do in life eventually becomes data. That job is not “programmer”. It is not “prompt engineer”. It is a service built around trust, physical presence and responsibility, augmented by software that becomes almost free to create. I suspect we are going to see a lot of things like that. So - is Open Mercato AI slop? This is actually why I went to the hackathon. I wanted first-hand experience. Open Mercato talks openly about agentic engineering. The project describes itself as an AI-engineering foundation framework and emphasizes architecture-aware agents, reusable skills and spec-first development. That sounds great in a README. I wanted to see what happens when people actually use it. My answer after HackOn is: No. Open Mercato is not AI slop. And importantly, I do not say this because every piece of code is perfect. It isn’t. Nothing interesting is. I say it because the interesting part of Open Mercato is not “AI generated a lot of code”. The interesting part is the system around generation . Open Mercato itself The main Open Mercato https://github.com/open-mercato/open-mercato framework is an impressive codebase for CRM, ERP and commerce applications. Perfect? No. Finished? Also no. It is WIP, and that is visible. But its architectural bet makes sense to me: if agents are going to generate a significant part of a greenfield system, then architecture, conventions and specifications need to exist before the agent starts inventing them. The project calls this spec-first development and an architecture-aware AI harness. This is almost the opposite of slop. AI slop is: prompt ↓ huge blob of output ↓ ship it 🤡 Agentic engineering should look more like: intent ↓ spec ↓ architecture ↓ agent ↓ isolated implementation ↓ tests ↓ review ↓ human decision ↓ merge That distinction matters. Cezar Cezar https://github.com/open-mercato/cezar is a GOAT. 🐐 I already wrote an entire post about it, so I will spare you another love letter. It runs coding agents in parallel, gives tasks isolated Git worktrees, provides queues, workflows and live visibility, and works locally or on a VPS. For me it has become the execution layer of my little factory. Nothing more to add. 🐐 Open Mercato Skills This is probably the biggest mindfuck for me: https://github.com/open-mercato/skills/ https://github.com/open-mercato/skills/ Before HackOn, I almost never used Skills. I did not really have a place for them in my workflow. I had also seen comments online dismissing skills as something for amateurs, and for a while I bought into that framing. I was wrong. Open Mercato Skills package repeatable engineering procedures as agent-readable instructions: PR creation, code review, CI stabilization, spec writing, integration testing, merge management and more. The only reason I finished my Cezar feature during the hackathon weekend in anything resembling a controlled process was their Skills. That changed my opinion completely. The model matters. The prompt matters. But increasingly the real leverage is: what procedures does the agent already know how to execute reliably? That is much closer to organizational knowledge than prompting. Sandboxes Sandboxes are the third piece. They are probably not optimized for someone like me, because I already enjoy operating infrastructure and, apparently, consider writing a scheduler in Go recreational activity. For businesses, teams and developers who do not want to maintain their own control plane, the proposition is much clearer. It works. That has value. If you are a full-stack person who enjoys doing everything yourself, paying someone else for this may initially look funny. Then you realize that they are selling exactly the part of the stack you should probably stop rebuilding. I am still not sure I am the customer. I am quite sure there are many people who are. So what is Open Mercato actually showing? This is the part I find more interesting than CRM or ERP. Open Mercato is an experiment in what software engineering looks like when agents become normal participants in the development process. Not autocomplete. Not “write me a React component”. Agents receiving specs. Agents following shared skills. Agents working in isolated environments. Agents reviewing other agents. Humans deciding what goes upstream. That is the thesis I came to Wrocław to test. My conclusion is that greenfield software development is moving toward spec-first, agentic engineering . Not every project. Not tomorrow. Not without human judgment. But directionally, yes. And that is not AI slop. Slop is uncontrolled output. This is an attempt to engineer the factory. There is one more thing Since apparently there is no obvious job-shaped slot for me in my country 😎, I decided it is time to create one. I am incorporating. For years I had my head in the clouds about where that should happen. Switzerland? Luxembourg? Malta? UAE? Delaware LLC? I have spent an unreasonable part of my life reading about taxes and international commerce. Strange interests for a kid, I know. I cannot do anything about it. 🤷🏻 But today I have clarity. Gliwice, Poland. A Polish sp. z o.o. . Taxes suck, obviously. But my father used to say something that stayed with me: “If you pay taxes - even high taxes - that is actually awesome. It means you have revenue and profits.” Fair enough. Ventures Originals The company will be AI-native. On August 9 I watched Aula Polska 194: Fireside Chat o Agentach AI | Bartek Pucek & Piotr Nowosielski : https://www.youtube.com/watch?v=w52Q64HXyOU https://www.youtube.com/watch?v=w52Q64HXyOU One framework from that discussion that stuck with me was the distinction between companies that lag on AI adoption, companies that embed AI into existing operations and companies that are genuinely AI-native. I know which one I want to build. The working direction for Ventures Originals https://venturesoriginals.com/ is AI research around: - safety - operations - inference - economics And the first product thesis is increasingly clear. An orchestrator of orchestrators The execution layer already exists. Cezar can be one runtime. Others can exist beside it. The product I am interested in sits one level above them: 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 A control plane for orchestrators. Not another agent UI. Not another wrapper around one model. Policies, routing, scheduling, budgets, SLOs, security, observability and discovery across execution systems. I know that is not easy. That is precisely why I am interested. I am looking for a co-founder I am not in a hurry. The kind of person I would particularly like to hear from is rare: - a technical founder with meaningful exit experience - a former CTO or staff-level engineer from a strong acquired company - somebody unusually deep in distributed systems, AI infrastructure or capital deployment - or, because life should remain interesting, a Bitcoin whale or Solana wizard who actually operates infrastructure rather than only posting charts 😎 The skill overlap I care about most: - distributed systems - effective capital deployment - digital transformation - AI At this stage, what I need first is expertise and approximately 20 minutes of conversation per week . No pitch deck circus. No need to rush. My current incorporation sketch is PLN 100,000 of initial capital. I am considering reserving a 5% founding stake for the right co-founder at a PLN 5,000 contribution, subject to the actual incorporation documents and legal/accounting setup. A Polish individual or company would make the mechanics easiest, but geography is not a hard constraint. If you are in Asia or North America, that is fine too. This is an experiment. If Ventures Originals cannot become profitable within one year of incorporation, I will dissolve it. Simple. See you after a small offline window I will be away from my computer for the next week or two, so I may be slower to respond. I will still keep an eye on my inbox. The factory can survive without me for a while. I hope. 🏭🤖💪🏻