Dark factory software delivery is an unattended delivery line where agents implement changes and carry them through verification and merge, while humans retain operational control through gate policy and halt authority.
TL;DR
Agentic coding revived a manufacturing term, but the term describes an end state rather than a documented industry norm. The controls that make unsupervised shipping safe, the verification gap that machines have not closed, and the trust and regulatory constraints that keep delivery lines attended decide how far a team can actually go.
An agent finishes a dependency upgrade, its tests pass, the pipeline's checks go green, and the merge controller lands the change with a commit message that reads like any other engineer's. Nobody on the team reads the diff. Similar merges land before the morning standup, and one that changed a connection-pool default under load surfaces as a paging incident. The on-call engineer must establish which merge caused it because each one carried valid credentials and a passing status. Every control authorizes that failure, and no person reviews it; this is what fully autonomous delivery looks like when the preconditions are missing.
This guide addresses chief technology officers (CTOs) and engineering leaders, including vice presidents and engineering managers, who must decide how far to remove humans from the merge path of a software factory, and it covers only the end state of an agentic software factory. It defines the term in the agentic-coding sense and assembles the necessary controls for unsupervised shipping into one checklist. Its counter-case explains why documented constraints keep almost every line attended.
What a Dark Factory Means in Software
In software, an AI dark factory is the Factory stage of the maturity model fully realized: agents pick up standardized work and implement it, then verify it against gates before merging it. No human reads each change before it ships. Humans still write the intent that enters the line and retain operational control through gate policy and halt authority. The word dark describes what humans stop doing, which is reading every diff, and says nothing about what they stop owning.
Software engineers borrowed the term from manufacturing. FANUC completed a highly automated Fuji factory in 1980 and, by 2002, ran robot cells for 720 hours of continuous unmanned operation, according to the company's corporate history. A total lights-out factory without direct human intervention is the target as defined by the National Institute of Standards and Technology (NIST) in a special publication. In that literature, dark and lights-out are synonyms. An unattended software line needs more accountability structure than an attended one, because it removes the reviewer's memory, which carried ownership that nobody wrote down.
What Dark Does Not Mean
Dark does not mean no human accountability, and the most common mistake teams make is equating unattended with unowned. In software, the absence of readers is a throughput decision, and ownership never moved. The SEC's Knight Capital order from 2013 shows the cost of that confusion in a pre-AI pipeline. A technician deployed new code to seven of eight servers, and the firm "did not have a second technician review this deployment." Dormant code on the eighth server went live, and the firm lost more than $460 million. Knight left the deployment unattended at the one step where it should have named an owner.
Teams should keep the ownership structure and remove only the reading. They should name the human who owns each gate's escape rate and the human who owns each service's incidents, then remove the reviewer. An unattended merge needs more provenance than an attended one because the reviewer's memory previously carried part of that record. The audit trail should attach the spec and agent identity to the merge, together with gate decisions and the model in use. That evidence lets the record behind an unread merge outlast the comment thread a human reviewer would have left. For deployers of high-risk AI systems, the AI Act logging duty in Article 26(6) sets a floor of six months of automatically generated logs.
Why the Term Resurfaced Now
The phrase resurfaced as agent-authored changes began arriving faster than the reviewer hours available to read them, the review-throughput ceiling the maturity model measures. Among nearly 5,000 technology professionals surveyed for the Google Cloud DevOps Research and Assessment (DORA) 2025 report published September 23, 2025, 90% use artificial intelligence (AI) at work and 30% report little or no trust in AI-generated code.
Benchmarks quantify how much the machines still miss. OpenAI and the SWE-bench maintainers created the 500-task human-filtered subset known as SWE-bench Verified. The top all-agent entries, tied at 79.20% resolved, are Sonar Foundation Agent and live-SWE-agent, both running Claude Opus 4.5. Scale AI's SWE-bench Pro public set contains 731 tasks from open-source repositories under strong copyleft licenses. On the September 3, 2026, snapshot, Muse Spark 1.1 under the mini-swe-agent harness led at 61.50 ± 3.10%. Derived from those two leaderboards, one in five curated Verified tasks and nearly two in five Pro tasks go unresolved, and that is the verification gap machine gates have to close.
What Has to Be True Before the Line Ships Unsupervised
Removing line-by-line review is a controlled decision only when standardized intake and owned gates operate alongside merge provenance, incident ownership, and a drilled halt path. The quality gates and org-design material already published cover these controls separately; together they form one checklist.
- Standardized intake: Every unit of work enters as an artifact with fixed acceptance criteria and scope boundaries, so the agent decides only what the spec leaves open and the gate owner classifies each failure as a spec defect or an implementation defect. For teams coordinating this standardized work across cloud agents, Augment Code's Cosmos is a unified cloud agents platform available on all paid plans.
- Station-level gates with named owners and escape-rate telemetry: Each gate has a human who owns its policy and a measured escape rate, meaning the share of changes that passed the gate and that incident responders later reverted or hotfixed. The closest published analog measures deployment-level outcomes. Deployments failed at a 5.4% rate and drew a manual revert or patch 0.92% of the time, across more than 30,000 pipelines studied in April and May 2023, according to Meta's peer-reviewed Conveyor deployment study.
- Provenance at merge: The merge record identifies which agent produced the change under a given spec and model, along with the gate that accepted it. Cosmos does this by default for its own merges: Sessions stay retained and auditable, so the spec and model behind a merge are reconstructable straight from the record. The Supply-chain Levels for Software Artifacts (SLSA) v1.2 build requirements, released November 24, 2025, specify signed provenance at Build L2 and forgery-resistant provenance at Build L3; the draft Source track defines L4 as two-party review. Organizations adopt both voluntarily.
- Incident ownership: A named human owns every incident the line causes, and the paging path reaches that person without a dispute about whether an agent-authored change counts as theirs. Accountability for the service stays with the human who owns it. The same rule holds when a Cosmos Automation triggers an Expert during an incident: the Automation's owner is accountable, not the Expert.
- A drilled halt path: Someone has stopped the line on purpose, in the last quarter, and measured how long it took every agent and scheduled job to go quiet. A policy nobody has exercised is only a setting. Cosmos's human-in-the-loop policies give a fleet operator this lever at the platform level.
Teams cannot treat intake as optional overhead when a gate owner needs to distinguish a specification defect from an implementation defect. Until standardized tickets establish that boundary, the first gate failure remains difficult to attribute.
Supervising by Exception: Human Over the Loop, Not Out of It
Supervising by exception means a human sees a change only when a gate raises it, and the design question is which position in the loop that human occupies. That taxonomy of loop positions comes from broader literature on human oversight of autonomous systems, not from software engineering: Human Rights Watch (HRW) and the Harvard International Human Rights Clinic set the three-term taxonomy in their 2012 HRW report. Singh and Szajnfarber split the middle position by how directly the overseer can act in a 2025 symposium paper. Over-the-loop is an academic term; binding instruments describe the same duty functionally, as the European Union (EU) Artificial Intelligence Act does in Article 14. The system's unattended behavior and the human intervention path define each loop position.
| Loop position | What the system does without a human | Human's intervention path | Source defining it | Delivery-line equivalent |
|---|---|---|---|---|
| Human-in-the-loop | Nothing; acts only on human command | Issues each command | HRW 2012 | Every diff read before merge |
| Human-on-the-loop | Acts under an operator who can override | Directly changes what the system does | HRW 2012; Singh and Szajnfarber 2025 | Reviewer blocks a merge in progress |
| Human-over-the-loop | Acts; oversight is indirect | Information or warnings only | Singh and Szajnfarber 2025 | Gate policy, intent, halt authority set in advance |
| Human-out-of-the-loop | Acts with no human input | None | HRW 2012 | No named halt owner |
The AI Act, Regulation 2024/1689, binds all European Union member states and applies generally from August 2, 2026. AI Act Article 14 requires providers to let human overseers interrupt a high-risk system with a "stop" button. That duty reaches a delivery pipeline only where the pipeline forms part of a covered high-risk system.
A dark factory puts humans over the loop by design, and the line runs unless a gate stops it. Cosmos operationalizes this directly with human-in-the-loop policies and sandboxed Environments that limit what an Expert can touch. Halt authority sits with a named role that can stop the whole line: the fleet-operator role in org design. The person who owns the gate's escape rate writes its policy, so a loosened threshold is a decision someone signed off on. Exceptions arrive at the rate gates fire, so teams plan supervision bandwidth as capacity. A line producing forty merges a night with a 5% exception rate hands two escalations to a human before breakfast, and supervision-bandwidth arithmetic belongs in capacity planning.
Why Delivery Lines Remain Attended
The documented constraints keep delivery lines attended when verification capacity, calibrated trust, or regulatory approval remains unresolved.
Verification Capacity
The agent vendors keep the human in the merge path themselves. Pre-integration human review of all agent-generated code is essential, according to OpenAI's Codex announcement, and GitHub's cloud-agent risk documentation prohibits the agent from approving or merging its own pull requests. Those positions match the benchmark gap above. A machine gate has to catch the curated tasks top agents still get wrong, and teams designed most existing gates to catch human mistakes at human volumes. Augment Code takes the same position with Cosmos: a Verifier Expert exercises each change against a live environment before a gate accepts it.
Trust Calibration
The approval gate itself is an attack surface. Prompt-injected content could flip Visual Studio's Copilot settings to auto-approve every tool call and disable all user confirmations until build 17.14.12, as Microsoft documented in Common Vulnerabilities and Exposures (CVE) entry CVE-2025-53773 and its security advisory on August 12, 2025. The same mechanism appears to have occurred without AI involved. A Two Sigma modeler's parameter changes flowed through an automated ticket workflow that implemented them "without review or analysis by the engineers who received the tickets," according to a 2025 order from the U.S. Securities and Exchange Commission (SEC). The changes reached 14 live-trading models, and Two Sigma repaid approximately $165 million.
Regulatory Posture
The EU's Digital Operational Resilience Act, Regulation 2022/2554, applies from January 17, 2025. Its technical standard, Regulation 2024/1774, sets an independence requirement: the function approving a change must remain independent of the functions requesting and implementing it. For in-scope financial entities, an agent that authors and merges its own change fails that test unless a separate gate owner approves. NIST Special Publication 800-53 Revision 5 control CM-3(1), "Automated Documentation, Notification, and Prohibition of Changes," requires that you "prohibit changes to the system until designated approvals are received," as a recommendation that becomes binding where FedRAMP adopts it. Neither instrument prohibits a dark factory outright. A line that cannot name the approver fails an audit before it fails in production.
Attribution runs both ways on an unattended line: operators can blame a human-authored change on an agent as easily as they can leave an agent-authored change unowned. Any one of these constraints keeps a line attended, and closing them requires work on intake and the audit trail, including gate ownership, rather than work on the agent.
How to Assess Your Own Line
Closing those gaps starts with an honest inventory. Score your line against the preconditions above this week, and treat any item you cannot answer from a document as a no. Pull the last 20 merges an agent authored and ask who read each one. If the answer is a passing status check, you already run part of an unattended line and have not decided to.
- Gate ownership: Open your branch-protection rules, list each required check, and write the name of the human who owns its policy beside it. A check without a name is a gate nobody will tune when it starts leaking.
- Escape-rate telemetry: For each named gate, compute the share of changes that passed it last quarter and that incident responders later reverted or hotfixed. Without that number, you can't loosen or tighten a gate threshold based on evidence.
- Provenance at merge: Open one agent-authored merge from last month and reconstruct the spec it implemented and the agent-model pairing that produced it, then identify the accepting gate from the record alone. If the reconstruction needs a person's memory, provenance is missing. On a line running Cosmos, that reconstruction should come from the Session record, not from asking around.
- Incident ownership: Find the last incident that an agent-authored change caused and check the postmortem for a named owner. A team whose postmortem names the agent and no human has already made the unowned mistake.
- Halt path: Ask when the line was last stopped on purpose and how long every agent and scheduled job took to go quiet. If the answer is never, schedule the drill for a low-traffic window this month and time it.
Answering all five establishes the documented controls needed to consider unattended shipping for the class of work the intake standardizes; it does not establish that the gates work effectively. If any answer is missing, the line remains below the Factory stage, and the first failed item identifies the next control to establish.
What to Do Next
Whatever the scoring shows, don't try to fix all five at once. Pick the single gate with the highest escape rate on the assessment above and give it an owner and a written threshold this week. The tradeoff is autonomy against verification capacity. For every reviewer a team removes from the merge path, a gate with a named owner and a measured escape rate must take their place. That gate will catch less than the reviewer did until the team standardizes the intake feeding it. Run the halt drill before you remove another reviewer, and record how long the line took to stop. On a line running Cosmos, the same drill should confirm a fleet operator can halt an Expert directly, through the platform's human-in-the-loop controls. That number and the escape rate are the two figures that decide how dark the line can safely go.
Frequently Asked Questions About Dark Factory
Related Reading
- Software Factory Metrics: Measuring Throughput When Agents Do the Work
- Software Factory vs DevOps: When Agents Do the Work
- AI Agents for Incident Management: Architecture and Production Patterns
- What Determines Software Delivery Performance With AI?
- Vulnerability Scanning in Agentic AI: Enterprise Guide
Written by
Paula Hingel
Paula writes about the patterns that make AI coding agents actually work — spec-driven development, multi-agent orchestration, and the context engineering layer most teams skip. Her guides draw on real build examples and focus on what changes when you move from a single AI assistant to a full agentic codebase.