The problem

Coding agents are fast, tireless and confidently wrong. Give one a large task and it drifts, reports success it never checked, and will change a test until the test agrees with the bug. I have more work than people, so I wanted the throughput of many agents in parallel without giving up control of quality.

With agents, typing code stops being the hard part. The work becomes specifying tasks precisely and verifying what comes back.

What I built

Not a product: a way of working, written down and enforced in tooling. I run it on Hermes Agent, an open-source agent runtime.

  • One orchestrator per project. It plans, writes the briefs, reviews and verifies, and does almost none of the ground work itself.
  • Workers in parallel. Each worker agent owns one slice of the work and its own set of files.
  • An independent reviewer. Important plans and final changes are graded by a different model from the one that wrote them.
  • Routing by sensitivity. Anything that touches credentials or private configuration stays on models running on my own hardware.
  • A rulebook that learns. Every correction I have to make twice becomes a written rule or a task-specific skill, so the next session starts from it.

How it works

  1. human Plan in acceptance slices Each slice has a definition of done that a command can check
  2. input Self-contained brief Inputs, owned files, forbidden actions and the check to run
  3. agent Parallel workers Tests first, results written to disk as they go

  4. Group, not done until verified (steps 4–6)

    check Orchestrator review Reads the diff and the raw test output, not the summary
  5. check Independent review A different model grades the plan or the final change

    Loop from step 5: fix round: back to step 3

  6. check Live proof and full gates Real system, fresh clone, CI green for that exact commit
  7. output Commit with evidence Every claim names its check and its result
One unit of agent work, from plan to commit

A few rules carry most of the weight:

  • A worker’s report is a self-report. I read the diff and the raw test output, and re-run the gates on a fresh clone of the pushed commit with a clean install. A worker’s long-lived checkout can pass on a tree that nobody else can reproduce.
  • Settle the design in the brief. Open questions such as “find the right approach” are where agents loop. A brief names exact paths, the acceptance command and what is out of scope. Hard design choices go to a stronger model first.
  • One owner per file. Parallel workers get disjoint files and no git commands; only the orchestrator commits. A worker that stashes changes to check whether a failure is new silently removes its siblings’ edits.
  • Never weaken a test to make it pass. A red test after a change is either the bug or the old rule. Read it and decide; then revert the fix once and watch the new test fail.
  • Evidence before claims. “Done” names the command, the commit and the result. A status update carries numbers, not “still running”.

In practice

In October 2026 I rolled a shared design system out to five of my own repositories. The shared UI package was published and smoke-tested before any repository work started. Then each repository got its own worker, never two in the same repository.

Before accepting a stage, the orchestrator re-ran its gates on a fresh clone. For the reports stage of a personal-finance app that meant 2,434 of 2,434 unit tests and a production build, all green. CI still failed: one of 263 browser tests, because the restyle had turned “36.0%” into “36 %”. No unit test could see it. The fix went into the app, as a fixed-decimal percentage component that later moved into the shared package. The test was not touched.

The same discipline runs my benchmarking: an overnight campaign is only worth something if every request in it is checked. That is the subject of the inference lab case study.

What I’d do differently

  • Smaller briefs from day one. Whole-feature briefs made workers plan in circles and finish with nothing on disk. Now a brief is one deliverable of 20 to 40 minutes, and the worker writes results as it goes.
  • Review the contract before the first wave. An independent review of the interfaces before several workers build against them is far cheaper than finding the gaps afterwards.
  • Declare the last fix round. Reviews narrow forever if you let them. After a few rounds, the remaining findings become explicit decisions or follow-ups instead of another loop.
  • Budget the orchestrator’s attention. Its context is finite and long sessions degrade, so work is committed often and every pause leaves a short hand-off file.