--- schema: "swft.publication/v1" id: "dark-factory-explainer" title: "What is a dark factory?" description: "A dark factory is a software factory where agents produce nearly all of the code — the extreme end of the autonomy spectrum, with named human gates for direction, permissions, review, and release." summary: "A dark factory is a software factory where agents produce nearly all of the code. The term borrows lights-out manufacturing: people are off the floor but still choose the work, set permissions, review output, and decide what ships. It is a spectrum end, not a separate kind of system." canonical: "https://swft.io/dark-factory" author: "SWFT Editorial" author_type: "Organization" published: "2026-09-23" modified: "2026-09-23" kind: "explainer" section: "Guides" tags: ["dark factory", "dark software factory", "agentic software development", "software factory", "agent swarms"] evidence_labels: ["INFERENCE", "OBS", "SELF-REPORT"] source_ids: ["openai-agents-work", "openai-harness-engineering", "openai-symphony", "openai-symphony-blog", "strongdm-software-factory"] authorship_disclosure: "AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections." --- # What is a dark factory? The lights-out end of the software-factory spectrum: agents write nearly all the code while people keep direction, review, and release. > **Authorship:** AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections. ## Quick answer A dark factory is a software factory where agents produce nearly all of the code. The term borrows lights-out manufacturing: people are off the floor but still choose the work, set permissions, review output, and decide what ships. It is a spectrum end, not a separate kind of system. A **dark factory** is a software factory where agents produce nearly all of the code. The name borrows "lights-out" manufacturing: the line runs without people on the floor, while people still choose what gets made and whether it ships. The closest documented approach is OpenAI's. Its [harness engineering account](https://openai.com/index/harness-engineering/) describes an internal repository written almost entirely by agents — people prepared specifications, tools, feedback, and repository structure rather than writing code. Its [Symphony spec](https://openai.com/index/open-source-codex-orchestration-symphony/) shows the orchestration layer: a work board drives isolated agent runs with proof-of-work requirements and a protected landing path. OpenAI's [internal usage figures](https://openai.com/index/how-agents-are-transforming-work/) describe adoption across engineering and other departments; those numbers are first-party reports, not an audit. [StrongDM's software-factory account](https://www.strongdm.com/blog/the-strongdm-software-factory-building-software-with-ai) is the second notable public description of an organization rebuilding its development process around agent-produced work. ## What "dark" means — and does not mean Dark describes where the code comes from, not where authority lives. In every documented case, people keep the same named gates: they choose the product work, set permissions, review what the system produces, and decide what merges and releases. "Nearly all code written by agents" is a claim about generated lines, not about unattended decisions. It is also the end of a spectrum, not a category. A team running one bounded production line and an organization generating most of its codebase through agents differ in degree along the same variables: how much work agents touch, how much checking is automated, and how much attention people spend on direction versus implementation. ## What a dark factory still needs from people The darker the floor, the more the human work concentrates: task selection and acceptance, the specifications and context agents receive, permissions and spend limits, review of what the system reports, and the decision to expand or contract the system's scope. The documented cases invest heavily in exactly those surfaces — repository-legible context, enforceable architecture, and proof loops — because the factory's quality is decided upstream of any single run. ## How to read dark-factory claims Apply the same evidence labels everywhere. First-party accounts describe what an organization reports about itself; they are real evidence with a known bias toward the flattering number. A "1 million lines" or "no human code" figure describes generated volume, not correctness, maintainability, or business result. The questions worth asking of any dark-factory claim: what fraction of *merged* work is agent-produced, what checks gate it, who can stop the line, and what the system costs per accepted result. For the orchestration design behind the best-documented case, read [OpenAI Codex Symphony](/companies/openai-codex-symphony). For reported scale across organizations, see [Agent scale](/scale). ## Questions product teams ask ### Does a dark factory need no humans? No documented case removes people. Agents write nearly all the code; people choose the work, set permissions, review output, and decide what merges and releases. Dark describes the code's origin, not authority. ### Is a dark factory the same as an AI factory? No. AI factory usually refers to data-center infrastructure for training and running models (NVIDIA's usage). A dark factory is a software-production organization where agents write most of the code. The terms collide in search results but describe different things. ### How real are the reported figures? The documented figures are first-party reports — real evidence about what an organization says about itself, with a known bias toward flattering numbers. Ask what share of merged work is agent-produced, what checks gate it, and what a result costs. ## How we know - **First-party report (SELF-REPORT)** OpenAI describes an internal repository written almost entirely by agents, an orchestration spec for board-driven agent runs, and internal adoption figures. Sources: [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/); [An open-source spec for Codex orchestration: Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/); [How agents are transforming work](https://openai.com/index/how-agents-are-transforming-work/). - **Observed artifact (OBS)** OpenAI's Symphony repository is the inspectable artifact of the orchestration design behind its account. Sources: [Symphony](https://github.com/openai/symphony). - **First-party report (SELF-REPORT)** StrongDM published a second public account of an organization rebuilding development around agent-produced work. Sources: [The StrongDM Software Factory: Building Software with AI](https://www.strongdm.com/blog/the-strongdm-software-factory-building-software-with-ai). - **Analysis (INFERENCE)** SWFT treats dark factory as the autonomy-spectrum end rather than a new category: the documented cases keep named human gates for direction, permissions, review, and release. Sources: [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/); [An open-source spec for Codex orchestration: Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/); [The StrongDM Software Factory: Building Software with AI](https://www.strongdm.com/blog/the-strongdm-software-factory-building-software-with-ai). ## Sources - **First-party report (SELF-REPORT)** [How agents are transforming work](https://openai.com/index/how-agents-are-transforming-work/) — OpenAI; published 2026-06-25; accessed 2026-09-01. OpenAI's first-party internal usage study across engineering and non-technical departments; runtime and output-token figures are adoption signals, not direct quality measures. - **First-party report (SELF-REPORT)** [Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/) — OpenAI; published 2026-02-11; accessed 2026-09-01. OpenAI's bounded internal experiment with an agent-written repository, enforceable architecture, repository-legible context, proof loops, observability, and recurring cleanup. - **Observed artifact (OBS)** [Symphony](https://github.com/openai/symphony) — OpenAI; accessed 2026-08-31. Open-source engineering preview for turning project work into isolated agent implementation runs with proof of work and protected landing. - **First-party report (SELF-REPORT)** [An open-source spec for Codex orchestration: Symphony](https://openai.com/index/open-source-codex-orchestration-symphony/) — OpenAI; published 2026-04-27; accessed 2026-09-01. OpenAI's account of turning a Linear board into a state machine and control plane for continuous isolated agent work, task dependencies, retries, and human review. - **First-party report (SELF-REPORT)** [The StrongDM Software Factory: Building Software with AI](https://www.strongdm.com/blog/the-strongdm-software-factory-building-software-with-ai) — StrongDM; accessed 2026-08-31. StrongDM's public account of its software-factory operating model. ## Read next - [OpenAI's Codex factory: preparing the repository and coordinating the work](/companies/openai-codex-symphony) - [Agent swarm scale: documented runs and adoption](/scale) - [What is a software factory?](/what-is-a-software-factory)