Light and dark

Why the word is “dark”, where the metaphor comes from, and what the autonomy ladder is actually measuring.

The term is a precise borrowing.

In manufacturing, a lights-out plant runs with the lights physically switched off, because only machines are on the floor and machines do not need to see. FANUC has run that way since 2001 Reported; Xiaomi opened a comparable plant in 2024. The darkness is a statement about who is present, not about sophistication.

Carry that across and the software floor is the diff. A dark software factory ships code no human has read, verified only by other machines. That is all the word means: a physical claim about where reading happens. In a dark factory, nowhere.

A lit factory is the same pipeline with the lights left on where judgment lives. Agents still do most of the building. But a person reads what comes out before it ships — and, more importantly, the lit version moves judgment upstream, to the product decision, the design, the architecture, before an agent starts a loop at all. An hour spent on a two-hundred-line plan replaces a long crawl through two thousand lines of generated code trying to reconstruct what the decision even was.

The ladder

The vocabulary crystallised in January 2026, when Dan Shapiro laid out five levels modelled on the driving-automation levels. Primary The analogy holds better than most analogies of its kind, because it measures the same thing the driving levels measure: not how good the machine is, but how much attention the human is obliged to keep.

L0 Manual You write the code. AI is a better search box.
L1 Spicy autocomplete Completion inside the editor, line by line.
L2 Pairing You and the model take turns. Where most AI-native developers actually live.
L3 Full-time reviewer The model writes most of it; your day is reading diffs.
L4 Specifier You write specs and check tests. Closer to engineering manager than author.
L5 Dark factory Specs go in, software comes out, and nobody reads what happened in between.

a human still reads the output nobody reads the output

Fig. 2.1The ladder as published by Dan Shapiro on 2026-01-23 Primary, modelled on the driving-automation levels. Its author placed himself at L4 and noted that only a handful of small teams had reached L5.

Two things about this ladder are worth more than the ladder itself.

The first is that the levels are not a maturity model. There is no law that says a good engineering organisation ends up at L5, any more than there is a law that says every road should be driven by a machine. The levels describe an arrangement, and the right arrangement depends on what a wrong answer costs you.

The second is that the jump from L4 to L5 is not a jump in capability. It is the removal of a step. Everything at L4 can already be done by the machines; what L5 changes is that nobody looks. That is why going dark feels so good at first — you are not adding anything, you are deleting the thing that was in everyone’s way.

Where the field actually sits

Nearly every production deployment described publicly in the first half of 2026 is L3 or L4. The autonomy is in execution, not in approval.

Stripe’s agents merge 1,300+ PRs merged per week, zero human-written code, all human-reviewed as of 2026-02-20 Primary

and the framing in their own write-up is careful about it: from Slack message to merged pull request no human touches a keyboard, and engineers review everything before it ships. Spotify’s migration fleet merges ~1,000 PRs merged every 10 days as of 2026-03 Reported

with CI verification and a human at the merge. Cursor reports 35% of internally merged PRs created by cloud agents as of 2026-04 Vendor

and describes review as the remaining bottleneck.

The well-documented L5 case is essentially one company. StrongDM’s factory runs on two stated rules — code must not be written by humans, and code must not be reviewed by humans. Understand why that is viable there before concluding it is viable anywhere. It is viable not because the model is trusted but because of machinery: scenario tests held outside the codebase like a holdout set so the agents cannot overfit them, behavioural clones of third-party services so thousands of scenarios can run in an hour, and a probabilistic “satisfaction” score in place of a boolean pass. Plus a token bill of ≥ $1,000/day/engineer stated token-spend benchmark for running this way as of 2026-02 Primary

That last figure is the one to keep in mind when someone tells you the dark factory is the inevitable future. It may well be — but the published route to it currently runs through a level of investment that answers the question “does this generalise?” with “not yet, and not cheaply”.

From the floor

The four factories on this machine all sit at L4, and not because L5 was too hard to reach. They sit there because of a decision made when the second one was designed: the deciding axis between factories is not the stack, it is what the checker can be.

The first factory drives software, where a task’s definition of done is machine-decidable — so it hangs on a green gate and a Cucumber suite. The next three drive demos, novels and websites, where “done” is mostly editorial and visual. Forcing those through a green gate produces ceremony: Gherkin that gates nothing. So they got a different arrangement — a deterministic floor, an independent judge over the rendered output, capped rounds, then a person.

The level each factory sits at was never chosen as an ambition. It fell out of asking what could be checked.

Evidence: website-factory/specs/design.md, § “Why a separate plugin”

The word is not an insult

The metaphor invites a sneer that is not in it. A dark factory is not a careless factory. StrongDM’s is one of the more rigorous engineering arrangements described publicly this year — the rigour just lives in machinery rather than in eyes. The question this manual keeps returning to is not whether darkness is responsible. It is whether your particular loop has an oracle good enough to earn it, which is Station 6.