How I accidentally built a software factory
It started as a way to stop an LLM producing unusable code. Each problem I solved left another part of the development lifecycle behind, until it was obvious they could be wired together.
I didn’t set out to build a software factory. I ended up with most of the parts, and it made sense to finish the job.
It started in September 2025 with GuardKit. I wanted a way to control what an LLM produced and get it to a standard I would put into production, which at the time was genuinely difficult — the models were hard to corral into doing what you actually wanted. GuardKit became a set of quality gates and a task workflow around that problem.
By January I was using it to plan features and then implementing each task in the plan myself, running six or seven at a time in Conductor. That is repetitive work, so I automated it. AutoBuild came out of that, and out of Block’s research on adversarial cooperation: one agent implements, another tries to find fault with the result, and the work only moves on once it survives.
After that I built an architect agent, and then a product owner agent from it — most of the same codebase, with the differences defined as roles.
Around then James, Appmilla’s CEO, asked whether I was actually building a dark factory — a plant that runs with the lights off and nobody on the floor, which was one of the hot topics at the time. I hadn’t thought of it that way, but the answer was yes, more or less. Requirements, architecture, planning, implementation and review had all been built at different times for different reasons, and they were all there. Wiring them together was a much smaller job than building them had been.
What it is now
An intent router I named Jarvis, after the Iron Man films, sits in front of an orchestrator, the architect and product owner agents, and build agents working through the adversarial loop above. It doesn’t only write features: it runs them, and fixes them when they fail. Serving goes through llama-swap and messaging over NATS, with its own Postgres-backed memory service and domain knowledge in ChromaDB, all on DGX Spark hardware under the desk. Routine work makes no cloud calls at all.
I had meant to drive it by voice through a Reachy Mini robot, but the robot went to the Study Tutor instead, so the factory is controlled from Slack.
The hard part
Almost all of the trouble has been in verification. The BDD layer that was supposed to prove each feature worked had turned into a nightmare of broken glue and plumbing — more work to keep running than the code it was checking, and not telling me much when it did run. It has since been replaced, and a twin-test harness piloted in August caught a real defect within its first minute of running.
That was a rough stretch, but a productive one. The four repositories behind the factory now hold 74 features and more than 800 completed task records, and every component I demonstrated at DDD South West was built by AutoBuild. What the factory couldn’t do until recently was run the whole chain without me somewhere in the middle of it: the first feature to go from a written sentence to merged code with a single human pause was on 15 August.
Don’t try this at home
Building a software factory is genuinely hard, and harder than the current conversation about it suggests. “Agent” and “software factory” have both stretched to cover such a range of things that they have nearly stopped being useful — I have seen a packaged set of skills presented as a software factory. If you are considering it, the part that will take your time is not getting agents to generate code. It is proving that what they produced actually works, and that is the part nobody demonstrates.
None of this was planned as a factory. It was four or five attempts to stop doing something by hand, and it also gave me a subject for my DDD South West talk — explaining the whole thing to a room of people being a good way to find out which parts you actually understand.