"AI dark factory" has become shorthand for a future where AI agents build software with little or no human intervention. But the idea comes from manufacturing, and the history might be more useful than the metaphor.

A dark factory, also called lights-out manufacturing, is a highly automated production facility designed to operate for extended periods without people on the factory floor. An AI dark factory applies the same idea to software: a defined class of development work running autonomously through implementation, verification, and delivery, with humans defining goals and constraints, setting the process, and handling exceptions rather than supervising every step.

The important lesson from manufacturing is not that robots eventually became smart enough to replace people. It is that engineers redesigned the production process so fewer steps required human judgement.

That distinction matters for software. The path to greater agent autonomy depends as much on reproducible environments, machine-checkable verification, instrumentation, and bounded workflow as it does on better models.

What makes a dark factory possible?

Lights-out manufacturing is not new. Manufacturers have spent decades automating production lines that can operate for long periods with few or no people on the floor.

FANUC is one of the best-known examples. At a factory near Mount Fuji, robots have been documented building other robots at roughly 50 units per 24-hour shift and running unattended for up to 30 days. FANUC has even described turning off the heating and air conditioning when nobody is on the floor.

The model has spread beyond robotics. Semiconductor manufacturer ASE now reports operating 56 lights-out factories. The idea itself is abundant in science fiction. In Star Wars, Episode II there is an underground automatic droid factory and Philip K. Dick imagined an autonomous factory in his 1955 short story Autofac.

What do engineers have to do differently before unattended operation become reliable?

Three requirements stand out: standardized inputs, deterministic verification, and continuous instrumentation.

Standardized inputs

A lights-out production line cannot depend on workers constantly compensating for unpredictable inputs. In non-software situations one can imagine that materials need to arrive in expected forms, orientations, and tolerances. In other words, enormous engineering goes into making the inputs boring. Variability that humans previously absorb through judgment has to be constrained or turned into an explicit exception path.

Deterministic verification

The more of the process that can be verified against explicit tolerances and machine-readable criteria, the less it depends on someone standing beside the line deciding whether the output “looks right”. Where judgment is still required, a human must stay in the process.

Continuous instrumentation

When a production line runs unattended for 30 days, the only thing you have is a record. Every machine must be able to report its state continuously, and a deviation should trigger a stop rather than a slow drift into scrap. You do not want to find out on day 30 by looking at the output that something went wrong. You want to find out on minute six by reading the stream. The process has to get redesigned around the automation.

What does an AI dark factory look like for software development?

The useful translation is not “software development without engineers”. It is a defined class of software work that can move through implementation and verification without requiring human judgement at every step.

Not all work. A class of work. For example, FANUC's dark factory does not build every product FANUC sells. They automate processes engineered to operate reliably within known boundaries. Software autonomy should be approached the same way.

Standardized inputs become reproducible environments and bounded tasks. An agent that has to guess how to build the service, discover undocumented dependencies, or interpret a ticket saying "login is broken sometimes," is working with highly variable input. Reproducible environments, repository instructions, explicit constraints, and well-scoped tasks reduce that variability.

Deterministic verification becomes executable acceptance criteria. Tests, builds, type checks, linters, static analysis, security scans, and other deterministic checks give an agent machine-readable evidence about whether its work satisfies known requirements. The more important correctness depends on subjective judgment, the harder the workflow is to run unattended. That is why the first candidates for greater autonomy tend to be narrow, repeatable workflows with strong verification rather than ambiguous product development.

Continuous instrumentation becomes an execution record. This is the requirement that gets skipped most often, because it is the least exciting.

If an agent runs unattended, the resulting code is only part of the evidence you need. Teams also need an execution record that can show:

• What the agent received

• Which model and agent handled it

• Which tools were called

• What arguments were supplied

• What the environment returned

• What files or systems changed

• Which validation checks ran

• Whether a policy, hook, or human rejected an action

• Where the workflow paused, retried, failed, or completed

Without that, you are not running lights-out. You are running blind.

A practical maturity model for autonomous software development

Teams do not move directly from AI assistance to lights-out development. A useful way to think about the progression is:

1. Assisted: A human drives the workflow while the agent suggests or performs bounded actions. Autocomplete and conversational coding tools fit here.

2. Supervised autonomy: The agent drives a task while a human monitors progress and intervenes when needed. This increases delegation but still ties agent throughput to human attention.

3. Gated autonomy: The agent runs independently until a defined gate, usually a pull request. Humans evaluate the result rather than supervising every action.

