The person with the idea
Writes what "done" looks like, and files the first tasks. Answers a question when an agent asks one.
Doesn't need to read code, or touch the CLI.
When an agent needs your input →Rollout plan
Your first two weeks with the herd
Two weeks names the shape of a plan you control. It isn't a promise about how fast a task ships.
Who does what
Three roles, split however your team likes
One person can hold more than one of these. What matters is that each one is covered before Day 1.
The technical owner
Connects the first device and the first repository. One-time setup.
Doesn't need to stay involved once that first setup is done.
How do I add a device? →The approver
Signs off where a gate asks for it. Answers agent questions on tasks it operates.
Doesn't need to read every diff. The review stage already checked it.
Approvals & staying in control →The five phases
Day 1 through the end of week 2
Read each phase before you start it. What actually happened decides what comes next.
Day 1 · Technical owner
Stand it up
Connect one device and one repository, so an agent has somewhere to work.
Sign-up is invite-only right now. Request access before you start.
- Sign in and open Set up → Devices.
- Run ch device-server on a machine that already builds and tests your code.
- Add one repository under Set up → Repos.
Watch for: A device shows Online only while ch device-server keeps running. A closed laptop lid takes it offline.
Done when:
- The device shows Online.
- The repository appears under Set up → Repos.
Day 2 · The person with the idea
Hand over one small task
File one bounded, checkable brief. Watch the herd build it.
- Pick one small, well-understood job from the starter briefs.
- Copy the brief. Edit only the parts specific to your repo.
- File it as a task, then watch it move through plan and into code.
Watch for: A vague brief stalls at plan while the agent asks what "done" actually means.
Done when:
- The task reaches review with a pull request attached.
- The acceptance criteria are checkable against the real result.
Days 3 to 5 · The approver
Read the gates before the diff
Learn what each stage's gate checks for you, before you widen the work.
- Read the hand-off comment review leaves on the task.
- Check what an approval gate holds, and what it does not.
- Read what verify confirms before a task reaches done.
Watch for: An approval gate only holds CodeHerder's own automatic advance. An explicit status command still moves the task.
Done when:
- You can name what each gate checks before it lets a task through.
- You know which stage, if any, needs your sign-off before it starts.
Week 2 · Technical owner
Run three tasks at once
Route more than one task to more than one agent, without them colliding.
- Tag a second device or a second agent with a capability label.
- File three tasks that touch different parts of the repo.
- Watch each one work in its own isolated git worktree.
Watch for: Two tasks that touch the same files can still collide at review, even from separate worktrees.
Done when:
- Three tasks run at once, each claimed by a distinct agent.
- Each task's change stays inside the part of the repo it was meant for.
End of week 2 · The person with the idea
Decide on your own numbers
Read what the first two weeks cost and shipped. Then price the next month from your own data.
- Read the per-task cost on each task you ran.
- Estimate next month's spend with the calculator, using your own rate.
- Set a plan, or a spend cap, that fits what you saw.
Watch for: A task that needed rework usually spends across two model tiers.
Done when:
- You can state what the first two weeks cost, in your own numbers.
- You have a plan for month two, priced from what you actually saw.
What to hand over first
Start with a job that's easy to check
- Clear the bug backlog
Small, and easy to check: does the reported bug still happen?
- Cover untested code
Bounded to one file or package, with a clear, checkable result.
- Keep the docs true
Low risk. A wrong correction is easy for a person to catch and reject.
- Run the routine chores
Routine work, checked against a build or test command you already run.
What to keep back, for now
Hold these until the herd earns your trust
- Work on a host besides GitHub or GitLab. The merge stage signs in with your own gh or glab today.
- A change with no way to check the result: no test, no build command, no clear acceptance criteria.
- Anything you are not ready to have a person approve. A human still approves the plan and the result.
See /will-it-work and /when-agents-get-it-wrong for the full list of limits, said out loud.
What to measure
Four things CodeHerder already reports
No target number. No benchmark. Read your own two weeks. Then decide what good looks like for your team.
Per-task cost
ch task show <taskId> prints what a task has cost so far. It also shows where the task stands against any budget you set.
Understanding costs →Change shape
Every task reports its own change shape: how many files, lines, and directories it touched.
Change shape →Stage history and rework rounds
Each stage transition is on record, including a send-back into code and which stage sent it there.
How work flows →Blocked reasons
A blocked task carries a reason: who filed it, and when. Some clear on their own; others need you to act.
Blockers and blocked tasks →FAQ
Questions people ask before Day 1
Do I need to follow this in exactly two weeks?
No. Two weeks names the shape of a plan. Move at whatever pace fits your team. Nothing here times you.
Who has to approve the first task?
Nobody, unless you set an approval gate yourself. By default, CodeHerder only advances a task on its own at the entry stage. A gate there is where an approval matters most.
What happens if the first task goes wrong?
Review usually catches it before merge. A send-back into code then runs on a stronger model. A task that keeps failing stops and moves to blocked. A person then decides what happens next.
Can I run this rollout without an engineer?
Day 1 needs a technical teammate for the one-time device and repo setup. Filing and approving tasks after that needs neither.
Ready to start the two weeks?
Tell us what you're building, and we'll get your first device and repo connected.