Summary: A software dark factory runs with no human hands in the middle — but no human eyes off it, either. Autonomy done right doesn’t ask you to cede control. It relocates control to where it’s most needed; in fact, it makes the work more visible than a human process can allow.
What ‘dark’ means
We recently described how we modernize legacy systems with a software dark factory: no one authoring the code, no one reviewing it. The natural reaction to that description is a question about control. If no human writes the code and no human reviews it, who’s watching? What happens in the dark?
You watch every decision of consequence. “Dark” describes the level of automation, not the level of visibility. If you think in terms of a physical factory, the lights are off because the workers don’t need them, not because there’s nothing to see. In fact, you’re in a control room of your wildest dreams, one with details of every station.
Autonomy, built properly, doesn’t reduce your control over modernization. It increases it — and it makes the process more transparent than the human-driven alternative ever was.
The process you’re used to is the opaque one
Consider how a traditional, human-driven rewrite actually works.
A team of engineers reads the legacy code. They form mental models, each one private, partial, and slightly different. They make thousands of judgment calls: this branch is dead code, that behavior is a bug we shouldn’t preserve, this module means what I think it means. Almost none of those decisions are written down. They live in heads, in hallway conversations, in the space between a pull request and its approval. Code review — the mechanism we trust to catch mistakes — is a human skimming a diff, approving on reputation and fatigue as much as rigor. Crucially, when someone leaves the project, their share of the understanding leaves with them.
Ask a rewrite team, eighteen months in, why a particular decision was made, and the answer is often best left to archaeology: someone remembers, or no one does, but digging takes time.
That is the opaque process. We just don’t notice it because it’s the one we grew up with.
Clarity in darkness
A dark factory can’t work that way, because agents don’t hang out in hallways. As we described in the original post, workers on the line communicate only through artifacts — checklists, reports, documents, code — left in a shared workspace. There is no shared memory, no tribal knowledge, no undocumented judgment call. Every decision leaves an artifact behind, not because a policy requires one, but because the next station wouldn’t have anything else to work from.
The result is a kind of transparency that human processes cannot produce because, for the factory, it isn’t a virtue; it’s foundational.
Stand in the control room and you can see, at any moment: what every station is doing, what each worker produced, which independent check it faced, whether it passed, and — when it didn’t — exactly what was sent back and why. The line’s structure is a diagram a human can take in at a glance. The factory checks state at every station. When the run is over, the full history is still there: every decision, every rejection, every retry, in order.
No human team, however disciplined, leaves a trail like that. In contrast, the factory needs it to run.
Control moves to where it counts
The deeper point is about what “control” means. A human reviewing code in the middle of the process certainly feels like control, but it’s just that; mostly a feeling. After all, after some point you have one tired reader, one diff at a time, sampling a tiny fraction of the decisions being made.
Real control over a modernization project lives at two points. First: defining what must be built. The seed — the goal and everything that specifies it — is authored by humans and is the single highest-leverage artifact in the entire effort. Second: deciding what to accept. The harness — the corpus of the legacy system’s observed behavior, and the parallel-run comparison against it — sets the standard that nothing ships without meeting, and humans decide when that standard is satisfied.
The dark factory doesn’t remove humans from these points. In fact, it concentrates them there. Instead of spreading human judgment thin across ten thousand micro-decisions, where it can often be unauditable and inconsistent, it pools that judgment where it becomes foundational: into the specification everything must serve and the acceptance bar everything must clear. Control hasn’t diminished; it’s moved from where it’s most susceptible to human error to where it’s strongest, at the point of declaration of intent.
And in between, the gates don’t blink. The worker is never its own inspector: every piece of work meets an independent check, and work that fails is sent back until it passes. A human reviewer approves what’s already passed those strict criteria, what’s been proved right against its check.
Visibility is comfort, but parity is proof
While this window into the factory tells you what’s happening, it doesn’t, by itself, tell you if the result is correct. That job belongs to the harness: the legacy system and the new one, run in parallel against the same inputs, compared output by output. Where they agree on every case in the corpus, that behavior is done; where they diverge, the factory has more to do. So while watching the line is how you stay informed, parity against your own system’s real behavior is how you definitively know.
Both matter, but they answer different questions. Transparency answers: can I see what’s being done? (Useful for compliance issues!) The harness answers: can it prove what it did matches? Answering both questions is essential, and the dark factory is built to offer both.
The question to ask any autonomous process
If you’re evaluating automation in modernization efforts, the question isn’t “is a human in the loop?” It’s a weak proxy for a much more comprehensive question you’re actually asking, far beyond an actual human, staring at code. Ask instead:
Can I see every decision of consequence the process made, after the fact and while it runs?
Is the work checked by something independent of whatever produced it? Or is AI marking its own paper?
Is “done” defined by evidence I chose and can inspect, or by someone’s assurance?
And when the answer is wrong, does the process catch it before I do?
A human-driven rewrite struggles to answer most of those cleanly. A well-built dark factory inherently answers all four.
Turning the lights off on the factory floor didn’t cost you visibility — it’s what made total visibility possible, because a process that runs on artifacts and independent checks can’t act on anything it hasn’t written down.
The factory runs in the dark. The customer never does.
Master class. Thank you.
Thanks for an insightful post Rachit. I think your description of what constitutes a software dark factory is one of the better ones I have read and understood. It's a post worth spreading.