4. Narrow lights-out workflows: A specific, bounded class of work can run end to end without a human approval gate because its inputs, permissions, verification, and failure handling are sufficiently constrained.

5. Broad lights-out software development: Large portions of the SDLC operate without routine human gates. Humans define goals, architecture, policies, and exception handling rather than reviewing individual changes.

Level 5 remains an aspirational architecture for most engineering organizations. The useful near-term question is not when all software development becomes autonomous. It is which workflows can responsibly move from level 2 to level 3, or from level 3 to level 4.

What is the difference between an AI dark factory and AI-assisted development?

The difference is where human judgment sits in the workflow.

In AI-assisted development, a developer remains inside the implementation loop: prompting the agent, reviewing intermediate work, correcting mistakes, and deciding what happens next.

In a more autonomous workflow, the agent can complete a bounded task independently and the human moves to a defined review gate.

In a narrow lights-out workflow, even that routine gate can be automated when correctness can be established through sufficiently reliable machine-checkable criteria and the consequences of failure are appropriately bounded. The progression is therefore not simply “more AI.” It is a shift in where human judgment is required.

How to start building toward a software dark factory

1. Start with one repeatable job. Don’t try to automate “software development”. Pick something narrow that happens often and follows roughly the same process every time.

2. Make the inputs boring. Give the agent a reproducible environment, a clear task, and the context it needs. The less it has to guess, the better.

3. Make success easy to check. Before you take away the review step, make sure tests, builds, linters, policies, or other checks can tell you whether the work actually passed.

4. Limit what can go wrong. Give the agent access to the tools, repos, credentials, and systems it needs for that job, and not much else.

5. Keep a record of what happened. If nobody is watching the agent work, you need to be able to go back and see what it did, what tools it used, what changed, and where something went wrong.

6. Move the human to the end of the line. Start by letting the agent work on its own and having someone review the result. Only remove that final check when you have enough confidence in the verification and the consequences of a mistake are contained.

7. Then do it again. Once one workflow can run reliably without constant supervision, pick the next one. You don’t turn on “autonomy” across engineering all at once. You earn it workflow by workflow.

That is how a manufacturing engineer would approach lights-out production: one process at a time. "We are building an AI dark factory" is not an executable roadmap. “We are making dependency upgrades reproducible, machine-verifiable, bounded, and observable enough to run unattended” is.

What does OpenHands have to do with the dark factory?

The OpenHands view is that greater agent autonomy requires more than a better coding model. It requires infrastructure around the agent that makes unattended work bounded, observable, and repeatable.

OpenHands provides isolated execution environments for software-engineering agents and supports repeatable automations for bounded workflows while keeping model, cloud, and other parts interchangeable. Agent Canvas gives developers a place to run and review those workflows, while OpenHands Enterprise adds organization-level controls for teams scaling automated agents.

Just as important is the execution record. OpenHands maintains an append-only event history of agent activity so supported workflows can distinguish the task the agent received, tool calls and arguments, environment responses, validation activity, interventions, and workflow state transitions.

That does not make every software task safe to run without review. It gives teams infrastructure for deciding which workflows can move from continuous human supervision toward defined gates and, eventually, narrow forms of unattended execution.

The goal is not to remove engineers. It is to make human judgment intentional: decide where it is essential, engineer the rest of the process so it is not required, and preserve enough evidence to know what happened when nobody was watching.

With OpenHands teams can plug in their existing tools into a ready built automated factory for software, and it’s open source so it’s truly open for teams to extend is in ways unique to their factories.

Ready to try putting a workflow into dark factory mode? Try Agent Canvas and start with one repeatable job.

npm install -g @openhands/agent-canvas

Frequently Asked Questions

What is a dark factory?

A dark factory, or lights-out factory, is a highly automated manufacturing facility designed to operate for extended periods without people on the production floor. The term comes from the idea that a factory without workers does not need normal lighting.

What is an AI dark factory?

An AI dark factory applies the lights-out manufacturing concept to software development. AI agents execute a defined class of software work with little or no human intervention in the inner loop, while specifications, automated verification, permissions, observability, and exception handling constrain the process.

Does an AI dark factory mean replacing software engineers?

Not necessarily. A more useful interpretation is that engineers move out of repetitive execution and continuous supervision and into defining requirements, architecture, verification, policies, and exception handling. Human judgment remains important where correctness cannot be reliably established automatically.

What is required for autonomous software development?

Increasing autonomy requires more than a capable coding model. The surrounding system needs well-defined inputs, reproducible execution environments, bounded permissions, machine-checkable verification, observable execution, failure handling, and clear rules for when humans must intervene.