Week 8 of Building a Software Factory: Looking at Another Factory
Eight weeks in, a third of the subscription is spent, so it is time to decide whether to keep going or pivot. This week I toured uzi, Vlad Mocanu's dark factory, and started trying it out. The post covers the vocabulary I re-read before that meeting, where each factory puts the human, and why I see a good fit in running both instead of replacing Mission Control, depending on how well uzi fits my workflow.
This is week 8 of building my own software factory, and it’s a good moment to evaluate how things are going. I have used a third of the Max 20x subscription I got for open source work, and before I spend the rest I want to be sure whether to continue in the same direction or pivot.
I believe in synchronicities, so I don’t think it’s a coincidence that this week I also sat down with Vlad Mocanu from Metaminds for a tour of uzi, his dark factory. I’ve started playing with it, which raises a question: what does that mean for Mission Control, my own factory?
Re-reading the vocabulary before the meeting
Before we sat together I refreshed the vocabulary: lights on vs lights off, one-way vs two-way doors.
“Dark factory” is a manufacturing term for a plant that runs lights off with nobody on the floor, and uzi borrows the name. What matters more is where the human sits. Human-in-the-loop: someone approves every action, safer but slower. Human-on-the-loop: the agent runs its cycle alone while a person watches a dashboard and steps in only for exceptions, the closest match to lights off. Full autonomy: nobody watches in real time, and review, if any, comes after.
What seems to be emerging in 2026 is that you don’t pick one of these for a whole system: oversight gets set per action, by risk, so all three coexist. Amazon’s one-way and two-way door framing fits: reversible calls get made fast and alone, irreversible ones wait for a human.
Mission Control already works roughly like this, though not by design. Everything up to the pull request runs without asking me. The merge is the one gate I hold every time: not because it’s always technically irreversible, but because that’s where I choose to keep a human in control. That’s my one-way door.
Re-reading this, I’ve started noticing decisions from earlier weeks of this series I’m no longer sure I agree with.
Where the human sits in uzi
Vlad is a gent, generous with his time, and I walked away with a lot to think about. I’m not ready to share findings yet, my notes are still raw, but here’s the comparison I’d prepared before we met.
uzi has two checkpoints: a person reviews the plan before work starts, and the diff before merge. Between them the run is unattended. Mission Control only has the end gate. Autonomy in uzi is one flag for the whole repository, and in Mission Control it’s a default per initiative that a single ticket can override. Vlad described the difference between uzi and something like OpenAI Symphony as “one idea, two very different calls on where the human sits.” At that other extreme, review moves after the merge, code is disposable, and a bad rework throws away the whole tree and restarts instead of patching it.
We also talked about how a factory should suggest improvements, both to the apps it builds and to the factory itself. That second part matters most to me, because it’s the premise of this whole experiment. Both factories do it: uzi informally, through scheduled jobs, and Mission Control through architecture decision records and postmortems as a formal discipline. I’m happy to spend as many tokens as possible closing tickets in Kairos, but what matters more is that tomorrow I know how to get better results, especially if those resources get scarcer, or if I manage to get some local inference running.
What this means for Mission Control
No, I don’t plan to stop working on Mission Control. For now I’m playing with uzi. I see a good fit in having the two running together, but whether I keep uzi will depend on how well it fits my workflow.
I have to accept that Mission Control isn’t only a software factory anymore. It’s closer to an assistant, an extension of me, and I already use it for more than shipping code. It now “owns” my internal Kubernetes cluster and ships apps there in a platform-friendly way. Right now that’s Forgejo and uzi, both reachable under *.apps.home.arpa. That suggests a possible answer: uzi wouldn’t replace Mission Control, it would become one more specialized factory that Mission Control runs underneath itself, the same way it already runs Forgejo. I like that shape. It’s still experimenting, but with requirements that match a production environment.
That also means I’m not really interacting with uzi myself, and I may not need to be. Mission Control does that part, and I keep guiding things the way I already do. I wouldn’t have to adopt uzi’s workflow: Mission Control could adopt uzi for me, while my own interface and working model stay exactly as they are. uzi is only one of the many projects I’m running, and it would be crazy to reshape how I work around each one of them.
I think many developers will land in the same place: subscribed to a common, shared factory for the routine work, and running their own highly customized harness, orchestrator, or whatever we end up calling it, on top of it. What we actually want isn’t one factory to rule them all, it’s an orchestrator that happens to use factories, for software and for everything else.
Next week
I’ll keep playing with uzi, and I hope to share my findings about it next week. I’m already happy that I opened my first issue, uzi#1682, and it got worked on so fast. Hopefully next it will be a contribution, though it’s weird to talk about contributions to factories: as soon as you report something, it can fix itself. Maybe we’ll be talking more about token donations.
The numbers
Between 19 and 25 September the factory merged 17 pull requests to Kairos, 55 to its own repository, and 2 to this website and homelab. It also wrote 5 architecture decision records and 1 postmortem. The internal board saw 99 issues opened and 119 closed. The full table is on the series page.
Compared to last week, Kairos went from 5 to 17, both weeks counting only the agent account’s pull requests, and the factory’s own repository went from 38 to 55. The website and homelab stayed about the same, 2 against 3. Decision records dropped from 7 to 5, and after a week without one, there’s a postmortem again. The board is back to closing more than it opens, but closing barely moved, 119 against 120. What changed is that far fewer tickets came in: 99, down from 153.
As before: this post was drafted by the system it describes, and I reviewed, edited and merged it myself. If you want to follow along you can subscribe to the RSS feed, find me on LinkedIn or YouTube, or say hello through my contact page.