Build a product with a coding agent fleet where only a person merges

Marcin Marzec has written no code for Saphan Studio since 6 July; the agent fleet made over 36,000 commits, each reviewed by other agents and merged only by Marzec.

Done withCustom agent· Nov 1, 2026

What they did

Marcin Marzec runs a fleet of coding agents that builds Saphan Studio and writes up a week of its record in a newsletter. The agent that writes a change never reviews it. Each change goes to a reviewer on a fresh context, and in critical areas two reviewers on models from two different vendors run in parallel without seeing each other's work. Findings are classed as blocking, owed (merge now, debt filed in the same commit) or note. Some tests scan the whole codebase to enforce architecture rules and include planted violations to prove they still catch things. Agents can reject work, but every change waits for Marzec to accept, accept with conditions, reject or close it. The fleet's rules are published on the Saphan site.

How it went

By the author's count, measured on 16 October 2026, the agents made more than 36,000 commits, close to 5,000 in one week, and none was merged by an agent. In that week the two cross-vendor reviewers split on one change and the blocker won; a reviewer showed a $30 spending limit could approve three $14 charges and stopped that change; and codebase checks went red on code from other tracks. A written rule against AI attribution lines failed, with 3,194 commits carrying one, until a repository check began refusing them.

Worth knowing

Marzec does not name the agent products or models. The lesson Marzec draws from the week: an instruction in a prompt is not a control, so enforce rules at the repository boundary. Until that week 98% of commits carried Marzec's name; the fleet now commits under its own Git identity so the history shows who wrote and who approved.

Try it

With Custom agent· 5 parts to fill in

You are one agent in a fleet working on [repository]. Your role is [builder or reviewer]. As builder, implement [ticket] and write a report of what you changed and the tests that failed before and pass after. As reviewer, on a fresh context, review the diff for [area such as security or spending limits], class each finding as BLOCKING, OWED or NOTE, and say plainly what your checks did not prove. Never merge. Stop after your report and wait for [the human owner] to accept, accept with conditions, reject or close the change.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related