In January 2026, Dan Shapiro published a five-level model for AI-assisted software development, borrowing the autonomy levels used for self-driving cars. He called Level 5 The Dark Factory.
The name comes from manufacturing. Japanese robotics company FANUC pursued highly automated production beginning in the early 1980s and, by the early 2000s, reported robot cells capable of 720 hours of continuous unmanned operation. That is the origin of the "lights-out" image: a factory able to keep producing without people continuously on the floor.
Shapiro argued that software development was approaching its own lights-out model.
The five levels
The framework, condensed:
Level 0, Manual. You write code by hand. AI is absent or sits outside the development workflow.
Level 1, Task delegation. You ask AI to write a unit test, generate a function, scaffold a component. You're driving; AI handles discrete tasks on command.
Level 2, Pair programming. AI is your copilot. You work together in real time. You guide direction, AI generates code, you iterate together. Shapiro estimates 90% of developers who call themselves "AI-native" are operating here.
Level 3, Code review. The dynamic flips. AI writes the code; you review it. Your job becomes reading diffs, approving pull requests, and catching mistakes. You're a manager now, not a maker.
Level 4, Spec-driven development. You write detailed specifications covering what the software should do, how it should behave, and what the acceptance criteria are, then hand them to AI agents. Hours later, you check the results against your specs and tests. You're a product manager, not a programmer.
Level 5, The Dark Factory. Specs go in. Software comes out. The human role is defining what to build and why. The how is entirely autonomous. Like the FANUC factory: dark, because humans are neither needed nor present in the production process.
This isn't theoretical anymore
Two weeks after Shapiro published his framework, StrongDM, an infrastructure access company, publicly described a small internal AI team that had been operating a dark factory since mid-2025 as a deliberately constrained experiment. Three engineers. No human-written code. No human code review. Their internal charter has two non-negotiable rules:
- Code must not be written by humans.
- Code must not be reviewed by humans.
Engineers write detailed prose specifications covering behavior, edge cases, error handling, and acceptance criteria. AI agents produce the code. Other agents review and test it. When a check fails, the agents try again. Humans remain responsible for the specification and validation but do not write or review the implementation.
StrongDM's own automation target is at least $1,000 in daily token spend per human engineer. That is the company's metric, not a proven industry benchmark.
Before the company identified itself, Simon Willison wrote that the team's system "looked very convincing". After visiting StrongDM, he described a process built around detailed specifications and external verification. The humans define intent and measure outcomes.
Why "dark factory" is catching on
There are a lot of terms floating around for what's happening in AI-assisted development. "Agentic coding" is the category term, the one Anthropic, OpenAI, Google, and the analyst firms use. "Vibe coding" captured the casual end of the spectrum. But "dark factory" fills a specific gap: it names the extreme, the endgame, the fully autonomous production line.
It's catching on because it's visceral. "Agentic development" is accurate but clinical. "Dark factory" makes you feel the weight of what's changing. It carries the industrial metaphor (assembly lines, factories, production) and applies it to something that has historically been considered a craft.
Jason Calacanis recently amplified the concept to his audience with the phrases "lights out startup" and "no humans touch the code". His framing pushes the question to its provocative extreme: how much of software production can operate without routine human handling?
StrongDM shows that a narrow, deliberately constrained version can run now. It does not prove the general case.
What this means for software teams and agencies
Most teams still use AI as a pair programmer or let it draft code for human review. Levels 4 and 5 require executable specifications, independent verification, bounded permissions, rollback, and clear human ownership. A better model does not supply those controls.
In a dark factory, the bottleneck moves from coding to specification.
CI/CD executes predefined steps. A dark factory lets agents choose and repeat steps within bounded intent.
Vague requirements leave decisions for the agent to invent. Detailed, testable specifications reduce that ambiguity, but they can still specify the wrong product. As code gets cheaper, knowing what to build and defining evidence for "done" matter more.
For agencies, the commercial unit can move from developer hours to verified outcomes. The claim that a small factory team can reliably match a much larger traditional team remains unproven.
Human expertise moves to architecture, security, product judgment, test design, and incident ownership. Repeated implementation work, such as standard CRUD endpoints and boilerplate authentication flows, is the easier part to delegate.
The risks nobody should ignore
Quality at scale is unproven. StrongDM's experiment is limited in scope and duration. In CodeRabbit's vendor-authored analysis of 470 open-source pull requests, AI-authored pull requests averaged 10.83 issues per pull request versus 6.45 for human-authored pull requests, about 1.7 times as many. The sample, authorship classification, and vendor interest limit how broadly that result should be applied, but it reinforces the need for independent testing and validation.
Specification debt replaces technical debt. If your specs are wrong, your factory produces the wrong thing faster and more confidently than a human team would. Bad specs at scale could be worse than bad code at scale, because the feedback loop is different. The code "works" according to its tests, but the tests were generated from flawed specs.
The "dark" metaphor cuts both ways. For enterprise buyers who need to trust that their software is secure, compliant, and maintainable, "no human ever looked at this code" can be terrifying rather than impressive. How do you sell confidence in a process that's explicitly designed to exclude human oversight from the production layer?
The public sample is one. The term was named less than a month ago, and StrongDM is its only major public implementation. One case cannot establish an adoption timeline.
Where this is heading
The direction is visible even if the pace is debatable. Models and agent tooling are improving, but the economics remain unproven. StrongDM publishes its token-spend target, not a comparison of durable output after validation, retries, maintenance, incidents, and human attention.
The factory model is a better fit for repeated, well-understood work than for novel architectures or exploratory research. That identifies a place to test the model. It does not tell us how much software work will fit it.
Developers become more valuable when they can set constraints, design tests that catch real failures, review risk, and make architectural decisions. Translating already-clear requirements into code is the part agents target first.
Agencies can sell operated, verified delivery instead of developer hours. The hard part is earning trust with evidence, not claiming that a smaller team can produce more code.
The lights are going out. The only questions are how fast, and who's ready.