framework
Dark Factories

The Dark Factory

A software development operation where code is written and reviewed entirely by AI agents, with no human involvement in implementation. Named by analogy to manufacturing's "lights-out factories" — facilities automated enough to run in the dark. Currently demonstrated in production by StrongDM.

The dark factory is software development’s equivalent of manufacturing’s lights-out factory — a fully automated operation where no human need be present during production.

In manufacturing, lights-out factories run entirely in the dark because there’s no human workforce to illuminate them for. In software, the dark factory runs without humans writing or reviewing code because implementation is fully automated.

The Definition

Dan Shapiro’s Level 5: “The dark factory. This is effectively a black box that turns specs into software.”

StrongDM’s operational rule: “Code must not be written by humans. Code must not be even reviewed by humans.”

What the Dark Factory Is Not

It’s not:

  • Vibe coding: Casual AI assistance, prompting for suggestions, still editing manually
  • Copilot usage: Inline suggestions, tab completion, Level 0–1
  • “AI-assisted” development: Level 2–3, where humans review code output
  • Fully autonomous AI: The humans still exist — they write specs and evaluate outcomes

What makes it a factory:

  • Specs go in
  • Software comes out
  • No human touches the production line

The Factory vs. The Artisan

Traditional software development is artisan work: individual engineers craft solutions by hand, making thousands of micro-decisions that encode their judgment and knowledge.

The dark factory inverts this. Engineers are no longer artisans — they’re factory designers. Their job is to:

  1. Understand the problem deeply enough to specify it
  2. Design evaluation systems (scenarios/tests) robust enough to catch failures
  3. Maintain the factory (agents, pipelines, simulation environments)

The implementation judgment is outsourced to the agent. The judgment that remains is product judgment, specification quality, and outcome evaluation.

Prerequisites for a Working Dark Factory

  1. Specification discipline: Can you articulate requirements clearly enough for an agent to implement them without clarification?
  2. External test methodology: Do your tests prevent the agent from gaming them? Are they stored outside the codebase?
  3. Simulation environment: Can you safely test code that touches external services?
  4. Greenfield (or documented brownfield): The specification must exist. Legacy systems without documented behavior cannot be dark-factored.
  5. Compute budget: ~$1,000/engineer/day is the reported number for StrongDM’s team

The Brownfield Problem

The video quote: “The specifications for that do not exist.”

Legacy systems accumulated their behavior over years of patches. The system is the specification — the only way to know what it does is to run it. You cannot write a spec for behavior that was never written down.

Before dark-factoring a brownfield system, you have to:

  1. Reverse-engineer the implicit specifications from the running code
  2. Document them explicitly
  3. Build test coverage that captures the implicit behaviors
  4. Then you can start factoring in agents

This is unglamorous, expensive work. It’s also the only path.

The Demand-Side Argument

Software demand has never been constrained by software quality — it’s been constrained by cost and velocity. Every time the cost of software dropped (from mainframes to minicomputers to PCs to the web to SaaS), the total amount of software in the world exploded.

The dark factory doesn’t end software demand. It expands it. When implementation costs $0, the number of software problems worth solving expands dramatically.