Pure dark factories are for vendors. Pure light factories are for teams that do not trust their pipeline. The interesting engineering is in between.

The ends are easy to describe. The middle is where the work is.

The light factory

A light factory is what most teams have when they say "we have a CI/CD pipeline." Code is written. Tests run. A human reviews the diff. A human approves the merge. A human triggers the deploy. A human watches the deploy. A human confirms the deploy is healthy.

Every transition is a handoff. Every handoff is a place for a person to add or remove judgment. The team scales linearly with the number of handoffs. The team does not scale linearly with the number of engineers, because the handoffs are the bottleneck.

At some point, the handoffs become the work. The team is not shipping product. The team is moving code through human gates. The product slows. The hiring ramps. The handoffs grow. The team gets further from shipping and closer to queue management.

The dark factory

A dark factory replaces the human handoffs with policy. Spec in, artifact out. The policy is the rules. Nothing in the middle requires a person to act.

This is a team that ships constantly, unattended. The product is moving fast, except when the policy is wrong. When the policy is wrong, the product moves fast in a bad direction and no one notices until the customer does.

The middle is a position, not a transition

The middle has three properties.

  1. The pipeline is the gate. The merge to main is not gated by a reviewer. It is gated by a policy expression. The policy is code. The code is reviewed.
  2. The human is the auditor. The human inspects what the pipeline produced. The audit is sampling-based, not exhaustive. The audit answers "did the policy work this week," not "is this merge correct."
  3. The spec is the source of truth. The code is generated. The test suite is generated. The deploy manifest is generated. The thing the human writes is the spec, and the spec is what gets reviewed.

What is new is the surface area. The spec is meant to be writable by a domain expert, not just an engineer, in a domain-specific language. The audit surface is small enough to review against the policy.

Why the middle is harder than either end

At the dark end, you maintain the policy. The policy is the system.

At the light end, you maintain the people. The people are the system.

In the middle, you maintain the policy, you maintain the people, and you maintain the seam between them. The seam is what fails. The seam is what determines whether the factory runs at all.

A seam is a place where the human's authority and the pipeline's authority have to be reconciled. Promotion to production is a seam. Incident response is a seam. The decision to roll back is a seam. Each of those is a moment where the human's signature is the difference between shipping and stalling.

Each seam has a default. The default is what the pipeline does when no human acts. If the default is "ship" and the human does not act, the system has shipped. If the default is "do not ship," the system has stalled. The default has to be defensible. The default has to be chosen.

How to know which position you are in

One question. When the human does nothing, does the system ship or stall?

If the answer is ship, you are dark. If the answer is stall, you are light. If the answer is "it depends on which stage," you are in the middle. The middle is where you want to be, and the middle is the part you have to design on purpose.