Dark Factory (Fully Automated Software Pipeline)

A fully automated software delivery pipeline (borrowed from manufacturing's lights-out factory) in which human oversight is excluded except for improving the quality of the pipelines themselves.

Also known as: dark factory, dark factories, full dark factory pipelines, dark factory pipelines, dark factory camp, fully automated, lights off, with no human ever reading the code

Part of: Agentic Engineering

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (4)

• Software Factories, Light and Dark AddyOsmani.com · 2026-07-20 source ↗ Reader 🖥️
  Because verification, not generation, is the real bottleneck of an AI-driven 'software factory,' an engineer's central job is to decide loop by loop how much autonomy each part of the pipeline can earn — full automation ('dark') only where a check is cheap, fast, and hard to fake, human judgment ('lit') everywhere else — with the human's own role relocating from writing code to owning and verifying that outer decision.
• Software Design in the Agentic Age: Place Your Bets Mathias Verraes · 2026-07-07 source ↗ Reader 🖥️
  In the agentic age, code-level quality becomes automatable but high-level software design and rigorous (ideally executable) specifications remain decisive human-led work, so under deep uncertainty about AI's payoffs and externalities teams should bet on design rigour, executable specifications, and the ability to revert from agent generation back to human engineering.
• Why did Martin Fowler invite 60 engineers to a ski resort? Ivett Ördög · 2026-07-05 source ↗ Reader 🖥️
  The turn to AI-built software has reopened rather than resolved the foundational questions of the craft — should humans still read code, how do we know it works, does code quality still matter, and how do we manage newly-empowered citizen developers — and the author's connective throughline is an optimistic one: AI democratizes building while the disciplines that make code good for humans remain exactly the ones that make it good for AI.
• Software Design in the Agentic Age: Placing Your Bets aardling.eu · 2026-07-03 Reader 🖥️
  Even though no one yet has evidence that classic code-design and domain-modeling discipline is necessary for agentic development, the author bets on maintaining it anyway — high test coverage, sound domain models and Ubiquitous Language, disciplined Bounded Contexts, and code quality — because doing so is the dominant strategy under uncertainty (cheap to unwind if unnecessary, expensive to retrofit if not) and because it preserves the option to revert an organization from agentic code generation back to human engineering if AI's economics or reliability falter.

Propositions touching this concept (12)

By publication month, oldest first (extraction month when no publication date is known).

2026-05

• explicitThe industry is converging on fully automated, self-optimizing infrastructure where performance, cost, and efficiency are balanced in real time.
  Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale · p14

2026-06

• explicitMost steps of most operational processes (e.g. routine code review, routine ticket triage) can be fully automated for their base case with a good-enough harness and domain context, while a minority of higher-risk steps still require human judgment; failing to distinguish base case from edge case creates unnecessary risk.
  Revised rules of engineering leadership. · p5
• explicitThe 'software/dark factory' and the $1000/token/day-per-engineer target are hype (the author's own factory runs ~$600/month), but with a kernel of truth: the incentive to spend ludicrously on tokens is latent, waiting for diffusion.
  Agentics / Tech Things: Tokenmaxxing is dead, long live tokenmaxxing · p11

2026-07

• explicitA dark factory is a fully automated software pipeline in which no human reads the code that ships, verified only by other machines, directly borrowing the 'lights-out manufacturing' precedent (FANUC since 2001, Xiaomi in 2024).
  Software Factories, Light and Dark · p5
• explicitcorroboratedRemoving the human review step makes a team's perceived throughput jump dramatically, which is exactly what makes dark factories deceptively easy to adopt at first, while their real costs stay hidden.
  Software Factories, Light and Dark · p6
• explicitcorroboratedComprehension debt (the growing gap between how much code exists and how much any human still understands) is not paid down by a dark factory; it is taken on as fast as possible, with tests green the whole way.
  Software Factories, Light and Dark · p7
• explicitcorroboratedRunning a fully automated code factory with zero human reading of output for about four months produced a failure severe enough to require painstaking manual debugging just to locate — evidence the failure mode is real, not hypothetical, and surfaces 'quiet and late' rather than as a dramatic collapse.
  Software Factories, Light and Dark · p9
• explicitcorroboratedA lit factory keeps the same automated pipeline as a dark factory but relocates human judgment upstream — into product, design, and architecture decisions before an agent starts a loop — rather than only re-adding review at the end.
  Software Factories, Light and Dark · p12
• explicitdevelopedA loop earns fully automated ('dark') status only if its check is cheap, runs at high frequency, and relies on an oracle that can't easily be faked out and answers immediately without drifting over time (green/red tests, type gates, property tests, or a review agent with a real rubric).
  Software Factories, Light and Dark · p15
• explicitDark-factory pipelines (fully automated generate-verify-deploy with human oversight limited to improving the pipeline) are currently very hard to set up and require highly skilled engineers plus an already-established high-quality engineering culture; organizations that attempt one without that foundation risk high costs or major accidents.
  Software Design in the Agentic Age: Placing Your Bets · p9
• explicitFully automated dark-factory pipelines are only safe for organisations that already have high test coverage, skilled engineers, and an established high-quality engineering culture; adopting them without these fundamentals risks high costs or major accidents.
  Software Design in the Agentic Age: Place Your Bets · p12
• explicitWhen loan officers could not see or override a fully automated loan-approval AI's actual rationale, they masked its role by citing familiar expert-sounding reasons (e.g., weak credit history) that did not reflect the AI's real basis, in order to preserve their perceived expertise.
  When Employees Are Held Accountable for AI-Generated Decisions · p3

Tensions

Open gaps (4)

• illogicalThe piece argues both that free-running loops are dangerously unstructured (motivating the pivot to explicit graphs) and that short, low-stakes loops (the nightly lint-fix cron) legitimately earn full autonomy without any explicit graph structure — it never reconciles when a loop needs graph-discipline versus when it's fine to run as a pure loop; length and stakes are offered as the answer for automation-worthiness, but that criterion is never explicitly connected back to the separate loop-vs-graph argument.
  Software Factories, Light and Dark — read next: Read for a unified framework connecting loop-length/stakes-based autonomy criteria with graph/state-machine architecture choices, rather than treating them as two independent recommendations.
• incompleteThe rule of thumb that 'an agent holds up for three to ten steps, then starts losing the thread past twenty' is stated (attributed to Dex Horthy) without any grounding for why that specific numeric range holds, what model or context window it was measured against, or whether it's expected to shift as context windows and context-management techniques improve — it's treated as a durable constant rather than a fast-moving, model-dependent empirical measurement.
  Software Factories, Light and Dark — read next: Look for benchmark data on agent step-count reliability across model generations and context-management techniques, to see whether this threshold is already stale.
• incompleteThe Squid v1 failure ('something went off-script... I couldn't debug it, couldn't halt it mid-run') is never described concretely — what broke, how it manifested, how long it ran undetected — so it functions as an origin myth justifying the granular-vs-autonomous design rule without evidence that granular commands would actually have prevented the same failure on a different task.
  Inside a Software Factory — read next: Compare against extract-addy-osmani-software-factories-light-dark#p9, which reports a similar personal failure (a fully automated pipeline running about four months before a serious bug was found) in far more concrete terms — useful for testing whether Iusztin's vaguer account describes the same underlying failure mode.
• illogicalThe closing operating model instructs 'put all quality assurances and verification inside the loop' and separately 'put humans in their rightful place, on the right decisions' as if these were sequential, non-competing instructions — but the essay's own earlier claim that 'the agent can ship more than you can review' implies verification-inside-the-loop and human decision-capacity are in tension precisely as loop throughput scales, and the essay never reconciles how 'put verification inside the loop' avoids collapsing into exactly the 'dark factory' pattern its companion piece warns against.
  Own the Outer Loop — read next: Reread the dark/lit factory framework in 'Software Factories, Light and Dark,' which draws this line explicitly and carefully, for how much more precise that essay is on this exact point than this one.