30-40 pull requests merged to main every day, from issue creation to deployment, with zero human touch in the pipeline. That’s not a demo. That’s a live operating environment.
There’s a gap in the AI services market that nobody talks about directly.
Most firms selling AI automation have built demos of it. Impressive demos, often — a pipeline that takes a ticket, writes the code, opens the pull request, and merges. It works on stage. What it hasn’t done is run continuously against a real codebase with real consequences for six months.
We run ours. 30-40 pull requests merged to main on a typical day. Issue creation through deployment, with no person in the path.
This is what we mean when we say dark factory, and this is what operating one actually involves.
Where the Term Comes From
A dark factory is a manufacturing facility automated to the point where it can run with the lights off. Not as a cost-saving measure — because there is nobody on the floor who needs to see. Machines don’t require illumination. The lights are a proxy for human presence, and their absence is the whole point.
Applied to software, it describes a development pipeline where the path from “here’s a problem” to “it’s in production” doesn’t route through a person for each individual change.
The metaphor is useful because of what it implies about the preceding decade. No manufacturer arrives at a dark factory by switching one on. They get there by instrumenting every step, discovering which failures are silent, and building detection for each one. The automation is the visible result of a long, unglamorous process of learning what breaks.
Software is no different, which is why the demo version and the operating version look nothing alike.
What Actually Has to Be True
The demos skip the infrastructure. Here is what makes the difference between a pipeline that ships quickly and one that ships broken code quickly.
Every gate has to stop the line
In a human-reviewed workflow, warnings are tolerable. Somebody reads the CI output, notices the yellow, and makes a judgment call. Remove the person and a warning is indistinguishable from silence.
So every gate — tests, contract validation, security scanning, deployment health checks — either blocks the merge or it might as well not exist. This sounds obvious and is the single most common reason automated pipelines produce bad outcomes. Teams port over a CI configuration built for human review, remove the human, and are surprised when things reach production that shouldn’t have.
An automated pipeline that fails quietly doesn’t ship faster. It ships broken code faster.
Contracts between services have to be explicit and versioned
When no human reads the diff, the schema is the only thing standing between a reasonable-looking change and a silent semantic break.
The canonical example: an extraction service returns a confidence score as a float between 0 and 1. Downstream, an orchestrator routes anything below 0.7 to human review. Someone changes confidence to a 0-to-100 integer for consistency with a new dashboard. Reasonable change, well tested, accuracy improves.
The orchestrator now compares 82 to 0.7. Everything auto-approves. No error, no alert, no unusual log line — just an empty review queue that looks like the improvement working.
In a human workflow, a reviewer might catch that. In an automated one, only a declared and validated contract catches it. Which is why the boundaries between our services are versioned, why breaking changes require a major version bump with a deprecation window, and why consumers test against published contracts rather than live instances.
Rollback has to be cheap and automatic
At 35 merges a day, “we’ll investigate tomorrow and patch it” is not a recovery plan. By tomorrow there are 35 more changes layered on top of the problem.
The system has to detect degradation and back itself out without waiting for someone to wake up. This constraint shapes everything upstream: small changes, feature flags, deployment strategies that can be reversed in seconds. You cannot bolt automatic rollback onto a pipeline that ships large, entangled changes.
Agents need somewhere to escalate
This is the piece most people get wrong about dark factories, and it’s the most important one.
Automation does not mean the human is gone. It means the human is not in the per-change path. Those are different claims, and conflating them produces exactly the systems that fail badly.
When one of our agents hits a decision it can’t make with confidence — an ambiguous requirement, a data source it lacks access to, a change whose blast radius it can’t determine — it stops and surfaces the gap rather than proceeding on an assumption. Structured question, bounded options, full context, logged with a timestamp. A person resolves it and the agent picks up exactly where it stopped.
An agent that never asks anything is not more capable. It’s a system that has been configured to guess silently, which in a pipeline running 35 changes a day is a way to accumulate errors faster than anyone can find them.
The Distinction That Makes It Work
Humans validate the system, not every output.
Nobody here reviews 35 diffs a day. That job doesn’t scale and, more to the point, wouldn’t be done well — a person reading their twenty-eighth pull request before lunch is not exercising meaningful judgment, they’re pattern-matching against fatigue.
What we do review is different work:
- Are the evaluation criteria still measuring the right thing?
- Are the gates catching what they should? When did one last block something, and was it right to?
- What is the escalation rate, and which direction is it moving? A falling rate might mean the system is getting better, or it might mean the confidence thresholds have drifted and it has stopped asking.
- What did the pipeline do when it disagreed with itself?
- Which changes did we roll back, and what class of problem did they share?
That’s a smaller amount of work than reviewing every change, and it’s harder work. It requires understanding the system as a system rather than evaluating artifacts one at a time. It’s also the only version of oversight that survives contact with this volume.
What Doesn’t Go Through It
The honest caveat, because a claim like this invites scrutiny and should.
Not every change belongs in the automated path. Anything touching authentication, payments, or customer data still routes through a person. Not because the pipeline couldn’t handle it mechanically, but because the cost of being wrong in those areas isn’t symmetrical with the cost of being slow.
That asymmetry is the actual decision rule. Where errors are cheap, reversible, and detectable, automate the path completely. Where they’re expensive, hard to reverse, or slow to surface, keep a human in it. Applying one policy to both categories is a mistake in either direction — full automation everywhere is reckless, full review everywhere is just an expensive way to be slow.
Knowing which changes fall where is a judgment call, and it’s ours to make and revisit.
Why We’re Writing This Down
There is a meaningful difference between a firm that can describe AI automation and one that operates it, and from the outside those look identical in a pitch meeting.
The difference shows up in what we know about the failure modes. We can tell you what happens when contract validation is missing, because we’ve watched it. We know that escalation rate is a more useful health metric than throughput, because throughput looked fine during a period when it wasn’t. We know rollback frequency is a feature rather than an embarrassment.
None of that comes from building demos. It comes from running the thing every day and being the ones who deal with it when it misbehaves.
A dark factory isn’t the absence of judgment. It’s judgment relocated — from reviewing individual changes to designing the system that reviews them. That relocation is the entire discipline, and it’s what we build for clients.
It’s also just how we work.
Talk to us at findustries.co/contact about what this would look like in your environment.
