A "dark factory" is a production facility that runs with the lights off. Nobody inside needs to see. That's the image everyone reaches for when they talk about where AI is heading. Every few months a new one gets announced and the coverage repeats itself. No workers. One unit per second. The future has arrived.
Honestly, that framing gets the interesting part backwards. The dark factory isn't proof that machines finally got good enough. Machines were good enough for a lot of this a decade ago. What changed is everything around the machines. And that surrounding list is the actual lesson, because it's also the checklist that tells you whether any process you run could survive being left alone.
I care about this for an unglamorous reason. I run automation that operates unattended, including the pipeline that publishes this site. The constraint has never once been whether the software could do the task. It's always been whether anything downstream could tell the difference between a good result and a confident, well-formatted, empty one.
What a dark factory actually is, and what the headline leaves out
A dark factory, or "lights-out" facility, is one where machines and software run production end to end with minimal human presence on site. Robots handle assembly, movement and packing. Scheduling, inspection and logistics run in software. These exist. They're mostly in electronics and high-volume component manufacturing. And yes, they are genuinely impressive.
Three things the announcement coverage consistently omits.
There are still people. The staff moved rather than disappeared. Out of the line and into supervision, maintenance, tooling, exception handling, and the changeovers that happen when the product changes. "Lights-out" describes the assembly floor during a run. It doesn't describe the building's headcount. Every real facility I've read about in detail has humans somewhere in the loop. Usually doing the hardest and least automatable work in the plant.
Headline production rates are peaks. "One unit per second" is a line-rate figure. Measured under ideal conditions on a running line. Sustained annual output is always materially lower, because real facilities have maintenance windows, changeovers, defect batches, supply gaps, and demand that isn't flat. That's true of every factory that has ever existed and it isn't a scandal. But a peak rate reported as a throughput rate is how a lot of automation gets oversold. The same trick shows up in software demos.
Nothing here generalises to messy work. These plants automate the most automatable process humans have ever designed. A fixed product. Identical components. A controlled environment. An immediately measurable pass/fail on each unit. That's not a stepping stone to autonomous everything. It's the extreme easy end of a spectrum, and the distance from there to "runs my business" is much larger than the coverage implies.
If you want the state of industrial automation from the people who actually count it rather than from the announcement cycle, the International Federation of Robotics publishes the primary numbers in its World Robotics reports. Its press releases and free downloads are the source most of the secondary coverage is loosely paraphrasing.
The five conditions that had to be true before the lights went off
This is the part worth stealing. Before anyone was willing to leave a factory unattended, five things had to be true. None of them is about how capable the robots are.
1. The input is constrained and identical every time. Components arrive in known orientations, in known quantities, within known tolerances. The system never has to decide what it's looking at. Where inputs vary, humans are still there.
2. The output is measured automatically, immediately, and by something other than the thing that produced it. Every unit gets checked by a separate system. The machine that built it doesn't get to grade its own work.
3. Failure is detectable by the process, not by a person noticing later. A jam, a tolerance drift, a missing part. Each produces a signal at the moment it happens. Nothing depends on somebody eventually spotting that the output looks wrong.
4. There is a stop condition. When something goes outside bounds, the line halts. It doesn't carry on producing defective units efficiently. The default on uncertainty is stop, not continue.
5. Somebody owns it. A named person is responsible for the line, gets woken up when it stops, and is accountable for what it produced. Autonomy didn't remove the owner. It removed the operator.
Look at that list again and notice what isn't on it. Intelligence. Not one of the five conditions is "the AI got smart enough". Four are about verification and one is about accountability. That's the actual precondition for autonomy, in a factory or anywhere else.
Score your own process against those five
Take any process you were thinking of handing over to AI and run it down the list. The result is usually clarifying and slightly deflating.
| Condition | Factory floor | Typical knowledge work |
|---|---|---|
| Constrained input | Yes, identical parts | Rarely. Every brief, email and dataset is a bit different |
| Independent measurement | Yes, separate inspection | Almost never. The output is judged by reading it |
| Failure detectable by the process | Yes, immediately | No. Wrong output looks exactly like right output |
| Stop condition | Yes, the line halts | Usually absent. It just continues |
| Named owner | Yes | Often nobody, once it is "automated" |
Most knowledge work fails on rows two and three. And it fails there regardless of how good the model is. That's the whole point. If nothing downstream can distinguish a correct output from a plausible one, then improving the model doesn't get you to autonomy. It gets you to failures that are harder to spot.
This isn't a theoretical concern. It's the most common way automation quietly stops working. The job runs, reports success, and produces nothing or nonsense, for weeks, because a green tick isn't a measurement. I've shipped that bug more than once, and the automation failure nobody catches is the long version of what it costs and how to build against it.
Autonomy is a supervision level, not a capability level
The usual three-stage model, assisted, automated, autonomous, is useful. But it's normally described as if it were a ladder of machine ability. It's more accurate, and far more actionable, to read it as a description of where the human sits.
Assisted. The system suggests. A human decides and is responsible for every output. Drafting, summarising, code suggestions. Errors are caught because a person reads everything before it matters.
Automated. The system executes inside tight rules. A human sets the rules and reviews in aggregate rather than per item. Sorting, classification, routine responses. Errors are caught by sampling and by exception reports. Which means the exception reports have to actually exist.
Autonomous. The system decides and acts within a goal. A human owns the outcome and is notified by exception only. Errors are caught by the verification you built in advance, or they aren't caught at all.
Moving a process up this ladder isn't a matter of the model becoming capable enough. It's a matter of you building the checking apparatus that each level requires. Skipping that construction doesn't leave you at the previous level. It puts you at the top level with none of the safeguards, which is strictly worse than staying at the bottom.
The framing that has stayed useful for me: you don't get autonomy by trusting the system more. You get it by needing to trust it less. The factory doesn't trust its robots. It inspects every unit.
Where this actually lands for a small team
The pattern repeats in software. And this is the part that matters if you aren't in manufacturing. Agents that plan and carry out multi-step tasks are the dark factory of knowledge work. Automation moving from a single task to a whole workflow.
The opportunity is real and it's asymmetric in favour of small teams. A person with well-built systems can now cover work that used to need a department. The constraint is no longer headcount or budget. It's how clearly you can specify what "done correctly" means. That's a skill, not a purchase.
But the bottleneck moves rather than disappearing. And it moves somewhere uncomfortable. When execution is cheap, the scarce inputs become deciding what should be built, and being able to tell whether the result is any good. Both are judgement, and neither is automatable by the thing whose output you are judging. That's the argument in the skills that actually matter in the age of AI. The factory version of it is that the humans who remained on site are the ones doing exception handling. The work that only shows up when something unexpected happens.
There's also a failure mode specific to putting a language model in the loop. It's the exact inverse of the factory's. A jammed robot stops. A model that has been given nothing useful produces a fluent, confident, well-structured answer about nothing, and passes every check that only asks "did it return something?". Understanding why it does that isn't optional if you're going to run one unattended. Why ChatGPT gives wrong answers covers the mechanism, and the practical rule that falls out of it is worth stating plainly:
Let the model do the judgement. Let deterministic code do the checking. Never let the model grade its own work.
That's condition two from the factory list, translated. It's also the single design decision that has saved me the most trouble.
What to actually do about it
Four things, roughly in order of how much they pay.
1. Automate your own repetitive work first, and start with the verification. Pick something you repeat weekly. Before you build the automation, write down how you'll know next month whether it's still working. If you can't answer that, you aren't ready to automate it. You're ready to do it manually and pay attention. How to automate your work with AI is the practical starting point, including the part where the maintenance cost, not the build cost, decides whether a workflow was ever worth having.
2. Learn to direct rather than to compete. The valuable skill is briefing, reviewing and combining. Not producing faster. How to actually use ChatGPT and Claude for real work is what that looks like day to day, and the reviewing half is the half people skip.
3. Build the stop condition before you build the capability. Decide in advance what output means "halt and tell a human". A workflow with no defined halt state will run through every edge case it meets, confidently, forever.
4. Put your name on it. Autonomy removes the operator, not the owner. If nobody can answer "who finds out when this stops working?", the honest answer is nobody, and you've built a liability with a dashboard. Formal risk frameworks say the same thing at greater length. NIST's AI Risk Management Framework is organised around exactly this. Mapping and measuring a system's behaviour and assigning accountability, rather than around how capable the model is.
Does this take jobs?
It moves them. And it moves them in a direction that is legible from the factory example rather than from speculation.
The line workers didn't become unnecessary and simultaneously stay in the same job. The roles that grew were the ones adjacent to the machines. Maintenance. Tooling. Systems integration. Quality engineering. Exception handling. The roles that shrank were the ones consisting of a repeated physical action with a measurable output. Which is to say, precisely the roles that satisfied the five conditions.
The knowledge-work version follows the same rule, and you can apply it yourself: the more your work resembles a constrained input producing an immediately checkable output, the sooner it changes. The more it involves ambiguous inputs, contested definitions of "correct", relationships, or accountability for a decision, the longer it holds. Not because it's impossible to automate, but because nobody can build condition two around it.
That's a more useful thing to plan against than a headline about robots. Will AI take my job works through what to do with the answer. The historically consistent pattern is that automation waves reward the people who move toward the new tools early and penalise those who wait to be told. There's nothing in this one that suggests otherwise.
The mistakes I see most
Reading a demo as a throughput figure. The peak rate under ideal conditions isn't the sustained rate, in a factory or a product demo. Ask what it does over a month, on real inputs, including the bad ones.
Automating capability without automating verification. The most expensive version of this error. You now produce ten times as much output and have exactly the same ability to check it. Which is to say you have industrialised whatever mistake you were already making.
Assuming a green status means the work happened. The tool reports that it executed, not that the outcome is correct. Those are different claims and the gap between them is where unattended systems fail.
Treating "autonomous" as a purchase. It's a property of the system you build around a tool, not a feature of the tool. Nobody sells it to you.
Removing the owner along with the operator. Unowned automation is where silent failure lives, because everybody assumes somebody else would have noticed.
Concluding that judgement no longer matters. Cheap execution raises the value of deciding what to execute. The factory didn't eliminate its engineers. It eliminated the repetition around them.
FAQs
Are fully autonomous factories real, or is it marketing?
Both, in different proportions than the headlines suggest. Lights-out production runs are genuinely real in electronics and high-volume component manufacturing, and they are a real engineering achievement. What's marketing is the implication of zero humans and the use of peak line rates as though they were sustained output. The accurate version, where machines run production while a smaller specialist staff handles supervision, maintenance and exceptions, is less dramatic and considerably more useful to reason from.
What is the difference between automation and autonomy?
Automation executes a defined procedure. Autonomy pursues a goal and decides the procedure itself. The practical difference isn't the software, it's where the human sits. Automation needs someone to have specified every step. Autonomy needs someone to have specified what a correct outcome looks like and what should happen when it isn't achieved. That second specification is the harder one, and it's the one people skip.
Can I make my own work "lights-out"?
Parts of it. The five conditions will tell you which parts far more reliably than intuition will. Anything with a stable input, a checkable output and an obvious failure signal is a candidate today. Anything where you would only notice a bad result by reading it carefully isn't. Regardless of how impressive the tool is. Not until you've built something that does the reading.
Isn't the AI good enough now that verification matters less?
It's the reverse. As output quality rises, errors stop looking like errors. A bad result now arrives well-formatted, plausible and internally consistent, so the cheap human check (does this look wrong?) stops working precisely when you start relying on it. Higher capability raises the cost of each undetected mistake and lowers your odds of detecting it by glancing. Verification gets more important as the model improves, not less.
What should a small business actually do this quarter?
One process, end to end, with the checking built first. Pick something repetitive whose failure you would notice within a week. Write down how you'll verify it monthly. Automate it. Put a name against it. That's worth more than a strategy covering everything you might automate later, and it teaches you the thing you actually need. Which isn't how to use the tool, but how to tell whether it worked. Marketing automation is a reasonable place to find the first candidate if nothing obvious comes to mind.
Key takeaways
- Dark factories are real, and they're the easy end of the spectrum: fixed product, identical inputs, immediate pass/fail on every unit.
- The staff moved rather than vanished, into supervision, maintenance and exception handling. "Lights-out" describes the line, not the payroll.
- Headline rates are peak line rates. Sustained output is always lower, in factories and in demos.
- Five conditions had to be true before the lights went off, and four of them are about verification, not intelligence.
- Most knowledge work fails on "measured independently" and "failure detectable by the process". A better model doesn't fix either.
- Autonomy is a supervision level, not a capability level. You reach it by needing to trust the system less, not more.
- Let the model do the judgement and deterministic code do the checking. Never let it grade its own work.
- Build the stop condition before the capability. A workflow with no halt state runs through every edge case forever.
- Automation removes the operator, never the owner. Put a name on anything that runs unattended.
- The closer your work is to a constrained input with a checkable output, the sooner it changes. That's a better planning tool than any headline.
Top comments (0)