A developer's playbook for running four coding agents without chaos

The problem is management

As dev.to reported, one developer has published the system he uses to run four coding agents together: Claude Code, Codex, Antigravity and Hermes. His starting point is that the models are not the main difficulty. Managing them is.

He compares a single unsupervised agent to an eager intern who is fast and confident but sometimes wrong. Put four of them on the same project with no structure and they overwrite one another, repeat each other's work and spend your budget disagreeing. Everything else in his write-up is a response to that.

One lead, several specialists

Only one agent, the orchestrator, ever hears from the human. Its job is not to write the most code. It splits a goal into tasks, decides which worker takes each one, and reviews what comes back. The author calls this being a tech lead rather than a typist.

Each worker gets a single task. One might take an architectural change, another routine boilerplate, a third a quick prototype. Workers do not need the big picture, only instructions they cannot misread.

The author also argues that roles matter more than brand names. A refactorer only simplifies code without changing what it does. A test writer only writes tests and may not repair the code under test. A feature builder works from a spec. Give a cleanup job to a feature builder and it may add a feature along the way, and a bug with it. Because the role is fixed, you can swap the tool filling it when prices or performance shift.

Packets instead of prompts

Loose, open-ended requests are where agents drift, so the author sends structured briefs, which he calls packets. Every packet has the same five parts:

• Goal: one sentence describing what finished looks like.
• Context: only the files, function signatures and limits that matter, not the whole codebase.
• Steps: the order of work he expects.
• Output format: exactly what should come back, such as a diff, tests or a summary.
• Verification: how the work will be checked, stated before the work starts.

His quality test is whether a worker that has never seen the earlier conversation could carry out the brief. When a worker fails, he rewrites the packet rather than asking it to retry. By his account, the brief is usually the culprit, not the model.

Spend on judgment, trust only evidence

On cost, he routes work by how much thinking it needs. Documentation, type updates, boilerplate, first drafts and summaries go to fast, cheap models, since he says a premium model does not do that pattern-matching work better, only at roughly three times the price. The expensive models are kept for the orchestrator, design decisions and difficult debugging. He also tracks spending per task. If a simple refactor costs more than building a feature, something is wrong: an agent looping or a poor brief.

For quality control, he says nothing is accepted because an agent reports it is finished. There are three checks. First, workers must run the tests they wrote and report the real results, failures included. Second, no agent touches the main branch directly. Every change arrives as a diff a person can read. Third, a different model with read-only access reviews the change and looks only for problems, so it does not share the author's blind spots.

The target is output that looks polished and confident but is wrong. In his framing, an agent's report is a claim, while tests and diffs are evidence.

A shared rulebook, and the mess that prompted it

Agents lose memory when a session ends, and one machine does not know what another learned. His fix is a short written project brief that each agent reads at the start of every session. In Claude Code, that file is called CLAUDE.md. His contains the exact build and test commands, the conventions that matter, the boundaries (what is never edited, never logged, and where secrets are kept), and a definition of done. He leaves out the current state of the project, which lives in the code and the task list.

The setup grew out of a failure. He once pointed two agents at one bug with no roles, briefs or reviewer. One changed the code, the other undid it and applied its own fix, and the first put its version back. The code ended up worse and he paid for all the tokens.

This is a personal account, not a test of how well it works. Our own caution is that every extra agent adds output a human must read. Our newsletter flagged a companion dev.to post suggesting the person, not the software, can become the bottleneck, though we have only its title. The author also offers a free starter pack of three CLAUDE.md templates and a one-page checklist on GitHub, and says a fuller paid kit is planned for December.