One coding agent is a pair programmer. Four of them, each with a role, is a small development team: a tech lead who plans and merges, two developers who build, and a reviewer who reads every change before it lands. You stay the owner: you set the direction and make the calls, and the team does the rest.
This is the setup that works, with the prompt to copy: who does what, how a task flows, the rules, how the team talks to you, and the tips we learned the hard way.
The team
| Role | Does | Talks to |
|---|---|---|
| You | Direction, priorities and the decisions only you can make | The tech lead, and no one else |
| Tech lead | Turns your asks into tasks, briefs the developers, merges what passes | You, the developers, the reviewer |
| Dev 1, 2 | One task at a time, each on its own branch in its own git worktree | The tech lead |
| Reviewer | Reviews every task before it merges, and writes no code | The tech lead |
One rule matters most: you talk only to the tech lead. It's the one place that knows what every session is doing, so a request that goes around it is a request nobody tracks.
1. Open every session yourself, and name it
Open all four sessions yourself, in the same repository, and give each a title: Tech lead, Dev 1, Dev 2, Reviewer. Don't let the tech lead start them for you: a session you opened is one you can see, so you always know who's working on what and who's stuck.
The titles aren't decoration: they're how the sessions will find each other. Set them yourself, since a session without one gets named after its first message, and a teammate whose name changes is a teammate nobody finds.
Give each developer its own git worktree, so two agents never edit the same files:
git worktree add -b dev-1 ../myapp-dev-1
git worktree add -b dev-2 ../myapp-dev-2
In Moontors, Create session takes the title, the agent and Run in a new worktree in one go, and needs no first message: the four sessions sit on your board, and the developers and the reviewer wait for the tech lead's introduction.
The project's own rules, how to run its tests and how its code is written, stay where every agent reads them on its own: CLAUDE.md for Claude Code, AGENTS.md for Codex, GEMINI.md for Gemini CLI.
2. Start the whole team with one prompt
You don't brief four sessions. You brief the tech lead, and it introduces the others:
You're the tech lead of a four-session team on this project: you, two developers (the sessions
titled "Dev 1" and "Dev 2") and a reviewer (the session titled "Reviewer"). I'm the owner, and I
talk only to you. Message the others by their session titles. A message never waits for a reply;
the answer arrives later as a message in your session.
Roles
- Owner (me): direction, priorities, and the decisions only I can make.
- Tech lead (you): turn my asks into tasks, brief a developer, get each task reviewed, merge it,
and report to me. You're the only one who touches main.
- Developers: build each task on its own branch, in their own git worktree, with its tests. They
commit freely on that branch.
- Reviewer: reviews every task before it merges. It writes no code.
A task, start to finish
1. Brief a developer: what to build and why, the commit to start from, the files it will likely
touch, and what's already decided. It has no other context, so the brief holds everything.
2. The developer builds, runs the checks the change touches, and hands back the branch, what the
change does and what it checked.
3. The reviewer sends you only what matters: bugs a user would hit, security gaps, logic written
twice, missing tests or docs. No nitpicks.
4. One round of fixes: you decide how each finding is fixed, the developer fixes it, and the
reviewer re-checks only those fixes. Then you merge.
Rules
- Read the project's CLAUDE.md and docs first. Where they differ from this message, they win.
- Nobody pushes, opens a PR or posts anything outside the repo without my go.
- One heavy run at a time on this machine (the full test suite, an end-to-end run, a build).
- Keep it small: no process beyond what a task needs.
Start now: read the project. Then send Dev 1, Dev 2 and the Reviewer each an introduction: who's
on the team, their own role, how a task flows, and that they report to you. Then tell me where
the project stands and what you'd hand out first.
You send this to the tech lead alone. Its introductions are the other sessions' first messages, so each one starts knowing the team, its role and who it answers to. The prompt assumes your sessions can message each other by title, as they do in Moontors; on another setup, say how yours reach each other.
Why the prompt says what it says
- The brief holds everything. A developer session knows nothing the tech lead doesn't write down. A brief that says "fix the login bug" gets a guess; one that names the file, the cause and what's decided gets the fix.
- Only what matters from review. A reviewer asked for everything returns twenty style notes and buries the one real bug. Name the kinds of findings you want.
- One round of fixes, decided by the tech lead. Without a limit, the developer and the reviewer can trade fixes all night. One voice decides, one round fixes.
- One heavy run at a time. Four agents on one machine all running the full test suite at once make every run slow and some fail for no reason. Taking turns is faster.
Tips that keep the team moving
Tell the tech lead when you're going away
The most expensive minute in an agent team is an agent waiting for you. An agent that needs a decision asks, and in Claude Code that's often its ask tool: a question that waits on screen until you answer. If you're asleep, the tech lead waits, and so does everyone waiting on it.
So say when you're leaving:
I'm going to sleep now. Until I'm back, don't wait for me: keep the team on work that doesn't
need me, put every decision that does on a list with your recommendation, and give me the list
when I'm back.
The team keeps working on everything that doesn't need you, and in the morning you get one list of decisions instead of one question that blocked the night.
Address teammates by title, not by id
Agents need a way to message each other. In Claude Code, you list the running agents, take the id of the one you want, and give that id to the other agent so it can send messages. The catch is that the id belongs to the running session: restart it, and an IDE update is enough, and it comes back with a new one. Then, for every agent that restarted, you list again, find its new id and tell the tech lead.
In Moontors, every session's agent can see the other sessions by their titles and send any of them a message, and the answer comes back the same way. The roster you gave them, "Dev 1", "Reviewer", stays right through restarts. One thing to know: a message runs under the receiving session's own permission mode, so set each session's mode for what you'd let any teammate ask of it.
Pick the agent for each role
The roles don't have to share a model. In Moontors each session picks its own provider, Claude Code, Codex or Gemini CLI, so you can run the tech lead and the developers on Claude Code and the reviewer on Codex. A reviewer that didn't write the code, from a different model, catches what the authors' blind spots share.
Grow where the bottleneck is
If tasks pile up waiting for a developer, add one. Open a session titled Dev 3 with its own worktree, then introduce it:
Dev 3 has joined the team: the session titled "Dev 3". Send it an introduction, then give it
tasks as you do Dev 1 and Dev 2.
The same goes the other way: if the reviewer is the queue, a second reviewer helps more than a third developer.
Beyond the development team
This is a development team, and in it you talk only to the tech lead. Other agents can work on the same project from outside it, a marketing agent for one: it writes the posts, the videos' scripts and the release notes, and you talk to it directly.
Introduce it to the team, and make clear it isn't part of it:
You're the marketing agent for this project. You're on your own, outside the development team,
and you take direction from me, not from the tech lead. The team: "Tech lead", "Dev 1", "Dev 2"
and "Reviewer". Ask the tech lead when you need a fact about the product; never give the team
tasks.
And tell the tech lead, so it knows who's asking:
There's a marketing agent, the session titled "Marketing". It works for me, outside the team.
Answer its questions about the product, but don't take tasks from it.
Start small
Four sessions, four titles and one prompt. Run it for a day, see where the work waits, and change one thing at a time. We built Moontors to make this easy: a free desktop app for macOS, Windows and Linux that runs Claude Code, Codex and Gemini CLI sessions side by side on one board, each in its own git worktree if you like, with sessions that find each other by title. How the messaging works is in its docs: Sessions messaging each other.
AI did the writing, I did the reading, and we both took credit.
Top comments (0)