A dark software factory, in Addy Osmani’s description, is a Software Factory in which “code ships that no human has read, verified only by other machines.” The image is borrowed from manufacturing: a dark factory runs with the lights physically off because the only things on the floor are machines, which do not need light to see. Osmani stresses that the word is used as a literal physical claim rather than an insult — in software “the floor is the diff,” and what makes a factory dark is that the act of a human reading that diff has been removed. Its counterpart is a lit factory: the same pipeline with the lights left on where judgment lives, in which agents still do most of the building but a human reads what comes out before it ships, and human judgment is moved upstream to the product, the design and the architecture before an agent starts a loop.
Usage
Osmani presents the dark/lit distinction in Software Factories, Light and Dark as a setting chosen loop by loop rather than for a whole factory. Going dark is, he says, surprisingly easy at first, because removing review makes a team’s throughput suddenly seem far higher; the cost is Comprehension Debt, which a dark factory “doesn’t pay … down; it takes it on as fast as it can, with the tests green the whole way.” He relays a report from a speaker who ran a fully automated code factory for about four months with no human looking at the code, and found the resulting failure required painstaking manual debugging to pinpoint.
The name is not Osmani’s alone. Recounting StrongDM’s software factory in 2026 in LLMs (so far), Simon Willison says Dan Shapiro called that approach the Dark Factory, after the idea that a sufficiently automated factory can turn the lights out because nobody needs to see what is going on. The approach he applies it to is defined by two rules StrongDM stated — code must not be written by humans, and code must not be reviewed by humans — and Willison describes the team as exploring how to build software without reading the code while still being confident it is of high quality, and what agents can do to help verify their own work.
When It Applies
On Osmani’s account, a loop can earn fully automated, lights-out status only when its check is cheap, runs at high frequency, relies on something that cannot easily be faked — green-or-red oracles, type gates, property tests, a review agent with a real rubric — answers immediately and does not drift over time. Short loops qualify more easily than long ones. He relays an example described by another practitioner: a nightly job that fixes exactly one anti-pattern and opens one small pull request. A loop should stay lit when a wrong answer is expensive and only a person can catch it: subtle production bugs tests cannot catch, large blast radii, and decisions that will shape a year or more of work. For loops with high enough stakes, he writes, you do not want to risk waking up to a broken authentication system, billing engine or public API contract.
The failure he warns of is setting every switch the same way. An all-dark factory leaves a team “stuck tearing everything down four months later”; an all-lit one leaves nobody able to finish reviews in time. He argues that better models will not by themselves make dark operation safe, because the coding agents that feel most capable are trained against their own harness and tools rather than for long-term maintainability, so the safety net — deliberate architecture with good types, test seams and well-defined boundaries — has to live outside the model.
How well established it is: the term is a borrowed metaphor and this framing is one practitioner’s argument, supported by reports relayed from others’ experience rather than by measured results.
Related Terms
Software Factory, Backpressure, Comprehension Debt, Human-in-the-loop, Humans on the loop, Review Bottleneck, Outer Loop