Dark Factory

The end state of loop engineering: a software production system that runs with the lights off. Autonomous agents build, test, and ship around the clock while humans define intent and review outcomes -- not code. Named after fully automated factories that need no human on the floor. Real for a handful of tiny elite teams; contested as a general model.

The Pattern

"At level 5, it's not really a car any more. [...] It's a black box that turns specs into software." -- Dan Shapiro (source)

The dark factory is the end state of loop engineering: software production that runs with the lights off. The name is borrowed from manufacturing's lights-out factories -- like FANUC's plant where robots build robots in the dark -- and Dan Shapiro adapted it as the top rung of a five-level ladder of AI autonomy (Dan Shapiro). Autonomous agents build, test, and ship around the clock; humans define intent and review outcomes, not code.

The clearest public example is StrongDM, whose charter is blunt -- "code must not be written by humans" and "code must not be reviewed by humans" (StrongDM). Its CTO Justin McCarthy gives a deliberately provocative gauge of how far they have gone: "If you haven't spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement" (Stanford CodeX). With no line-by-line review, trust is engineered in elsewhere: agents prove each change against a "Digital Twin Universe" of services like Okta and Slack, backed by layered verification, red-team agents, and full traceability of every action to a human-defined intent.

Why It Matters

The defining shift is not the absence of humans but the relocation of their effort -- away from writing and reviewing code, toward two scarce skills: harness engineering (architecting the factory) and "intent thinking," stating precisely enough what correct looks like that a spec can carry it.

It also scales by composition. The natural shape is a factory of pipelines: each team runs its own pipeline -- a loop and a harness on its project -- and those pipelines compose into one organization-wide factory. That is what orchestration frameworks like Steve Yegge's Gas Town, a "coding agent factory" that coordinates many agents under a single foreman, are reaching for (Steve Yegge). It puts the dark factory as much in scaling the org -- org shape and maturity -- as in individual practice.

It is the most contested pattern in the theme, on two fronts:

• Does it generalize? The credible examples are tiny teams -- StrongDM's factory was described by just three engineers (Stanford CodeX). Spotify is factory-adjacent (engineers reportedly not writing code since December 2025, ~650 agent PRs a month; consultancies claim 3-5x gains), but most other claims are experiments (BCG Platinion). Whether it holds at enterprise scale is unsettled.
• Is it safe? Simon Willison -- who coined "prompt injection" -- warns the still-unsolved "lethal trifecta," once normalized as routine, could produce an AI "Challenger disaster," and that for security-grade software "97% effectiveness is a failing grade" (Lenny's Podcast). A security company going lights-off only sharpens the question: "built by agents, tested by agents, trusted by whom?" (Stanford CodeX).

So read the dark factory as an aim, not a default. The case is strongest where the cost of an error is bounded and the proving system can be made airtight, weakest where it cannot. But even as an aspiration it earns its keep: it forces the question "what verification would let me automate this?" -- and that pushes you to build the tests, simulations, and traceability that make incremental autonomy safe, long before you ever turn the lights all the way off.

Last reviewed: 2026-06-25