Six control surfaces, 22 practices, five ways a fleet fails, and the metrics that catch review debt before it becomes a queue. This is the operating model behind every merge request on this site, not a pitch for one.
Most writing about managing AI coding agents is vendor marketing for an orchestration product. This is neither. It's the operating model this studio actually runs, the same one that landed the merge request that shipped this page. The honest finding, confirmed by every fleet we've run and every one we've read about: once generation is cheap, review throughput is the bottleneck, not model capability.
Six control surfaces, each with a named owner and a specific failure it prevents. Skip one and the fleet doesn't get slower. It gets faster at producing work nobody can trust.
Each one governs something different. A fleet that's missing one doesn't fail loudly; it fails quietly, in a way that looks like progress.
Owner: Whoever writes the task — a tech lead, or the engineer requesting the work
What acceptance criteria a task carries before an agent starts, and whether 'done' has a checkable definition
Owner: Whoever owns the sandbox and orchestration layer — the fleet operator
Whether two agents can ever touch the same mutable state at the same time
Owner: The orchestration harness and pipeline definition — not any one agent
The sequence a task moves through, and what a fresh context inherits at each hand-off
Owner: Whoever owns the review queue — a tech lead, or the review-stage configuration
How many tasks can be in flight without the review queue growing unboundedly
Owner: Whoever curates workspace memory — often a lead engineer or the fleet operator
Whether a decision made once has to be re-litigated by every subsequent session
Owner: Whoever sets the harness's budget defaults — the infra or platform owner
The ceiling on any single loop's steps, tokens, wall-clock, and cost, and the gate every landing path must pass through
Filter by maturity (crawl, walk, run), then copy the visible list as a Markdown adoption checklist.
Showing all 22 practices
Output quality is capped by task specificity, not by model capability. An agent given "add authentication" will produce something that runs — and something that has nothing to do with what you actually needed, because it filled in the gaps itself, quietly, the way anyone would when the ask is underspecified. A task is a spec: background, a named goal, explicit constraints, and an acceptance criterion someone — or something — can check without asking the requester what they meant. A chat-prompt task feels faster to write and is the single most reliable way to get a confident, well-executed answer to the wrong question.
Fleets of coding agents fail on shared mutable state long before they fail on reasoning. Two agents editing the same file, a shared dev database mutated by two tasks at once, one agent's blanket add sweeping up another agent's uncommitted work — none of these are model failures, and no amount of better prompting fixes them, because the failure is architectural: two writers, one piece of state, no ownership boundary between them. The fix is unglamorous and non-negotiable: one task, one branch, one working tree, one sandbox — so a task that misbehaves has a blast radius of exactly one task.
A fleet needs named stages with named exit artifacts, not an agent that decides for itself when it's done. Plan produces a plan; code produces a diff and an open request; review produces a verdict; merge produces a merged change; verify produces a pass or a routed-back failure — and every stage starts a fresh context that inherits nothing except what the previous stage wrote down. A stage that can't advance releases the slot instead of looping in place waiting for input that isn't coming. Skip a stage, or let an agent self-certify that a later one isn't needed, and the fleet quietly reverts to one long, ungated context nobody can audit.
Once generation is cheap, review is the bottleneck — and adding agents without adding review capacity doesn't raise throughput, it grows a queue of unread work with a friendlier name attached to it. The fix is layered: machine review first, adversarial and independent, catching what a first pass misses before a human ever opens the diff; a human reviewing decisions and the diffs that actually carry risk, not rubber-stamping every line of every PR because there are more of them than there is attention to spare. A fleet sized past its actual review capacity is not shipping faster — it's converting engineering hours into an ever-growing pile of merge requests nobody has read.
A fleet that forgets re-litigates the same decision every session, at the same cost, and arrives at a different answer half the time because the reasoning that settled it last time lived in a context window that no longer exists. Conventions drift the same way: every fresh agent invents its own idiom for a problem the last one already solved, because nothing durable told it otherwise. The fix is memory that outlives any single session — shared, versioned, workspace-level, curated rather than left to grow into an unread pile — not a per-tool cache that dies the moment the process exits.
Every agent loop needs an explicit ceiling — steps, tokens, wall-clock, cost — enforced by the harness, not requested of the model, because a model has no reliable internal sense of "I've tried this six times, stop." And every landing path needs a gate no agent can bypass: no direct pushes to the default branch, CI as the arbiter, a forced terminal state when a budget runs out instead of a loop that idles indefinitely. Skip either one and the failure mode is the same shape twice — a retry storm that turns a two-dollar task into a two-hundred-dollar one, or a 3am unreviewed change that only gets noticed once it's already live.
No practices match that combination. Clear a filter to see more.
Every one of these looks, from the outside, like an agent capability problem. None of them are.
Looks like: Merge lag climbs while "throughput" improves — more tasks completed, longer queue of them waiting to actually ship.
Guardrail: Cap in-flight tasks at the review capacity you actually have; run machine review before human review.
Looks like: The agent writes the tests it then passes, so a suite that is all green tells you nothing about whether the feature is right.
Guardrail: Author acceptance criteria before the code stage, by a different context; make verification its own stage.
Looks like: Every agent invents its own idiom for the same problem, because nothing durable told it what the last one decided.
Guardrail: Durable memory plus house conventions the fleet reads, enforced by lint and CI rather than by hope.
Looks like: The agent improves things nobody asked for, and the diff is twice the size the task actually needed.
Guardrail: Name the scope in the task; diffs outside the stated files get bounced at review.
Looks like: A loop that costs forty times the estimate, discovered on the monthly invoice instead of while it was happening.
Guardrail: Hard ceilings, a per-task budget, and "release, don't stall" instead of idle looping.
Every one of these is measurable today. Every one has a way of looking better than it is.
No invented metrics, no throughput multipliers, no client names. Just what this repository's own history proves.
CodeHerder is the task registry and per-task sandbox layer that runs this operating model day to day, the how behind the why on this page.
What teams ask us before adopting this operating model.
The opposite of it, structurally. Vibe coding is a chat prompt and a hope; this is a written spec with a machine-checkable acceptance criterion, an isolated sandbox, a named stage sequence, and a verification stage that runs after review — not a human eyeballing the output and calling it good.
Review, once generation is cheap. Adding more agents doesn't raise throughput if review capacity stays fixed — it just grows an unread queue with a faster-looking front end. Machine review before human review is the fix; see the review-throughput surface above.
Something has to implement the six surfaces — isolation, stage gates, and spend ceilings in particular are hard to run by convention alone — but the framework is the implementation detail, not the point. Judge any tool by whether it gives you these six things, not by its feature list.
Isolation: one task, one branch, one working tree, one sandbox. It's the least glamorous of the six surfaces and the one that causes the most damage when it's skipped — see the isolation surface above.
This operating model is about how work gets delivered, not about compliance sign-off — those are a different, and real, set of questions. See our AI Security Review for the InfoSec, privacy, risk, and procurement checklist a regulated system also has to clear.
No — review throughput is the human bottleneck by design, not an oversight to engineer away. A senior engineer's judgment is what the review and stage-gate surfaces exist to apply efficiently across more work, not what they replace.
Pick two surfaces, not all six: task definition (require an acceptance criterion on every task) and spend and blast radius (a hard ceiling and branch protection). Both are crawl-maturity, both are cheap, and both prevent the two failure modes that do the most damage first.