Summary

A software dark factory writes and verifies software without a human in the loop — no one authoring the code, no one reviewing it. It sounds reckless. It isn’t, provided you get two things right: what you want, and how you’ll prove you got it.

‍

Lights off

Some factories run in the dark. The robots don’t need light to see, so the lights stay off, and the product rolls off the line with no one on the floor. The plant didn’t remove people by cutting corners; it removed them because the process no longer depended on them.

StrongDM put the software version of this into two rules:

• Code must not be written by humans.
• Code must not be reviewed by humans.

Read quickly, those rules sound like an abdication of responsibility. Read carefully, they’re a challenge: build a process so well-specified and so well-checked that human hands in the middle would only slow it down or introduce error. The humans don’t disappear. They move — to the start, where the work is defined, and to the end, where the result is accepted. Everything in between runs autonomously.

At Mechanical Orchard we build these factories for a specific job: modernizing legacy systems.

‍

Why modernization fits

Modernization is a peculiar kind of problem. The hard part isn’t imagination — it’s fidelity. A decades-old system already does something, often something critical, often something nobody fully remembers. The goal isn’t to invent; it’s to reproduce that behavior on a modern foundation you can trust — and, from there, change safely.

That makes modernization unusually well-suited to autonomy, for one reason: the goal is precise and the result is verifiable. You’re not asking a machine to guess what “good” looks like. You already have the answer — the old system — and you can check the new one against it. Where there’s a definition of done and a way to prove you’ve reached it, you can take humans out of the loop without taking judgment out of the work.

Which brings us to what you have to get right.

‍

The seed and the harness

A software dark factory rests on two ingredients.

The first is the seed: what you want. The goal, plus all the source material that defines it. In modernization, the seed is the legacy system’s form — its source code, its examples, its documentation, everything that explains how the thing is built and what it was meant to do. The seed is the answer to what are we building?

The second is the harness: how you prove you got it right. If the seed is the system’s form, the harness is its behavior — what it actually does, captured and made checkable. The harness is the answer to how do we know we’re done?

In modernization, that question has a hard edge. Legacy systems almost never come with tests — no suite to inherit, no reference outputs to check against. The behavior is real but undocumented; it lives only in the running system. So we build that ground truth ourselves. We characterize the legacy system with synthetic data designed to exercise its paths, and we collect real production data to see how it responds under genuine load and real-world edge cases. Together these give us a corpus of inputs and the outputs the old system produces for them.

That corpus is what makes verification possible: we run the legacy system and the new one in parallel against the same inputs and compare their results. Where they agree, the new system is faithful. Where they diverge, we’ve found work that isn’t done. That comparison — old versus new, output by output — is our harness.

Neither is optional.

A seed only sets a direction, and direction alone doesn’t get you there. An autonomous run makes thousands of small decisions, and small errors compound until the result is confidently, comprehensively wrong. A seed without a harness is therefore dangerous, not merely incomplete: give a factory a vivid goal and no way to check itself, and it will run straight past the target, tirelessly delivering something that looks like work and isn’t. The harness is what catches the drift and pulls it back, again and again, until the factory converges on the goal. A harness without a seed, of course, has nothing to build. The two together are what make the factory real.

And neither is cheap. A seed isn’t a prompt; it’s often a substantial, researched document. A harness isn’t an afterthought; it’s the thing that earns your trust. This is the work humans own, and it’s most of the work — the factory is only ever as good as the specification it’s given and the checks it must pass.

‍

How to think about a factory

Once you accept that the human effort lives at the edges, the design of the factory in the middle follows from a handful of principles. They’re less rules than a way of thinking.

A factory is a single production line. Workers at each station do their part, hand off, and the next picks up, until a finished product rolls off the end. When work can happen in parallel — ten parts that don’t depend on each other — the line splits into lanes that run side by side and merge back when it’s time to assemble. Reach for a factory when the problem is specifiable, self-contained, and too big for a single pass.

The worker is never its own inspector. This is the principle that makes the rest trustworthy. Never trust a single worker’s account of its own output. The agent that does the work is never the agent that judges it; every piece of work meets an independent check, and that check sends it back when it isn’t good enough. This is the harness, expressed in the structure of the line itself. There’s a subtlety here worth keeping: if a worker can see the exact test it must pass, it will optimize for passing the test rather than doing the work — so good checks describe what correct looks like without handing the worker the answer key.

