I've been building and operating a personal software factory since May.
Software factories organize product engineering work so that human engineers only focus on describing what to build, its aesthetic, its architecture, and its tradeoffs.
Swarms of coding agents do the rest. They write the code, build it, test it, and review it in a loop until it meets a certain quality bar. The agents also prepare a merge candidate, handle rebases, and resolve code conflicts across work happening in parallel.
In this approach, human engineers improve the final product by improving the machine that builds it instead of working directly on the product's code. The factory and its product become inseparable.
For an example, see the workflow image below and the Fluent codebase on my GitHub.
Over the past couple of months, I've worked on improving my factory so it can produce high-quality code using open-weight AI models running locally on my desk. The two Nvidia DGX Spark machines in the picture below run 8 concurrent slices of coding work using the open Qwen3.8-27B model.
In the past, while managing human-only engineering teams, I would encourage my teammates to break work into small, shippable vertical slices of functionality that could be built, reviewed, and shipped in approximately two working days. This was a high bar for continuous delivery. Elite teams that had their processes and systems dialed in could reach a level where each engineer shipped approximately 10 such slices a month.
The two Spark machines on my desk cost approximately ten thousand dollars and consume a few dollars' worth of electricity a month. Each slice of functionality goes through 10–15 cycles of building, testing, and review. Multiple independent reviewer agents look at the code from a variety of angles, including security, architecture, and quality. They give writer agents feedback to fix and improve their work until all the reviewers are satisfied.
During this process, between 5 and 100 agent instances work on landing one slice of functionality. Each well-planned slice takes about 2 hours, on average, to build and land. The output is high-quality software. The same slice would've taken an experienced human teammate 2 days to land.
With 8 concurrently scheduled slices, this creates capacity for ~3,000 pull requests a month. This is a 300× multiplier on my time, provided I can fill the queue with well-specified work fast enough to keep the Sparks at ~95% GPU utilization.
Moving at this speed is extremely challenging. To keep up, I have to specify, unblock, and understand ~100 slices of functionality every day. So far, I can't keep up. And this capacity limit is a personal constraint I've imposed: I could buy more Sparks or host the open model in an elastic private cloud. Just thinking about what you're building at this pace is daunting.
From here, increasingly my focus in on the new tools we need to do product and architecture work at this pace.
