The difference between the two is not how much code agents write. It’s who verifies it.
Where the Terms Come From
“Dark factory” is borrowed from manufacturing. Lights-out factories first ran in Japan in the 1980s, pioneered by Fanuc, a robotics company famous for using robots to build more robots. Nobody needed to turn the lights on because nobody was on the floor. A “lights-on factory” is the implied contrast: a plant that still needs people physically present to run it, even a highly automated one.
Applied to software, the two terms describe the same spectrum I’ve written about in The Five Levels Are Gated by Verification. Dan Shapiro’s ladder runs from manual coding to Level 5, “the dark factory: specs go in, software comes out, and humans are neither needed nor welcome on the floor.” Everything below that, however much of the coding is automated, is still a lights-on operation, because a human is still standing at the review gate.
The Lights-On Factory
A lights-on factory automates production heavily but keeps a human as the final check before code ships. Agents write the diff. A person, or a process that encodes a person’s judgment (a required approval, a manual merge), decides whether it’s correct.
Stripe is the concrete example worth anchoring on: north of a 1000 AI-generated pull requests a week, and every single one still gets an engineer’s eyes before merge. That’s an extremely automated factory. It is not a dark one. The lights are still on because review is still the gate.
Most teams using coding agents today, including mine on most repos, live here. “Your life is diffs,” as Shapiro puts it: you stopped typing code, but you didn’t stop being the thing that decides whether code is right.
The Dark Factory
A dark factory removes the human from that gate entirely, not by skipping verification but by replacing it. The Encyclopedia of Agentic Coding Patterns states the definition bluntly: code must not be written by humans, and code must not be reviewed by humans. In their place sits an automated verification stack, property-based tests, simulation environments, a second agent whose only job is adversarial critique, and production telemetry that catches what pre-deploy checks miss. Humans don’t disappear. They move entirely upstream, into specs, policy, and stage-gate design, and never touch an individual diff.
This is exactly Level 5 on the ladder, and it is worth noticing how far it is from Level 4. Level 4, “you write specs, leave for 12 hours, and check whether the tests pass,” still has you checking. Level 5 removes the checking, not just the writing.
The Axis That Actually Matters
It’s tempting to read “dark factory” as a claim about model intelligence: a smart enough agent gets to run unsupervised. That reading is wrong, and the manufacturing history proves it. Industrial robots existed for decades before lights-out factories did. The robots weren’t the bottleneck. The gap was metrology: automated measurement had to get good enough that a human inspector added zero information before the lights could go off.
Software’s gap is identical. Plenty of coding agents today are already capable of Level 5 behavior in narrow domains. What’s missing almost everywhere is the verification stack dense enough to make human review statistically redundant. That’s the same conclusion the verification-ladder note reaches from the other direction: your autonomy level is a property of the repository’s test suite and type coverage, not a property of the model you’re renting that week. Dark factory is a claim about your oracle, not about your agent.
Full Dark Is Mostly Vapor Right Now
Treat most of the current “dark factory” writing as marketing for an aspiration rather than a report from production. One of the more honest pieces I found in researching this called the current state “experimental teams,” not proven deployments. Even the enterprise examples cited (large migrations, agent-driven PR generation at scale) describe agents producing at dark-factory volume while humans still gate the output, which is a lights-on factory running very fast, not a dark one.
The prerequisites for a genuine Level 5 are steep enough that this isn’t surprising: a mature agentic harness, codified specs and scenario descriptions, test oracles strong enough that a weak one doesn’t just accelerate shipping defects, reliable simulation, and telemetry that catches silent failures in production. Skip any one of those and “dark” just means “unreviewed,” which is a different and much worse thing.
The Useful Reframe
The binary framing, is your company a lights-on factory or a dark one, is the wrong question, because almost nobody will ever flip that switch company-wide. Blast radius varies wildly by change type, and no verification stack is uniformly strong across an entire codebase.
The better question is per-category: which specific classes of change have I built enough metrology around that I can move them from lights-on to dark, one at a time? This is exactly the “holiday mode” split I laid out in Buy Orchestration, Own Semantics. Dependency bumps behind test gates, draft PRs, backlog triage, spec drafting from known templates: these can already run dark, unreviewed, because the blast radius is low and the oracle is strong. Merges to main, production deploys, schema mutations, anything touching billing or auth: these stay lights-on indefinitely, because the cost of a false negative in the verifier is catastrophic and no test suite gives you zero-information confidence there yet.
Dark factory, in other words, isn’t a destination. It’s a migration you run category by category, gated the same way every level transition on Shapiro’s ladder is gated: by how cheaply and reliably your environment can tell an agent it’s wrong. Build that oracle for one class of change, and that class goes dark. The rest of the factory keeps its lights on until you’ve earned the right to turn them off.
Where I Land
I’ll disclose my own bet, the same way Shapiro discloses his: I prefer lights-on, and not just as a temporary concession until the verification stack catches up. Even in categories where I could plausibly build an oracle strong enough to go dark, I’m not in a hurry to. The gate is where my judgment compounds. Handing it to an automated verifier, even a good one, is a bet that the oracle needs zero information from me, and I’d rather keep earning that information than assume it away.
That preference is why I built diff-core. Agents now open 50+ file PRs as a matter of course, and a flat, alphabetically ordered diff cannot be reviewed at that size. It just gets skimmed, which quietly turns a lights-on pipeline into an unreviewed one wearing a review’s clothes. Diffcore builds a symbol graph from tree-sitter ASTs, clusters the changed files into flow groups by data-flow reachability, and ranks them by a risk score, so I read the diff in the order the code actually executes instead of the order git happened to list the files. An optional LLM pass can refine the grouping, but it never makes the call. It hands me a better-ordered diff; I still decide whether it’s correct.
That’s the whole point of the tool: not to route around the human gate, but to make the human gate afford agent-scale throughput. I’m not trying to make myself redundant at the point of review. I’m trying to make sure that when I stand at the gate, I’m actually able to see what’s coming through it.
Related
- The Five Levels Are Gated by Verification, Not Intelligence
- Buy Orchestration, Own Semantics
- Building the Factory
- The Verification Ladder
- Autonomous Loops Need a Scoring Function
- Monte Carlo Quality Assurance
Sources
- Dan Shapiro – The Five Levels: From Spicy Autocomplete to the Software Factory
- Dark Factory – Encyclopedia of Agentic Coding Patterns
- Dark software factories and the future of autonomous software delivery (i-scoop)
- What Is a Dark Factory? (MindStudio)
- The Dark Software Factory (Dootrix)
- Built by Agents, Tested by Agents, Trusted by Whom? (Stanford CodeX)
