In manufacturing there’s a name for the most automated plants on earth: a dark factory. The machines run so completely on their own that nobody needs to be on the floor — and if no human is there to see by, you don’t pay to light the room. Lights-out. It’s an unsettling image and an aspirational one at the same time, depending on where you’re standing.
Software is getting its own version of that idea, and it’s worth understanding before the phrase is everywhere. Because the interesting question was never “can the machines run the whole thing in the dark.” It’s “where do you choose to leave the lights on” — and that turns out to be the most important engineering decision of the next few years.
Faster typing was never the prize
For a couple of years the story about AI and software was about speed: the model writes the code faster, so the engineer ships faster. True, and useful, and not the point.
Making one person type faster is a local optimization. The work of building software is much bigger than typing. A change starts as a signal from the outside world — a bug report, a line in a support thread, a customer asking for something, a business deciding to go a new direction. That signal has to be understood, triaged, turned into a plan, built, tested, reviewed, secured, shipped, and then watched in the wild. And watching it in the wild produces new signals, which start the whole thing over.
Speeding up the “build” step while every other step stays manual is like installing a faster machine in the middle of an assembly line where humans still carry the parts to it by hand. The line doesn’t get much faster. The bottleneck just moves.
The bigger prize is the software factory: the entire loop — signal in, shipped software out, new signals back — instrumented so that the machine handles the legwork end to end, and the system gets better at it over time by watching itself.
The loop: signal → ship → signal
Here’s the whole thing in one shape. Read it as a circle, not a line — the last step feeds the first.
┌─────────────────────────────────────────────┐
│ │
▼ │
signals in ──▶ triage ──▶ plan ──▶ build ──▶ test │
(bugs, feedback, │ │
requests, metrics) ▼ │
review │
│ │
┌──────────── monitor ◀── ship ◀── secure ◀─┘ │
│ │
└──────── (monitoring makes new signals) ─────┘Almost everyone has automated one box on this diagram. Continuous integration automates “test.” A deploy pipeline automates “ship.” A coding agent automates “build.” What almost nobody has done yet is instrument the whole loop so it runs as one connected system — where a monitoring alert becomes a triaged ticket becomes a planned change becomes a reviewed pull request without a human relaying it between each stage by hand.
That’s the leap. Not a better tool for one box, but a single system that owns the circle. We’re early, but once the pieces exist, this assembles fast.
You’ve already met the unit: the agent
A factory is made of identical small units doing repeatable work. The unit here isn’t a model that answers questions. It’s an agent — the act-observe-decide loop we cover in what is an AI agent. An agent takes a step, looks at the real result, decides the next step, and repeats until the job is done.
That’s the brick. A single agent can own a single box on the diagram: an agent that triages incoming issues, an agent that drafts the fix, an agent that reviews it. A software factory is what you get when you wire those agents into the loop and let the output of one become the input of the next.
The reach of each agent comes from its tools — the actions it can take in your actual systems. This is why a standard like MCP matters to the factory: every tool you connect (your issue tracker, your logs, your database, a browser) is another box an agent can reach into. Tools are how an agent stops being a clever chat window and starts being a worker on the floor.
Three things a real factory needs
Strip away the jargon and a durable software factory rests on three plain ideas.
Pick the right model for each job. No single model is best at everything — they trade off cost, speed, and raw capability. A factory that hard-wires itself to one model is brittle and overpays. The healthy version lets you choose deliberately: a fast, cheap model for the mechanical boxes (triage, formatting, simple edits) and a stronger one for the hard ones (a tricky design, a security-sensitive review). This is the same habit one person practices when they decide which Claude model to use for a task — just applied across a whole pipeline. As models get cheaper and better every few months, that flexibility is what lets the factory ride the curve instead of being stranded on one rung of it.
Own the whole thing. A factory that learns is only valuable if the learning stays yours. Every triaged ticket, every review, every resolved incident is context about how your software actually works — and that context is the moat. Whether it runs in the cloud, on your own hardware, or somewhere locked down with no outside network at all, the principle is the same: the system should accumulate understanding of your codebase inside your walls, under your control, so the more you invest in it the more capable your factory becomes — not someone else’s.
It learns from itself. This is the part that makes it a factory and not just a pile of automations. When review, security analysis, testing, documentation, and incident response all run on the same floor, they share context. A security finding can inform the next code review. A deploy can trigger a documentation update. An incident can be traced back to the change that caused it. Every improvement you make to one station — a better prompt, a new check, a connected tool — flows to the whole line at once. The loop observes its own output and tightens.
The autonomy ladder
Nobody flips a switch and goes lights-out. Autonomy is a ramp you climb deliberately, and which rung you stand on should depend on the stakes, the sensitivity of the data, and how much you trust the system so far.
- A single skill or agent for well-defined, measurable tasks — “format this,” “draft a fix for this small bug,” “write the changelog.” Short horizon, easy to check, low risk. Start here.
- Recurring automations that run a known workflow on a schedule or a trigger, with a shared goal and a little memory between runs — “every morning, triage overnight issues and draft replies.”
- Long-running and parallel work, where the agent writes its own plan and coordinates several sub-agents for the task in front of it. This is the territory of dynamic workflows: one Claude writing a small program that runs many Claudes, for jobs too big or too parallel for a single context window.
- Multi-agent missions that decompose a genuinely complex job into parallel tracks and grind on it for hours, with a human checking in at the seams rather than every step.
The mistake is reaching for the top rung first. Most work belongs on the bottom two, and a mature factory is mostly small, boring, reliable automations with a few ambitious ones — not one heroic autonomous system doing everything. You earn each rung by trusting the one below it.
Where the lights stay on
Here’s the counterweight, and it’s the whole reason “dark factory” is a metaphor and not a plan. A loop that writes, reviews, and ships with no human anywhere in it is a loop that can be confidently, fluently wrong — and have no one left who understands what it did. We dug into exactly this failure mode in writing got cheap, understanding didn’t: when machines generate output faster than people can read it, the bottleneck moves to verification, and the human’s job is to spend scarce attention where being wrong actually hurts.
So you don’t go fully dark on purpose. You decide, on purpose, where the lights stay on:
- The high-blast-radius gates — the changes where a mistake costs users, money, or trust. A human owns those.
- The judgment of whether this is even the right thing to build — distinct from whether the code is correct. Models review the code that exists; they rarely flag the requirement nobody thought to write down.
- Governance, safety, and the business outcome — someone has to be accountable for what the factory ships. A model can’t be paged.
This is the genuinely good news for engineers, and it gets buried under the scary version of the story. The role doesn’t shrink — it grows. You stop being the only person who hand-writes the software and become the person who builds and governs the factory that writes it. That remit is bigger: it reaches into architecture, safety, cost, and the business itself. The most valuable engineer in a factory isn’t the fastest typist. It’s the one who designed a loop you can actually trust.
What to try this week
You don’t need a platform or a mandate to start. The factory shape is fractal — you can run a one-person version today and feel the loop close:
- Automate one box first. Point Claude Code at your incoming issues and ask for a triage pass: what’s safe, what’s risky, what’s unclear. You’ve just instrumented the front of the loop.
- Wire a second box to it. Have it draft a fix for one low-risk issue, then run a separate review pass over that draft. Two agents, output feeding input — that’s a miniature line.
- Keep one light on. You own the merge and you watch what ships. The monitoring step stays human, and what it tells you becomes next week’s signal.
That’s it — a loop, running mostly on its own, with you standing exactly where the stakes are highest. Scale it one rung at a time as you trust it more.
A software factory isn’t built in a day, and the lights-out version is further off and more conditional than the hype suggests. But the shape is real, it’s coming quickly, and the best day to wire up your first small loop is today.