One Person, One Week of Unattended AI Code Delivery
In the seven days to 1 September, one person at A-CX closed 204 issues and merged 152 pull requests in a single repository. Most of that person’s week went into planning the work rather than writing it, with unattended AI code delivery doing the execution: runs that pick planned work off the board, work it in parallel, open pull requests, and merge them, most of it while nobody was watching.
Volume claims like that deserve doubt, so this post is the machinery rather than the claim. What the planning has to contain before an agent may touch it, how several agents run at once in the same repository without wrecking each other’s work, and the two points where the whole thing stops and waits for a human.
One Engineer, Many Agents
The repository holds our own AI configuration: the skills, agents, and plugins A-CX uses across Claude.ai Chat, Cowork, and Claude Code, with the same bundles consumed by GitHub Copilot CLI. We publish numbers from our own codebase because we can show you the commits. We have written before about why we built our own tooling instead of adopting someone else’s.
That engineer’s week went on planning the work, gating the calls that need judgment, and reviewing what came back. Execution ran in parallel around them, including overnight. The division of labor is the whole model, and it holds only because the planning underneath is specific enough for an agent to execute without asking.
204 closed issues is a heavy week, and we will not present it as a steady rate. Several large parent issues closed at once. The part worth your attention is that the machinery producing it behaves the same way on a quiet week.
The Real Work Happens Before Any Agent Starts
The number at the top of this post is weak evidence that agents are fast. It is strong evidence that planning pays. Most of the engineer’s hours went into planning, and the execution that followed was the cheap part. Skip the planning and you do not get a slower version of this week. You get a different and worse outcome.
Every issue an agent picks up carries four things: an objective stating what should be true when the work is done, a technical design the implementation has to conform to, acceptance criteria written so a reviewer can check them, and explicit dependencies naming the issues that must land first. None of that is documentation written after the fact. It is the input the agent executes against, and its quality sets a hard ceiling on the output.
An underspecified issue does not produce a slow result. It produces a confident, well-tested implementation of the wrong thing, and it produces it quickly. That failure mode is worse than a missed deadline, because the code looks finished and the tests are green. This is the whole reason our readiness gate refuses work instead of guessing at it. An issue missing a clear objective, checkable criteria, or a stated dependency order is not eligible for a run to pick up, and the gate exists because the alternative is discovering the ambiguity after fifteen pull requests have been built on top of it.
Sequencing carries as much weight as specification. Work is delivered in dependency order, and getting that order right is a judgment call made by a person who knows the codebase. Get it wrong and parallel agents hand you a pile of pull requests that each pass on their own and conflict with one another.
The honest arithmetic: planning is where the engineer’s hours went, execution is where the calendar time went. Moving effort from typing to specifying is the actual change in the job, and it is a harder skill than the one it replaces. Anyone expecting to skip the planning and keep the throughput will get volume without direction, which costs more to unpick than a slow week costs to wait out.
How the Volume Happens
Many Agents at Once, One per Unit
A run does not work a queue one item at a time. Several agents execute in parallel in the same repository, each owning exactly one unit of planned work in its own isolated context, where a unit is a single issue or a feature cluster that ships together. Parallelism is the entire explanation for the throughput. It is also the fastest way to destroy a repository.
How They Avoid Corrupting Each Other's Work
Parallel agents in one clone share an index, a working directory, and a run-state file. Left alone they stage each other’s changes, overwrite each other’s state, and both derive the same next decision-record number from the same directory scan. We hit all three.
The fix has three parts. Every unit gets a dedicated git worktree on its own branch, so no two agents share an index. A registry in the git common directory claims an issue atomically, so a second run on the same issue is refused outright instead of quietly clobbering the first. Numbered artifacts come from atomic counters rather than a directory scan, so two agents never receive the same number.
Teardown is guarded as well. Before a worktree is removed, the run checks for uncommitted changes and stops if it finds any, because the alternative is discarding work nobody has seen.
What Your Team Actually Reviews
A feature cluster ships as one pull request that closes its sibling tasks, and standalone issues get their own. Both extremes were rejected along the way. A pull request per task produces churn nobody reads, and one pull request per run produces something nobody can review. The reviewable unit is the feature, which is how the team already thinks about the work and how the planning already grouped it.
Where a Person Still Says Yes
Two gates after the planning gate. Each one was added after a specific incident. The human-guided version of this flow, from product idea to merged code, is a separate post; what follows is what survives when nobody is driving.
Readiness
Work a machine found is not eligible for delivery simply because it exists. A run that discovers a bug may file it, and the filed bug then sits until a person grants it. The grant is expressed as a priority label. No label means the issue is real and nobody has decided it should be built yet.
One narrow exception exists. A run may grant its own readiness, marked in the issue body as an autonomous grant, which makes it the only work in the pipeline no human planned. We bound it at fifteen such units per run, each shipping as its own revertable pull request, and self-granted work is verified at arm’s length from the agent that granted it. The orchestrator re-runs the failing test the grant cites, checks the commit it names, and reads the spec line it quotes, rather than trusting that the citation looks well formed.
The Merge Checkpoint
A pull request closing an autonomous-grant issue is review-sensitive, meaning a passing automated review verdict is necessary and not sufficient. It does not merge on that verdict alone.
Detection reads the linked issues rather than the diff, so one marked issue among several makes the whole pull request review-sensitive, with no partial state. When a linked issue cannot be read, it fails closed. A single configuration key waives the rule, and setting it is a deliberate act by a named person.
What the Numbers Do Not Say
204 closed issues is throughput. Throughput and value come apart easily, and roughly one in twenty machine-derived findings gets rejected on review. We watch that rate rather than celebrate it: low enough to be workable, high enough to show the review is doing something.
The figure also hides where the effort actually sat. A week of planning produced that week of execution, so the cost did not disappear, it moved earlier and became harder to see. And the volume creates its own work: more pull requests means more review surface, and review is where one person becomes the bottleneck. That is the honest limit of a one-person model. Anyone selling agentic delivery as pure headcount reduction is describing a different product than the one we run.
If You Are Considering This
Five things we would put in place before turning parallel agents loose on a repository, in this order.
- Planning an agent can execute against. An objective, a technical design, checkable acceptance criteria, and a dependency order on every issue. This is the expensive part and the part that determines whether the output is worth having.
- Decision records the agent can cite. Ours holds 130 of them, and agents refuse work by pointing at one. A rule that lives only in someone’s head cannot be enforced at three in the morning.
- Isolation before parallelism. Worktrees, an atomic claim registry, and counters for anything numbered. Add agents after that, not before.
- A gate that can actually fail. A check that passes whether or not the code beneath it works is worse than no check, because it buys confidence nobody earned.
- A named identity for machine work. Machine commits under a machine account, so every autonomous change is attributable without guessing which person was awake.
We are publishing one of these every Thursday, working through the parts that took us longest to get right. Next week: the gates that stop an agent approving its own work. If you are weighing this for your own team, our AI Workflow Automation work is where that conversation usually starts.
