the series — post 1M. Marzec (“Wato”)
wato.org / blog / seven-mocks-in-ten-days2026-07-06

Seven mocks in ten days — and then one took fourteen minutes

On April 9th, 2026, at 13:40:31, I started building a mock: a PostgreSQL browser with on-the-fly decryption of encrypted PII columns, for testers who needed to see what the system actually stored. At 13:54:50 it was done. Fourteen minutes and nineteen seconds, commit-timestamped, for the eighth mock in the fleet.

The first mock, fifteen days earlier, had taken days of iteration. This post is about what happened in between — and it's the first post in a series about shipping a commercial telco-security product with fleets of coding agents, live at a mobile operator six months after development started. The methodology that grew out of it: the protocol.

The integration surface you can't have on your laptop

We were building a security product that lives inside a mobile operator's network. The team was in Poland. I work from Thailand. The operator's integration environments were where operator integration environments always are: shared, gated, and six time zones from somebody.

The product touched a stack of operator-side systems, so between March 25th and April 3rd — ten days — the first seven mocks came into existence: an SMTP server with STARTTLS and AUTH, a direct-carrier-billing gateway speaking SOAP, a messaging gateway speaking a binary telco protocol over TCP/TLS, a subscriber-activation service, a carrier-identity verifier, the operator's header-enrichment authorization flow with OAuth 2.0, and DNS with DoH. Every one of them is something you cannot run on a laptop and cannot hammer in shared staging without making enemies.

All of them were written with a coding agent. None of them took the same amount of time — and the differences are the interesting part.

The honest cost curve

Git remembers what memory smooths over, so here is the actual curve, from commit timestamps:

That curve is not "agents got smarter" — same models, same person. Something else bent it.

What bent the curve: the extraction

On March 28th — the same day mocks #2 and #3 got their first commits — I stopped and built the platform instead of the next mock. By that evening there existed: a dashboard repo whose first commit already contained Docker fleet control; autowiring that detects sibling mocks and skips missing ones gracefully; a mock-example scaffold — "the new mock service guide" — and a live-events console streaming what every mock receives and returns. That same night, event-reporting middleware was retrofitted into every mock that existed, three commits landing a few seconds apart.

A second extraction wave came a week later: a shared, hardened base image (patched CVEs, healthchecks, non-root user), retrofitted across the fleet — the retrofit commits land in every repo in the same second, because by then fleet-wide chores were scripted. The fleet is maintained as one organism: when a convention changes, one decision becomes an identical commit everywhere, simultaneously.

The conventional wisdom says: rule of three — don't abstract until the third repetition. I extracted the platform layer the day the second and third instances were born, and I'd argue that when agents write the instances, you should. The economics flip. With human hands, the instances are expensive and premature abstraction is a risk. With agents, the instances are cheap either way — the leverage lives entirely in the platform and the conventions, because they are what every future instance inherits. Mock #8's fourteen minutes were purchased on March 28th.

The interface to an agent is a repository it can read

After the extraction, the brief for a new mock was essentially: read the example and the conventions, then build a mock of system X with contract Y. The scaffold demonstrated every convention; the docs were written for a reader that actually reads everything; autowiring meant a conforming mock appeared in the dashboard with zero dashboard work.

That's also why the fleet stopped being mine. In the second half of April, a developer on the team took over evolving it: he realigned two mocks to the operator's specification end-to-end — one of them in five commits that took the mock from my one-sitting skeleton to spec-exact behavior — extended the header-enrichment mock's mobile flow, and made nine commits to the dashboard itself. No planning meeting, no ticket asking me for platform support. The way I learned about some of it was messages on the project channel, after the fact.

A pattern is something you apply. A platform is something other people extend without asking you. The moment that happens, the marginal cost of the next instance has hit zero in the currency that actually matters: founder attention.

The dashboard was for the humans

One more thing bent the six-month timeline, and it wasn't code that shipped to production. Distributed teams die from waiting on each other: can you send me the code from the test phone across six time zones is a lost day; can someone with database access check what's actually stored is a lost day; it works on my machine without shared visibility into a failing connector is a lost day.

The dashboard removed whole classes of those waits. Testers could see, on their own, at any hour: the one-time PINs "sent" by the mocked messaging systems (surfaced in the dashboard precisely because they're never sent to a real phone), a readable view of data that sits encrypted in database columns, and live logs of every connector — the exact seam where "your bug" and "my bug" usually get argued about. Mock and staging data, in our own data center, to be clear — nobody was browsing decrypted production data in a web panel.

None of that is glamorous. All of it is why a team spread across a continent and a half could move without meetings.

Ten weeks later, a different product

In mid-June — seventy-one days after the base extraction — I needed a mock again, for a different product, integrating a payment aggregator in a different country, with the extra twist that the thing to mock included a browser-side JavaScript library, not just a backend. The entire working mock — JS library behavior, PIN verification, dashboard tab — landed as a single commit, built in one sitting on top of the same base.

That mock, and the thirty-minutes-a-day test window it existed to escape, is the next post.

What git corrected about my memory

This series has a rule: every number must survive hostile checking, so before writing this I had an agent sweep the repositories, read-only, and report where the commit record contradicts my recollection. It found three things. I remembered the gap between the extraction and that last mock as four months; git says seventy-one days. I remembered a teammate building one of the original mocks solo; git says I built it and he did something better — he took over the fleet's evolution. And I remembered the fleet as seven mocks; it's ten today. My memory consistently made the story smaller and slower than the record.

That habit — treating recollection as a claim that needs an artifact — is rule zero of the methodology this series is about. The rest of it — roles, hard gates, dispatch rules, proof-over-claims — is in the protocol.

Marcin "Wato" Marzec has built internet infrastructure and security since 1997 — from a dial-up-era ISP through enterprise identity at Microsoft and CA Technologies, to founding SafeKiddo. He ships carrier-grade telco security with fleets of coding agents, from Thailand. More: wato.org · the protocol · Saphan Studio, the product this method became.