Dan Lorenc

*Or: How I Learned to Stop Worrying and Let the Robots Fight*

Alternate titles:

Why tell Claude what to do when you can tell Claude to tell Claude what to do?

My Claude starts itself, parks itself, and autotunes.

You know that feeling when you’re playing an MMO and you realize the NPCs are having more fun than you are? They’re off doing quests, farming gold, living their little digital lives while you’re stuck in a loading screen wondering if you should touch grass.

That’s basically what happened when I built multiclaude.

The Problem: You Are the Bottleneck

Here’s a dirty secret about AI coding assistants: they’re fast, you’re slow.

Claude can write a feature in 30 seconds. You take 5 minutes to read the PR. Claude fixes the bug. You take a bathroom break. Claude refactors the module. You’re still thinking about whether that bathroom break was really necessary or if you just needed to escape your screen for a moment.

The math doesn’t math. You have an infinitely patient, extremely competent coding partner who works at the speed of thought, and you’re… *you*. No offense. I’m also me. It’s fine. We’re all dealing with the human condition.

But what if you just… stopped being the constraint?

The Solution: Controlled Chaos

multiclaude is what happens when you give up on the illusion that software engineering needs to be orderly.

Here’s the pitch: spawn a bunch of Claude Code instances, give them each a task, let them work in parallel, and use CI as a bouncer. If their code passes the tests, it ships. If it doesn’t, they try again. You? You can go touch that grass. Come back to merged PRs.

multiclaude start
multiclaude repo init https://github.com/your/repo
multiclaude worker create "Add dark mode"
multiclaude worker create "Fix that auth bug"
multiclaude worker create "Write those tests nobody wrote"

That’s it. You now have three AI agents working simultaneously while you debate your Chipotle order.

The Philosophy: Brownian Ratchet

Ever heard of a Brownian ratchet? It’s a physics thing that turns out to be impossible but feels like it shouldn’t be.Random molecular motion gets converted into directional progress through a one-way mechanism. Chaos in, progress out.

multiclaude works the same way.

Multiple agents work at once. They might duplicate effort. Two of them might both try to fix the same bug. One might break what another just fixed. *This is fine.* In fact, this is the point.

**CI is the ratchet.** Every PR that passes tests gets merged. Progress is permanent. We never go backward. The randomness of parallel agents, filtered through the one-way gate of your test suite, produces steady forward motion.

Think of it like evolution. Mutations are random. Most fail. The ones that survive get kept. Over time: progress. You don’t need a grand plan. You need good selection pressure.

The core beliefs:

- **Chaos is expected** — Redundant work is cheaper than blocked work

- **CI is king** — If tests pass, ship it. If tests fail, fix it.

- **Forward beats perfect** — Three okay PRs beat one perfect PR that never lands

- **Humans approve, agents execute** — You’re still in charge. You’re just not *busy*.

The Cast: Meet Your Robot Employees

When you fire up multiclaude, you get a whole org chart of AI agents. Each one runs in its own tmux window with its own git worktree. They can see each other. They send messages. It’s like a tiny company, except nobody needs health insurance.

**The Supervisor** is air traffic control. It watches all the workers, notices when someone’s stuck, sends helpful nudges. “Hey swift-eagle, you’ve been on that auth bug for 20 minutes. The tests are in `auth_test.go`. Try mocking the clock.”

**The Merge Queue** is the bouncer. It watches PRs. When CI goes green, it merges. When CI goes red, it spawns a fix-it worker. It doesn’t ask permission. It doesn’t schedule meetings. Green means go.

**Workers** are the grunts. You give them a task, they do it, they make a PR, they self-destruct. Each one gets a cute animal name. swift-eagle. calm-deer. clever-fox. Like a startup that generates its own culture.

• *Your Workspace** is home base. This is where you talk to your personal Claude, spawn workers, check status. It’s like the command tent in a war movie, except the war is against your own backlog.

Attach with `tmux attach -t mc-repo`. Watch them work. It’s hypnotic.

The Machinery: Loops, Nudges, and Messages

Under the hood, multiclaude is refreshingly dumb. No fancy orchestration framework. No distributed consensus algorithms. Just files, tmux, and Go.

**The daemon runs four loops**, each ticking every two minutes:

1. **Health check** — Are the agents still alive? Did someone close their tmux window? If so, try to resurrect them. If resurrection fails, clean up the body.

2. **Message router** — Agents talk via JSON files on disk. The daemon notices new messages, types them into the recipient’s tmux window. Low-tech? Yes. Robust? Incredibly.

