I spent a day building a code factory: a manager agent that reads a project's own build plan, works out what can be built in parallel, hands each subtask to an engineer in an isolated workspace, and merges the result behind a test gate.
It works.
Five subtasks built, tested, merged and logged in under a minute, on a backlog that was written weeks before the factory existed.
Three things about it were wrong on the way there.
None of them showed up in the design, in review, or in the tests.
All three showed up in the log, and two of them only because I went looking for something else.
What the thing is A manager agent on Google ADK, running .
Six tools: read the graph, read what the human pointed at, delegate, poll, merge, finish.
The engineers work in their own on their own branch, run the tests for the area they touched, and commit.
The manager merges to one trial branch, one at a time.
The design comes from a paper by Geng and Neubig on asynchronous software engineering agents, which measures something worth repeating: two runs on the same repository, the same model, differing only in which files got assigned, scored 8.7% and 34.3%.
The expensive decision is not the code.
It is what goes out next.
So that is the decision I gave to the model, and only that one.
One: the plan carries the tasks, not the order The manager was supposed to read the dependency graph out of the build plan.
That is a 1,300-line document with 115 open subtasks, written over three weeks by someone who knew exactly what depended on what.
I searched it for every phrasing I could think of.
One subtask states its dependency in a form a machine can read.
One, in the whole document.
The order lives in the head of whoever wrote the plan, and a manager cannot get in there.
An agent asked to "derive the graph from the plan" will find that single edge, invent the rest, and say nothing about which is which.
So the edges are now written by hand, per run, in a file the human can see and correct.
The builder refuses a run where a subtask has no entry: an empty list means "checked, independent", and a missing entry means "nobody looked".
Those are different things, and only one of them is safe.
The one edge the plan does state is the interesting one.
Subtask 7.3 requires four subtasks from another phase that are not part of this run.
Every run I have done leaves 7.3 alone and says why on the dashboard.
A manager that had guessed the graph would have built it, against a service that does not exist yet.
Two: a guardrail in the prompt is not a guardrail Some files must not be touched by an engineer.
The build plan itself is the sharpest case: it holds every checkbox, every log line, and a running total that has to be added up by hand.
Two writers on that file is exactly how it went wrong twice in this repository already, and neither time did git say anything, because the two writers touched different lines.
The first version of the manager's instruction said: do not touch these paths.
That reads fine and is worth nothing.
A model that can be asked not to do something can be argued into doing it, and the log will show a confident sentence either way.
The check now runs on the diff, in code, immediately before the merge: One match and the run ends.
Not a warning, not a retry, not a fix.
The reason is not tidiness: once a forbidden file has been touched, I can no longer tell whether the bookkeeping is right, and a factory whose bookkeeping might be wrong is worse than no factory.
The path matcher has its own test table with 18 cases, and the ones that matter most are the non-matches. is allowed, because only the one at the root is the status document.
A pattern that is too wide stops a run over work that was always fine, and that costs exactly as much as a rule that does not fire.
Three: isolation is not concurrency This is the one I would have shipped.
Someone asked me a simple question: do the engineers work in their own branches?
They do.
Own branch, own worktree, visibl