The phrase is everywhere. The working meaning is gone.

I sat down to write about software factories, and the first thing I had to do was take the word back. Every vendor has a "dark factory" slide. Every Devops team has a "lights-out deployment" demo. The phrase has been stripped the way "platform engineering" was stripped, the way "Devops" was stripped before that.

The marketing version: AI writes the code, the pipeline ships the code, humans go home early. That is a fantasy. It assumes the spec is correct, the spec is complete, the spec captures every invariant the running system has to preserve. None of those are true today.

The working version is a smaller claim, and a more useful one.

The working definition

A dark factory is a build pipeline that ships production software with no human in the critical path. Spec in, artifact out. The intermediate steps happen unattended.

The opposite is a light factory. Same inputs, same outputs, but a human signs off between every major stage. The human is the gate.

Many teams are not running either. They are running a partial factory. Some stages are dark; CI runs unattended. Some stages are light; the merge to main requires a reviewer. The work is figuring out which stages should be which, and what the seams look like.

The five positions

Treating "dark" and "light" as a binary loses the part that matters. The positions, named:

  1. Manual. A person runs the commands. No factory yet; the engineer is the build system.
  2. Assisted. CI exists. Tests run. A person merges. Many teams live here and call it Devops.
  3. Light. Merge is gated by policy, not by reviewer. The pipeline is the gate. A human is the auditor, not the approver.
  4. Dark, gated. The pipeline ships. A human is the only one who can promote from staging to production. The factory runs, but it cannot cross a particular seam without a key turn.
  5. Dark, full. The pipeline ships. Promotion is policy-driven. The human's role is to write the policy and the spec, then to inspect the artifacts the factory produces.

The interesting range is between three and four. The question is not how to get to five. The question is which of your stages should be at which position, and why.

What the framing changes

Calling it a factory reallocates where the engineering effort goes.

You stop asking who is on call for the deploy and start asking what the failure mode of the deploy step is. You stop asking how fast your engineers can merge and start asking how fast the policy can express a correct merge. You stop asking whether the code was reviewed and start asking whether the spec the code was generated from is auditable.

A factory is designed, not grown. A factory is maintained, not improvised. A factory has a failure budget, not a heroism budget.

If the build system you are running is a pile of bash scripts and a Slack channel, the factory framing is going to be uncomfortable. That is the point.