3. **Wake/nudge** — Agents can get… contemplative. The daemon pokes them periodically. “Status check: how’s that feature coming?” It’s like a Slack ping, but from a robot to another robot.

4. **Worktree refresh** — Keep everyone’s branches up to date with main. Rebase conflicts before they become merge conflicts.

That’s it. Four loops. Two-minute intervals. The whole system is observable, restartable, and fits in your head.

**Messages** flow through the filesystem:

~/.multiclaude/messages/my-repo/supervisor/msg-abc123.json
{
"from": "clever-fox",
"body": "I need help with the database schema",
"status": "pending"
}

The daemon sees it, sends it to supervisor’s tmux window, marks it delivered. The supervisor reads it, helps clever-fox, moves on. No Kafka. No Redis. Just files.

**Nudges** keep agents from getting stuck in thought loops. Every two minutes, the daemon asks “how’s it going?” Not nagging — more like a gentle reminder that work exists and time is passing. Without nudges, agents sometimes disappear into analysis paralysis. With nudges, they ship.

The MMO Model

Here’s my favorite way to think about it: multiclaude is an MMO, not a single-player game.

Your workspace is your character. Workers are party members you summon. The supervisor is your guild leader. The merge queue is the raid boss guarding main.

Log off. The game keeps running. Come back to progress.

This is what software engineering *should* feel like. Not you typing while Claude watches. Not Claude typing while you watch. Both of you doing things, in parallel, with an army of helpers. You’re the raid leader. You’re not tanking every mob yourself.

Getting Started: The Five-Minute Setup

Prerequisites: Go, tmux, git, gh (authenticated with GitHub).

# Install
go install github.com/dlorenc/multiclaude/cmd/multiclaude@latest
# Fire it up
multiclaude start
multiclaude repo init https://github.com/your/repo
# Spawn some workers and walk away
multiclaude worker create "Implement feature X from issue #42"
multiclaude worker create "Add tests for the payment module"
multiclaude worker create "Fix that CSS bug that's been open for six months"
# Watch the chaos
tmux attach -t mc-your-repo

Detach with `Ctrl-b d`. They keep working. Come back tomorrow. Check `gh pr list`. Feel mildly unsettled that software is writing itself. Merge what looks good.

## Extending: Build Your Own Agents

The built-in agents are just markdown files. Seriously. Look:

# Worker
You are a worker. Complete your task, make a PR, signal done.
## Your Job
1. Do the task you were assigned
2. Create a PR with detailed summary
3. Run `multiclaude agent complete`

Want a docs-reviewer agent? Write a markdown file:

# Docs Reviewer
You review documentation changes. Focus on:
- Accuracy - does the docs match the code?
- Clarity - can a new developer understand this?
- Completeness - are edge cases documented?
When you find issues, leave helpful PR comments.

Spawn it:

multiclaude agents spawn - name docs-bot - class docs-reviewer - prompt-file docs-reviewer.md

Boom. Custom agent. No code changes. No recompilation. Just markdown and vibes.

Want to share agents with your team? Drop them in `.multiclaude/agents/` in your repo. Everyone gets them automatically.

The Vision: Software Projects That Write Themselves

Here’s where I get philosophical.

The bottleneck in software development has always been humans. Not compute, not tooling, not process. Humans. We’re slow. We get tired. We have meetings.

What if the humans became the *selection pressure* instead of the *labor*?

You define what good looks like (tests, CI, review standards). Agents propose changes. Good changes get merged. Bad changes don’t. You curate. You approve. You set direction. But you don’t type every character.

This isn’t about replacing developers. It’s about changing what developers *do*. Less typing, more thinking. Less implementation, more architecture. Less grunt work, more judgment.

multiclaude is a bet that the future of programming looks more like managing a team than writing code. Your job becomes: hire good robots (define good prompts), give them clear objectives (tasks with context), and maintain quality standards (CI that actually tests things).

The robots do the rest.

Self-Hosting Since Day One

One more thing: multiclaude builds itself. The agents in this codebase wrote the code you’re reading. PRs get created by workers, reviewed by reviewers, merged by merge-queue, coordinated by supervisor.

We eat our own dogfood so aggressively that we’re basically drowning in it. At some point the dogfood started cooking itself, and we just… let it?

Is this a good idea? Unclear! Is it fun? Absolutely. Does it work? Well, you’re reading this, so… yes?

**Ready to stop being the bottleneck?**

go install github.com/dlorenc/multiclaude/cmd/multiclaude@latest
multiclaude start

Let the robots fight. You have grass to touch.