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.
A manager agent on Google ADK, running gemini-3.7-flash
. Six tools: read the graph, read what the human pointed at, delegate, poll, merge, finish. The engineers work in their own git worktree
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.
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.
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:
git diff --name-only base...branch | config.py --stand -
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. services/watchdog/BUILDPLAN.md
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.
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, visible in git worktree list
. I pulled up the log to show it, and the log answered a question I had not asked.
15:22:02 eng-1 klaar 7.1 done
15:22:03 eng-2 opgewarmd worktree on proef/fase7-caid-eng-2
The first engineer finished before the second one started. The workspaces were isolated, the branches were real, the merges were test-gated, and the whole thing ran one after the other. The engineer loop was synchronous, and nothing in the design, the dashboard or the tests had any opinion about that.
The paper this is built on is about asynchronous collaboration. Isolation without concurrency is branch-and-merge without the reason for it. And in a demo it would have been a claim I could not support: two lanes side by side on the screen, filling in sequence.
Engineers now start in their own thread and the manager does not wait. Merging stays sequential, which is not an omission. Integration is one at a time and test-gated precisely so that building can be parallel.
Afterwards the log interleaves, which is the only way I know to check it:
15:25:48 eng-2 begonnen
15:25:48 eng-1 begonnen
15:25:48 eng-1 toets groen
15:25:48 eng-2 toets ...
15:25:48 eng-1 commit d53e7ba
15:25:48 eng-2 commit 69e2bf1
All three findings came out of one design decision I did get right, and it was the first one I made.
Every line in the log carries its source. Reported is what the agent says about itself: rich, early, and not to be trusted, because an agent that has lost the thread reports progress that is not there. Measured is what git says: thin, late, and impossible to fake. A commit exists or it does not.
The dashboard marks the two differently, and two of its eight warnings fire exactly where they disagree: an engineer that reports three times with no measured change, and silence on both sides past a threshold.
Finding three was a timestamp comparison between two measured lines. If the log had held only what the agents said about themselves, the answer would have been "yes, both engineers worked on it", and that would have been true and useless.
One run, on one repository, on a backlog I chose. The paper behind it measures a spread from +30.7 to −10.5 percentage points between repositories, so a single result sits inside its own noise.
The headline numbers are worth reading carefully as well. The abstract reports +25.6 percentage points, and that is the weakest of the three models tested. For the strongest model the same table shows +6.1 and +6.0, at roughly two to four times the cost, and the wall-clock goes up in every row. Coordination buys accuracy, not speed. Anyone selling you the opposite has not read the runtime column.
What I can say is narrower and I think more useful: the mechanism runs, the guardrail holds when tested against it, and the two failures I found were both invisible until something ran and wrote down what it actually did.
Built at Business Data Solutions, a Dutch consulting and training firm that helps organisations put their data to work. The factory runs against Plinkie, a price-comparison system we operate on Google Cloud, so the backlog it builds is a real one.
If you are working out where an agent belongs in your own delivery process, or where it does not, we are happy to think along. You can reach us through the contact form.
We wrote this piece for the purposes of entering the All Things Agentic Hackathon run by Google Cloud and Devpost.