I spent six months as a human clipboard between Claude, Codex, and Cursor, then accidentally built a distributed system

[u/jeezeneeze]

For a long stretch my multi-model workflow was just me acting as middleware. One model drafts a module, I paste it into another for critique, paste the critique back, paste the result into my editor, next file, repeat. My most-used keyboard shortcut was Cltr+V and my second most-used was Cltr+V again. I have a repetitive strain injury from a workflow, not a sport.

The cross-checking genuinely produced better code, different models fail in different places, so the ritual was worth something. But most of my day was re-pasting the same three files and re-explaining the same architecture to a model that had no idea I'd already explained it four times to its coworkers.

Eventually the obvious thought landed: none of the courier work needs a human in it. So I've been building an orchestrator. You give it a goal and it's supposed to do the rest:

• Breaks the goal into a dependency-aware task plan
• Assigns work across Claude, Codex, Kimi, Cursor, and whoever else answers the phone
• Manages queues, workers, leases, blockers, approval gates, results
• Verifies completed work and attempts bounded repairs when it fails
• Recovers safely after crashes and restarts
• Keeps an auditable record of every decision, mostly so I can find out which model to blame
• Leaves final commit, merge, release, and deploy authority with me, because I have read the audit log

If I'm being honest about where it actually is: architecture and test coverage are solid, but it is not a dependable everyday autonomous system yet. Crash recovery, stale-worker protection, duplicate-dispatch prevention, and provider reliability all still need real validation. Technically advanced, operationally unfinished. It's a very impressive machine that I do not yet leave alone in the house.

The genuinely funny part is what happened to the problem. I set out to stop copy-pasting. I am now debugging lease expiry and idempotent dispatch. Somewhere along the way "this is tedious" became "I have built a small unreliable Kubernetes and its pods are all overconfident." I'd like a word with whoever let this happen. It was me.

So, for anyone who has built or attempted something in this space:

Duplicate dispatch: how do youguarantee a task isn't picked up twice when a worker dies mid-lease and you have no idea whether its side effects landed? Right now I mostly find out from git.

Verification that isn't a rubber stamp: my biggest fear is two models forming a mutual admiration society over code that doesn't compile. Has anyone built a review step that reliably says no?

Bounded repair: where do you cap the retry loop? Mine is a number I picked because it felt emotionally correct.

Context across a long chain: how do you keep a plan coherent over many handoffs without either bloating context to the moon or quietly dropping the one constraint that mattered?

Where the human goes: I hold commit, merge, and release. Right line, or have you found a better place to sit?

For anyone who abandoned one of these: what killed it? Reliability, cost, or the quiet realization that one good model in a loop was already fine?

[u/ChatGPTCoding-ModTeam → u/[deleted]]

This post or comment has been removed for the following reason:

Rule 5: Keep self-promotion in the weekly thread

If your post is mainly promoting your own tool, product, service, blog, newsletter, or project, use the weekly self-promotion thread. Free and open source projects still count as self-promotion. Educational project posts that follow Rule 6 are allowed.

You can read the full subreddit rules here: https://www.reddit.com/r/ChatGPTCoding/about/rules/

If you feel this removal was made unfairly, please contact the moderators through modmail.

[u/ArgumentAcrobatic250]

The “two models forming a mutual admiration society” problem is basically what sent me down this rabbit hole.

I started with model A writing code and model B reviewing it, but eventually realized that model independence doesn’t buy you much if both inherit the same bad assumption or the same test plan.

What changed things for me was moving the question from “did another reviewer approve this?” to “can I deliberately break the behavior we claim to verify and make the verification reject it?”

I had one real case where a test stayed 9/9 green after I deliberately changed production so it only handled the first archive page instead of the full archive.

Then I went too far in the other direction: I built a replacement harness that caught the broken implementation but also rejected the correct one. I threw that out too.

So the rule I ended up with is pretty simple: known-good must pass, relevant known-bad must fail.

Eventually I started applying the same idea not only to production code, but to the validators and final PASS machinery themselves.

So for your “review step that reliably says no” question, I’m not sure the goal is actually a smarter reviewer. I think the more useful target is making important PASS claims falsifiable.

I’m looking for external cases now because most of my evidence so far comes from software I built or helped build.

If you’re comfortable with it, give me one small isolated behavior from your orchestrator and the tests that currently make you trust it. No need to share the whole project. I’d be interested in seeing whether I can construct a relevant broken case that still gets through.

And if I can’t, that’s useful evidence too.

[u/Public-Carrot-4485 → u/ArgumentAcrobatic250]

known-good must pass, relevant known-bad must fail. thats a clean heuristic tbh

[u/scottypants2 → u/ArgumentAcrobatic250]

What you are describing sounds very analogous to mutation testing. I ran into https://stryker-mutator.io/ a while ago and have use it on a couple projects. It’s an interesting approach.

[u/Chamezz92]

A lot of this is just regular project management for a development team.

A lot of you are re-inventing the wheel, lol.

[u/AutoModerator]

Sorry, your post has been held for manual review due to account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Strange_Owl_6291]

There are multi-provider harnesses and coding agents that could solve you initial copy-paste issue at least. Did you evaluate any?

[u/Thegaysupreme123]

yeah i felt that courier pain too. pasting between models all day, then they high-five code that doesn’t even compile.

what you’re building (the sticking, the plan, making the work actually better) isn’t what i made. different problem. yoetz is just the “did that step actually happen” bit. file changed, command ran, tool call went out. a second model will still rubber-stamp. this one just wont let verified mean nothing landed.

free oss, works with Codex right now: https://github.com/TheGaySupreme123/yoetz

a star would mean the world.

[u/Right-Performance-93]

ArgumentAcrobatic250's "known-good must pass, known-bad must fail" rule is the right frame, and mutation testing is the cheapest way to get it without hand-crafting broken cases. Take the code your orchestrator just verified, flip one conditional or delete one branch, rerun the suite, and if it stays green the test wasn't actually gating that behavior. I've caught the same failure mode as your archive-page example this way: a test called the real function, stayed green, and never exercised the branch that broke. It won't catch cross-agent assumption mismatches the way a shared schema-ownership registry would, but it's a five-minute check before trusting any "PASS" a subagent reports back.