Running many coding agents moves the bottleneck from typing code to deciding what should exist and confirming that it does. An agentic engineer spends the day writing specs, building gates that check work automatically, and reviewing diffs, and the number of agents that pays off is set by how fast those three things go.
Each agent creates work for you twice, once when you write its spec and again when you review what it produced. Add agents and that demand grows linearly while your hours stay fixed. Past the crossover, extra agents only lengthen the review queue. Move the sliders to find where your crossover sits.
Model assumptions, shown so you can disagree with them: a feature builder finishes about 3 runs in a working day, a chore agent about 6, an investigator about 3. A feature spec takes 15 minutes, a chore spec 3, an investigation prompt 5. Chores take 3 minutes to review and merge at your feature rate plus 25 points (capped at 95%). Notes take 8 minutes to read. An abandoned feature costs a quick 5-minute look plus a 10-minute re-spec. When demand passes your hours, everything scales down in proportion. The numbers are illustrative; the shape of the curve is the point.
herdr is one layer. It keeps sessions alive and tells you which agent needs you. The other layers decide what agents work on, where their files live, what they're allowed to touch, and how you know they finished correctly. Tap a layer for what it does and what breaks without it.
Tool facts checked October 2026. This category churns quickly; Crystal was deprecated and Bloop shut down earlier this year, so weigh who maintains a tool before building a workflow on it.
Thirty panes is never thirty agents writing features. Work splits into archetypes that differ in how expensive their output is to verify, and that cost decides how many of each you can run. The cards list typical pane counts in a full board and the loop each one follows.
Lower-left work is cheap to check and scales out. Feature builders sit high because a feature diff needs real reading. Reviewers and investigators produce text, so their cost is reading time, and nothing has to be merged.
Pick a day type. Each square is one herdr pane. Pale squares are the dev server or test watcher paired with a builder. The load figure is how much of your focused time the board demands, using the same assumptions as the ceiling model.
The rhythm alternates between short sweeps of the attention queue and longer blocks in the planning pane. You almost never type code and rarely read agent transcripts. Agents keep running between your blocks, and long-runners carry work through the night.
Your lane shows what you're doing. Agent lanes show when each archetype is running. Gaps in an agent lane mean it's waiting on you, which is the cost the sweeps keep small.
A spec is half a page that tells an agent what done means without telling it how to get there. Agents drift on vague goals far more than on hard code, so this is where your judgment does the most work.
The checker on the right reads this box live. Paste your own spec to grade it. The rules are simple text heuristics, so treat a pass as necessary rather than sufficient.
Each bullet should map to a test or a one-minute manual check. "Fast" can't be checked; "streams over 10k rows" can. Three to seven bullets is typical for a feature.
They stop the agent from improving code next door while it's there. Missing non-goals cause most scope drift. Write one every time you think "it could also".
File paths and "reuse this helper" save exploration and prevent reinvention. Point, don't explain; the agent can read code faster than you can describe it.
One command that exits zero when the work is acceptable. It goes in the Stop hook, and it's what turns "done" in the sidebar into a fact.
If you're writing step 1, step 2, the task is either small enough to do yourself or should be split into several specs.
A spec should produce a diff you can review in one sitting. Large work becomes several specs, ordered so each lands green.
| Archetype | Length | Must contain | Example |
|---|---|---|---|
| Chore | 3 to 5 lines | Target, non-goal, done command | Bump zod to v4. Fix type errors. No refactors. Done when tests and typecheck pass. |
| Investigation | A question and an output path | Question, evidence standard, "no code changes" | Why does /search take over 2 s on cold start? Findings with evidence to notes/search-latency.md. |
| Feature | Half a page | Goal, criteria, non-goals, context, done command | The template above. |
| Long-runner | Feature template plus commit rules | Small commits, tests green at every commit, stop conditions | Migrate each module to the new logger, one commit per module, stop after 3 consecutive failures. |
| Review | Two lines | The spec and the diff, nothing else | Check this diff against this spec. List violations, risks, and unasked changes. |
Reader: people who need to agree.
Settles: which approach, and why over the alternatives.
Contains: problem, options, trade-offs, risks, open questions.
Precision: architecture level is enough.
Lifecycle: reviewed, approved, kept as a record.
Failure: a meeting with no decision.
Reader: an agent that will execute it.
Settles: what done looks like, and the fence around it.
Contains: criteria, non-goals, pointers, done command.
Precision: checkable by a test.
Lifecycle: run, refined, rerun, dead once merged.
Failure: confident, working code for the wrong thing.
The two stack. When the approach is genuinely open or other teams own parts of the system, write the one-pager, get it reviewed, and derive specs from its chosen option. One design doc usually fans out into several specs. Agents change the doc too: investigators can gather evidence for each option, and two prototypes can run in parallel, so review argues from results.
No single check catches everything, and the expensive one is you. Stack cheap automatic gates first so your review time goes to the failures only a person can see: the wrong thing built, or a design that drifts from how the system should work.
Scale: blank means it rarely catches this class, 3 means it reliably does. Ratings are judgment. The right two columns are the only ones that read intent, which is why the reviewer agent earns its pane: it filters unasked changes and spec violations before they reach you.
| Symptom | Likely cause | Fix |
|---|---|---|
| Agent built something plausible but wrong | Ambiguous acceptance criteria | Abandon. Rewrite criteria as checkable statements and relaunch. |
| Diff touches files you didn't ask about | No non-goals, or a broad goal | Add explicit non-goals. Have the reviewer list unasked changes. |
| Agent spends 20 minutes exploring before writing | Thin context | Add file pointers and "reuse X". Add the repeated discovery to CLAUDE.md. |
| Finished diffs wait hours for you | More builders than your review rate supports | Cut builders, move capacity to chores and investigators. |
| Frequent merge conflicts | Tasks split by feature across shared files | Split by file or module ownership. Merge oldest first. |
| Agents stuck on permission prompts | No sandbox, so approvals stay manual | Run inside a sandbox (Fence, a VM, a Sprite) and allow broad permissions there. |
| "Done" in the sidebar but the build is red | Gates live in your head, not in the hook | Put the done command in the Stop hook. |
| Tests pass but were edited to pass | Gate gaming | Protect test files. Reviewer flags any test change outside the spec. |
| herdr shows an agent working forever | State detection relies on process and output patterns, which can lag agent updates | Look at the pane. Install herdr's integration for that agent for authoritative state. |
| You keep correcting the same thing | The fix lives in your head | Turn it into a CLAUDE.md line, a lint rule, a hook, or a skill. |
| Long-runner made 40 commits, half broken | No per-commit gate or stop condition | Require tests green per commit. Stop after N consecutive failures. |
| You're reading transcripts all day | Specs or gates too loose to trust output | Tighten both until the diff alone tells you enough. |
People who open thirty panes on day one end up with thirty half-finished diffs. Each stage below has a pass condition. Move up when you meet it for a full week, and drop back a stage if the review queue starts growing.
A single Claude Code session per task. Write a spec every time, even for small work. Wire the done command into the Stop hook.
PassTen specs in a row merge on the first or second run.
herdr plus jj workspaces (or ai-workspace to do both in one command). Two builders on unrelated modules.
PassZero merge conflicts for a week, and no diff waits more than 2 hours.
Chores and investigators alongside the builders. Keep an inbox. Sandbox the chore agents so they run without prompts.
PassFive or more chores merged per day at under 3 minutes of review each.
A reviewer agent on every feature diff. Notifications off, sweeps every 20 to 40 minutes.
PassReviewer catches something you'd have missed at least weekly, and your abandon rate is under 30%.
Long-runners with commit rules. Optionally a lead agent that dispatches workers through herdr's API (herdr-walkietalkie, herdr-symphony).
PassMorning review of overnight work takes under 30 minutes and most of it merges.
In order. The first sets a baseline you'll compare against. Ticks are saved in this browser.
Ten skills. Tap the level that matches what you actually do, judged from last week's work. The overall tier can't exceed your weakest skill by more than one level, because the weak link sets throughput.
| Level | In one line | Typical week |
|---|---|---|
| Novice | Uses agents like a fast pair programmer and watches them work. | One or two sessions, lots of mid-run steering, review by reading transcripts. |
| Intermediate | Runs several isolated agents from specs, with automatic gates. | Three to six agents, a spec per task, merges by diff, occasional conflicts and abandons. |
| Expert | Designs the work so it can be verified cheaply, and runs as many agents as review allows. | Ten or more agents across archetypes, short sweeps, long planning blocks, overnight runs that merge. |
Benchmarks are judgment calls. Rate from evidence you can point to, such as your merge log, abandon count and review times, rather than how a skill feels.