Workers are workers, not code generators. It’s tempting to think of an agent as a smarter transpiler — something that takes input and mechanically emits code, the way the dumb, deterministic translators of the past did. It isn’t. An agent runs commands, reads the output, diagnoses what went wrong, and fixes it; it works toward a goal rather than transforming a line at a time. So you tell it what to accomplish, not how. Scripting a worker step by step throws away the one thing that makes it more than a transpiler — its ability to figure out the how.

No human gates in the middle. Not that there are no gates — the line is full of them: checks, watchdogs, and validation steps that refuse to pass work that doesn’t measure up. What’s absent is the human gate. Humans belong at exactly two points: designing the line before it runs, and accepting what it produces after. In between, the gates are automated and the line runs on its own. The moment it needs a person to make a judgment call mid-run, it has stopped being a dark factory — a useful signal that some problems genuinely want a human in the loop.

Structure carries the flow; workers carry the work. The shape of the line is deterministic: it decides who runs after whom, and under what conditions, and nothing more. The workers are not — they reason, and reasoning varies from run to run. This division is the whole trick. The deterministic structure bounds the non-deterministic agents, giving their open-ended work a fixed frame to move within. Push decisions and transformations into the wiring instead of the workers, and the separation collapses: the structure is no longer predictable, and the workers are no longer doing what makes them workers.

Agents communicate only through artifacts. There’s no shared memory between workers — they pass each other nothing but artifacts: checklists, files, reports, documents left on a shared workspace. So every instruction must be self-contained: what to read, what matters, what came before.

‍

You don't program the factory — you draw it

The factory isn’t written as a program. It’s described as a diagram: boxes connected by arrows, where each box is a station and each arrow is a route the work can take. That is the whole blueprint.

The choice of a diagram over a program is deliberate. A diagram can’t express the tangle of nested conditionals and bespoke logic that a programming language invites; it expresses only flow — which station runs next, and when. That limitation is the feature. It keeps the design honest about what it is, a sequence of stations and the paths between them, and pushes the real work out to the agents, where it belongs. The result stays legible: a human can take in at a glance a factory that will run for days.

There are only a handful of kinds of station, and everything the factory can do is built from combining them. Some put an agent to work. Some are decision points that read what just happened and choose which arrow to follow. Some split the line into parallel lanes, and others wait for those lanes to reconverge. The principles from earlier are just these pieces wired together. The independent check becomes a loop: route the arrow out of a failed check back to the station that produced the work, and it redoes and rechecks until the work passes, with nothing leaving the loop until it has earned its way out. Parallel work becomes a fan-out: split the line into ten lanes and ten agents run at once, each in an isolated context but on a shared working directory, until a fan-in station gathers them and assembly continues.

The engine is built to survive the failures of a long run. It monitors each agent for liveness, and one that hangs or goes silent is killed and its station retried automatically. State is checkpointed after every completed station, so an interrupted run — a crash, a killed process, a machine that went away — resumes exactly where it left off, with every decision and result intact.

The agents themselves are interchangeable. The factory is the orchestrator; the agents are labor it dispatches to, so one station’s work can go to one coding agent and the next to another — the right tool for each job under a single line.

‍

Turning the lights off

Autonomy without boundaries is reckless; autonomy within boundaries is the entire proposition. A factory runs inside a contained, sandboxed environment, with a defined scope of what it can touch and change. And the harness is itself a boundary: work that can’t prove it’s correct doesn’t ship. The same mechanism that keeps the factory on course keeps it safe.

None of this is mysterious once you’ve seen the two ingredients. AI writing code is the least of it; what matters is the discipline around the code — a precise seed, an independent harness, checks that no worker can grade for itself, a line designed carefully enough to trust, and boundaries drawn tightly enough to make autonomy safe. That discipline is what lets a factory run in the dark.

It’s also how we modernize legacy systems — at a speed, and with a fidelity, that translating them by hand never offered. The question was never whether the lights are on. It’s whether you understand what you’re building well enough to turn them off.

‍