AI Tools, Testing
What Is a Dark Software Factory?
A dark software factory is a software system that builds, tests, deploys, and repairs itself through autonomous agents, with no human required in the loop for the routine work. The name borrows from manufacturing's "dark factory" — a plant so fully automated it can run with the lights off, because no human operators are on the floor. Applied to software, the metaphor describes a codebase where the agents doing the work don't need a developer watching the screen. Code gets written, reviewed, tested, and merged; regressions get caught and fixed; the pipeline keeps moving through nights and weekends. The developer sets direction and reviews outcomes instead of typing every line. This post defines the term, separates it from the things it gets confused with, and gives you a concrete test for whether your own project is heading toward one.
Join the Vibe Coding Community
Swap builds, trade feedback, and ship faster alongside other people vibe coding.
The One-Line Answer
A dark software factory is a software delivery pipeline that runs end-to-end on autonomous agents — writing, testing, deploying, and self-healing code — without a human operating each step. It's "lights-out manufacturing" applied to software: the system stays productive when no one is watching, because no one needs to be.
The phrase is a deliberate lift from industry. In manufacturing, a dark factory or "lights-out" plant fully automates production so it can run with the lights off — robots don't need to see. FANUC in Japan is the canonical example, running facilities with almost no on-site staff. The software version keeps the core claim and drops the hardware: the factory floor is your repository, the machines are coding agents, and "the lights are off" means the routine build-test-ship-repair cycle continues without a developer driving it.
The phrase is a deliberate lift from industry. In manufacturing, a dark factory or "lights-out" plant fully automates production so it can run with the lights off — robots don't need to see. FANUC in Japan is the canonical example, running facilities with almost no on-site staff. The software version keeps the core claim and drops the hardware: the factory floor is your repository, the machines are coding agents, and "the lights are off" means the routine build-test-ship-repair cycle continues without a developer driving it.
Where the Term Comes From
Lights-out manufacturing has a real lineage. The idea is that humans need light to work, so a plant designed to run without humans can run without lights — saving energy, running continuously, and removing human error from precision processes like semiconductor and pharmaceutical production. It's not science fiction; it's an operating model that specific factories already use.
The software analogy has become usable only recently, because until coding agents got good enough to carry a task across multiple steps without constant correction, "software that ships itself" was a slogan, not a workflow. That changed. Agents can now hold a goal, take a sequence of actions, run their own checks, and course-correct. Once that's true, the manufacturing metaphor stops being a stretch and starts being a design target: what would it take for your delivery pipeline to run lights-out?
For the deeper argument — why the runtime itself, not just the build step, is where autonomy has to live, and what "dark-factory-as-runtime" implies for how software is operated — see the Adaptive Software Substack. This post stays on the definition.
The software analogy has become usable only recently, because until coding agents got good enough to carry a task across multiple steps without constant correction, "software that ships itself" was a slogan, not a workflow. That changed. Agents can now hold a goal, take a sequence of actions, run their own checks, and course-correct. Once that's true, the manufacturing metaphor stops being a stretch and starts being a design target: what would it take for your delivery pipeline to run lights-out?
For the deeper argument — why the runtime itself, not just the build step, is where autonomy has to live, and what "dark-factory-as-runtime" implies for how software is operated — see the Adaptive Software Substack. This post stays on the definition.
What a Dark Software Factory Is Not
The term gets stretched, so it's worth drawing three lines.
It's not just CI/CD. Continuous integration and deployment automate the plumbing — run the tests, build the artifact, push it to prod when the checks go green. But CI/CD doesn't decide what to build, doesn't write the code, and doesn't diagnose a failing test and fix it. It executes a pipeline a human authored. A dark software factory automates the judgment steps too: what change to make, whether the change is correct, and what to do when it isn't. CI/CD is the conveyor belt. The dark factory is the conveyor belt plus the workers.
It's not "AI autocomplete." An IDE assistant that suggests the next line is a copilot — a human is still flying the plane. A dark software factory is closer to autopilot: the agent owns a whole task from intent to merged, and the human reviews the result rather than approving each keystroke. The distinction is who holds the loop. In autocomplete, the human is in the loop on every token. In a dark factory, the human is on the loop — supervising, setting guardrails, spot-checking — but not inside every action.
It's not "no humans ever." "Lights-out" describes the routine case, not every case. A real dark factory in manufacturing still has engineers who design the line, handle exceptions, and intervene when something novel breaks. The software version is the same: humans set goals, define guardrails, review high-stakes changes, and step in for the genuinely new. The claim is that the repetitive work — the 80% that's build-test-ship-repair — runs without a person driving it, not that people disappear.
It's not just CI/CD. Continuous integration and deployment automate the plumbing — run the tests, build the artifact, push it to prod when the checks go green. But CI/CD doesn't decide what to build, doesn't write the code, and doesn't diagnose a failing test and fix it. It executes a pipeline a human authored. A dark software factory automates the judgment steps too: what change to make, whether the change is correct, and what to do when it isn't. CI/CD is the conveyor belt. The dark factory is the conveyor belt plus the workers.
It's not "AI autocomplete." An IDE assistant that suggests the next line is a copilot — a human is still flying the plane. A dark software factory is closer to autopilot: the agent owns a whole task from intent to merged, and the human reviews the result rather than approving each keystroke. The distinction is who holds the loop. In autocomplete, the human is in the loop on every token. In a dark factory, the human is on the loop — supervising, setting guardrails, spot-checking — but not inside every action.
It's not "no humans ever." "Lights-out" describes the routine case, not every case. A real dark factory in manufacturing still has engineers who design the line, handle exceptions, and intervene when something novel breaks. The software version is the same: humans set goals, define guardrails, review high-stakes changes, and step in for the genuinely new. The claim is that the repetitive work — the 80% that's build-test-ship-repair — runs without a person driving it, not that people disappear.
The Three Capabilities That Define One
If you want a test rather than a vibe, a dark software factory needs three things working together. Miss one and you have automation, not a factory.
1. Autonomous construction. Agents can take a specified goal and produce working code against it — not a snippet, but a change that compiles, passes its checks, and does what was asked. This is the part most teams already experience through coding agents.
2. Self-verification. The system generates its own signal about whether the work is correct, before real users hit it. This is the hard part and the part most "AI coding" setups skip. Autonomous construction without verification just produces broken code faster. The factory needs a way to know a change is good without waiting for a human to notice it's bad in production.
3. Self-repair. When verification catches a problem, the system can act on it — open the fix, re-verify, and close the loop — rather than filing a ticket for a human. Repair is what makes the lights-out claim true. A pipeline that detects problems but parks them for a human on Monday isn't running dark; it's running with a night-shift backlog.
The interesting gap is #2. Construction is increasingly commodity. Repair is downstream of verification. But verification requires signal — evidence that a change is right or wrong — and for a freshly built app that signal usually comes from real users you don't have yet. That cold-start problem is the wall most self-building pipelines hit.
1. Autonomous construction. Agents can take a specified goal and produce working code against it — not a snippet, but a change that compiles, passes its checks, and does what was asked. This is the part most teams already experience through coding agents.
2. Self-verification. The system generates its own signal about whether the work is correct, before real users hit it. This is the hard part and the part most "AI coding" setups skip. Autonomous construction without verification just produces broken code faster. The factory needs a way to know a change is good without waiting for a human to notice it's bad in production.
3. Self-repair. When verification catches a problem, the system can act on it — open the fix, re-verify, and close the loop — rather than filing a ticket for a human. Repair is what makes the lights-out claim true. A pipeline that detects problems but parks them for a human on Monday isn't running dark; it's running with a night-shift backlog.
The interesting gap is #2. Construction is increasingly commodity. Repair is downstream of verification. But verification requires signal — evidence that a change is right or wrong — and for a freshly built app that signal usually comes from real users you don't have yet. That cold-start problem is the wall most self-building pipelines hit.
How You'd Know You're Building One
You don't decide to build a dark software factory on a Monday. You back into one by removing humans from steps that used to require them. A practical readiness check:
• Construction: can an agent take a task in your backlog and produce a mergeable change without a developer writing the code?
• Verification: does anything other than a human reviewer decide whether that change is safe — tests, checks, simulated usage, behavioral signal?
• Repair: when something is found to be wrong, does the system attempt the fix, or does it wait for a person?
• Signal without traffic: can you tell whether a change is good before real users touch it, or are you flying blind until something breaks in prod?
The last one is usually the weakest link. Static analysis catches the code that's obviously wrong. It says nothing about the code that runs fine and still fails the user — the form that loses people at the password field, the flow that's confusing, the behavior that's technically correct and practically broken. Closing that gap is what separates a fast pipeline from a factory that can actually run in the dark.
• Construction: can an agent take a task in your backlog and produce a mergeable change without a developer writing the code?
• Verification: does anything other than a human reviewer decide whether that change is safe — tests, checks, simulated usage, behavioral signal?
• Repair: when something is found to be wrong, does the system attempt the fix, or does it wait for a person?
• Signal without traffic: can you tell whether a change is good before real users touch it, or are you flying blind until something breaks in prod?
The last one is usually the weakest link. Static analysis catches the code that's obviously wrong. It says nothing about the code that runs fine and still fails the user — the form that loses people at the password field, the flow that's confusing, the behavior that's technically correct and practically broken. Closing that gap is what separates a fast pipeline from a factory that can actually run in the dark.
Why the Verification Gap Is the Real Bottleneck
Every serious attempt at lights-out software runs into the same problem: agents can write and rewrite code all day, but the loop only closes if the system can judge its own output. For a live product with traffic, real user behavior supplies that judgment. For a new app, a refactor, or any change before it reaches users, there's no behavioral signal yet — and that's exactly when you most need to know whether the change is safe.
There are two ways to get signal without live traffic. Scan the code statically for the classes of problem that are visible without running it — security holes, performance regressions, outdated and vulnerable dependencies, obvious UX defects. And simulate the usage you don't have yet, running synthetic personas through the actual flows to surface the behavioral problems that only appear when something tries to use the thing. Together, those two give a self-building pipeline the verification layer it needs before real users ever show up.
There are two ways to get signal without live traffic. Scan the code statically for the classes of problem that are visible without running it — security holes, performance regressions, outdated and vulnerable dependencies, obvious UX defects. And simulate the usage you don't have yet, running synthetic personas through the actual flows to surface the behavioral problems that only appear when something tries to use the thing. Together, those two give a self-building pipeline the verification layer it needs before real users ever show up.
See the Verification Layer in Action — Free
A dark software factory is only as good as its ability to check its own work, and that check has to happen before real users arrive. That's the piece you can try today. Connect your GitHub repo to Differ and the first import runs a Phase 1 code scan — security, performance, outdated packages, and UX defects — then sends AI personas through your actual flows to surface the behavioral problems static analysis can't see. No live traffic required, no instrumentation to add. You get back a concrete report of what's wrong and what to fix, which is exactly the self-verification signal a lights-out pipeline runs on. Connect your repo and get your free report.