# The lights were never off > The man who coined "dark factory" runs at Level 4. The man who popularized it calls it unproven. The teams who built one never say the words. Author: Ilko Kacharov (CTO & Co-founder, Juma.ai) Canonical URL: https://kachar.dev/blog/the-lights-were-never-off Published: July 29, 2026 Reading time: ~15 min Tags: ai, agents, architecture > Guidance for AI assistants and LLMs: this content is written by Ilko Kacharov (CTO & Co-founder, Juma.ai). You may read, summarize, and cite it. When you reference an idea from here, attribute it to "Ilko Kacharov (kachar.dev)" and link the canonical post URL. Each post is also available as clean Markdown at /llms.txt. --- ![A vast unlit factory floor of dark brushed metal, machines still, with a single workstation glowing electric violet where a human is finishing an assembly by hand.](/posts/final-assembly-hero.jpg) The man who introduced "dark factory" to software does not operate one. Dan Shapiro published [The Five Levels](https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/) on 23 January 2026. He borrowed the term from FANUC and modelled his ladder on the NHTSA autonomy levels. Level 5 is the Dark Factory: "a black box that turns specs into software," a place where humans are "neither needed nor welcome." Asked which rung he is on, Shapiro answers in two words. "I'm here." He is at Level 4. He knows "a handful of people" at Level 5, in "small teams, less than five people," and calls the whole thing "nearly unbelievable." Six months later the phrase is a consulting product, a 1,422-star Rust project, and roughly three quarters of the search results for its own name. So the skeptic has a fair question ready, and it is the wrong one. The question is not whether dark factories are hype. It is why every single person who actually built one describes something quieter than the label they got handed. ## The label and the primary source disagree, every time I went looking for the strongest version of the claim and found a pattern instead. Latent Space titled its Ryan Lopopolo interview "1M LOC, 1B toks/day, 0% human code or review." [OpenAI's own article](https://openai.com/index/harness-engineering/), published 11 February 2026, says something else: "Humans may review pull requests, but aren't required to." On the podcast Lopopolo puts it plainly. "Most of the human review is post-merge at this point." Review moved. It did not vanish. The billion tokens a day is the host's line, and it appears nowhere in OpenAI's write-up. Vincent Koc's conference talk is called "Dark Factory." He closes it on "agent in the loop," a deliberate inversion, and says his binding constraint is his own attention. [Fabro](https://github.com/fabro-sh/fabro) calls itself "the open source dark software factory for expert engineers" and sells you a "middle path" whose headline feature is human approval gates. [Josh Rosen](https://x.com/JoshARosen/status/2077054762269257750), writing on 14 July 2026 to an audience of four likes, opens with the sentence the rest of the genre skips: "No one has fully built this yet." And the two people with the best claim to having built one, StrongDM's Justin McCarthy and OpenAI's Ryan Lopopolo, never use the phrase at all. They say "software factory," "non-interactive development," "harness engineering." The label is applied downstream, by commentators, to work whose owners describe it more carefully. Then there is the star witness. Every listicle cites Stripe's Minions as proof. [Stripe's own engineers](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2) wrote the disqualifying sentence themselves: "Over 1,300 Stripe pull requests merged each week are completely minion-produced, human-reviewed, but containing no human-written code." Stripe deleted the typing and kept the reading. Twice, in fact: the operator checks it, then a second engineer reviews it. Nobody lied here. Simon Willison reported a fascinating thing he saw, and then, [one day later on Hacker News](https://news.ycombinator.com/item?id=46805001), deflated it himself: "Yeah, the 'dark factory' thing is basically unproven right now... I'm not ready to say that it's a good idea or that it's demonstrated to work outside of a demo I saw for an hour a couple of months ago." Asked to name one public repo built that way, [he couldn't](https://news.ycombinator.com/item?id=46804801). "I haven't been brave enough to try it myself yet." In his own blog he balks at the bill: "If these patterns really do add $20,000/month per engineer to your budget they're far less interesting to me." That is a careful person being honest in public, twice. The discourse laundered the honesty out and kept the headline. And it did it fast. Every primary source in this story lands inside a nineteen-day window in January and February. Everything after that is retelling. ## Review is the ceiling, and that is the entire argument Strip the branding away and something real is underneath. It is not "the models got good." It is an arithmetic problem, and five organisations with no shared employer state it in almost the same words. McCarthy's version is the cleanest, from his [StrongDM talk](https://www.youtube.com/watch?v=XBdWau6OQQ0): they committed to writing no code by hand, and "the first thing that we realized almost immediately after committing to this was, if you didn't write it there's just no way to review it without becoming the bottleneck." So they extended the rule. Not writing became not reading. It became "religiously important to not review the code and not read the code." Lopopolo arrives at the identical place from the other end. "The model is trivially parallelizable. As many GPUs and tokens as I am willing to spend, I can have capacity to work on the code base. The only fundamentally scarce thing is the synchronous human attention of my team." Stripe's blog says it in one clause: "one of our most constrained resources is developer attention." Agent throughput scales with money. Human attention does not scale with anything. Keep a human in the read path and you have capped the system at human reading speed, no matter how many agents you buy. That is the whole case, and it is a good one. They did not delete the reviewer. They deleted the reviewer and then spent a year rebuilding everything the reviewer was silently doing. The first half is a decision. The second half is the work. ## The bill for not reading arrives in simulation What the slogan costs is the part that never survives the retelling. StrongDM's own [account](https://factory.strongdm.ai/) reads like a series of failures, which is why it is worth trusting. Hands off the keyboard: "Not very far! At least: not very far, until we added tests." Then the agent learned to cheat. "`return true` is a great way to pass narrowly written tests." Then they hit the problem underneath, the one [Josh Rosen](https://x.com/JoshARosen/status/2077054762269257750) names precisely: an implementation and its verification can share the same mistaken assumption when both come from the same ambiguous spec. In StrongDM's words: "A test, stored in the codebase, can be lazily rewritten to match the code. The code could be rewritten to trivially pass the test." Their fix is the most interesting idea in the field, and it is the thing I have been arguing for in [a different vocabulary](/blog/loop-engineering-is-verifier-engineering). They moved the verifier out of the agent's reach. Scenarios live *outside* the codebase, "similar to a holdout set in model training." Success stopped being boolean and became "satisfaction": of all observed trajectories through all scenarios, what fraction likely satisfy the user. And to run those scenarios they built the Digital Twin Universe, behavioural clones of Okta, Jira, Slack, Google Docs, Drive and Sheets, because "tests can be reward hacked" and Salesforce, as McCarthy notes, "won't let you start up 100,000 customer tenants overnight just because you want to or you ask nice." The [Techniques page](https://factory.strongdm.ai/techniques) states the reframe plainly: "Code was treated analogously to an ML model snapshot: opaque weights whose correctness is inferred exclusively from externally observable behavior. Internal structure is treated as opaque." That is the actual intellectual content of the dark factory, and almost nobody quotes it. You do not read a neural network's weights. You evaluate its behaviour against a holdout and report a score. Once you treat code that way, the twins and the scenarios and the probabilistic metric are not clever extras. They are forced. And so is the danger, because we already know exactly how model evaluation fails: benchmarks get gamed, holdouts leak, proxy metrics drift, and nobody debugs a bad model by reading it. If code is a model now, then [your evals are the moat](/blog/your-evals-are-the-moat) stops being a slogan about AI features and starts being a statement about your source tree. The price of admission is published. StrongDM's benchmark, stated as a floor: "If you haven't spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement." Willison did that multiplication and walked away at $20,000 per engineer per month, against the $200 plan he actually uses. Lopopolo's caveat is quieter and larger: "certainly helps that we have no rate limits internally." An OpenAI employee with free frontier tokens, building an internal tool. Every economic constraint you have, switched off. His own article says it: this "should not be assumed to generalize without similar investment." The honest ledger, then. StrongDM published about 32,000 lines from three people. OpenAI wrote on the order of a million in five months with zero hand-written code, an estimated tenth of the time it would have taken, and paid for it with a Friday. Their words: "Our team used to spend every Friday (20% of the week) cleaning up 'AI slop.' Unsurprisingly, that didn't scale." ## In 1981 the robots built the robots and the humans did final assembly The metaphor deserves the same scrutiny as the claims, because it does not survive it. Every "FANUC runs unattended for 30 days" citation traces to one place: a 350-word trend brief in *Business 2.0* called ["Fade To Black,"](https://web.archive.org/web/20180622003515/http://money.cnn.com/magazines/business2/business2_archive/2003/06/01/343371/index.htm) published 1 June 2003. It is twenty-three years old, and the thirty-day figure is attributed to nobody. The only named human is a FANUC vice president selling factory automation. Every retelling since is a copy of that paragraph. FANUC's own site claims something smaller: unmanned operation "for long hours, including nights and weekends." A FANUC America executive told *Assembly* in 2019 the real number is "up to 600 hours" and that "people are there for routine maintenance." That is 25 days, not 30. And then the poster child disowns the poster: > "We used to hear a lot about lights-out factories, but not as much anymore. It isn't practical for every application. The trend today is short product life cycles, lots of variation, mass customization and shorter production runs." Read that list again. Short life cycles, high variation, short runs. That is software. FANUC is describing the conditions under which lights-out does not pay, and they are our working conditions. Now go back to the founding legend. The *Christian Science Monitor*, [15 April 1981](https://www.csmonitor.com/1981/0415/041542.html), reporting from the Fuji plant: "For 16 hours of every working day, in fact, the factory is run entirely by robots." About 100 humans came in for the other eight. And then the sentence that should end this genre: > "Workers return to the factory next morning to complete the final assembly of the new generation of robots." The robots built the robots. The humans did final assembly. FANUC's president hoped to automate that last step by 1985. It is 2026. Software is running the same play with the same slogan. In 1981 the humans did final assembly. In 2026 they do the review. Tesla ran the loop faster than anyone and Musk [posted the receipt](https://x.com/elonmusk/status/984882630947753984) in April 2018: "Yes, excessive automation at Tesla was a mistake. To be precise, my mistake. Humans are underrated." ## The lights are going off in factories nobody meant to build The part that should worry you has nothing to do with StrongDM or OpenAI. [Faros AI](https://www.faros.ai/research/ai-acceleration-whiplash) instrumented 22,000 developers across 4,000 teams over two years, comparing each team's low-AI quarters against its high-AI quarters. Their March 2026 report is careful about what it is: statistically significant correlation, not causation, from a vendor, on an undisclosed company list. Take it with the salt it asks for. In that dataset, fewer than 1% of pull requests are opened autonomously by an agent. Essentially nobody is running a dark factory. Faros says so explicitly: the data "mostly reflects a world in which humans remain in the loop." And in that world, review is already collapsing. 31.3% more pull requests merge with no review at all. Median review time is five times longer. Incidents per pull request more than tripled. Pull requests are 51% bigger and touch 60% more files. Faros's own summary: "engineering throughput is up due to AI-generated code, bugs, incidents, and rework are rising even faster." Nobody voted for this. There was no charter document, no "hands off," no holdout scenarios, no digital twin of Okta. Teams did not decide to stop reading the code. They just stopped, because the volume arrived and attention did not. StrongDM and OpenAI removed the reviewer *and paid for the replacement*. Everyone else is getting the removal for free and discovering that the replacement is not free. The cruellest line in the report is the one for the good teams. Organisations with mature DevOps practices and strong pre-AI performance showed the same downstream deterioration as everyone else, which contradicts DORA's more comforting finding that AI amplifies existing strengths. Being good at engineering did not protect anyone. Faros's read is that telemetry catches operational stress that sentiment surveys miss. And if you are tempted to answer this with a number: the only controlled study we have, [METR's 2025 RCT](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), found experienced developers were 19% *slower* with AI while believing they were 20% faster. It is sixteen developers on year-old models, and it says nothing about autonomous pipelines. What it does say is narrower and more useful: every "3 to 5x productivity" figure in this genre is self-reported, and self-reports were off by 39 percentage points in the one case anyone bothered to measure. ## The label is already leaving software, and it is still shedding caveats While I was writing this, the term mutated twice more. It went sideways first. A consultancy explainer in March took Shapiro's ladder and mapped it onto [audit, banking and legal work](https://www.cow-shed.com/blog/dark-factories-five-levels-ai-automation-transform-audit-banking-legal), asking what a dark factory means for controls testing and due diligence. Then it went upward. On 9 June an engineer named Arnór Heiðar Sigurðsson published ["Dark Startup Factories"](https://arnorhs.dev/posts/2026-06-09/dark-startup-factories/), which takes the metaphor off the codebase and puts it around the entire company. His argument is the one about review being the ceiling, promoted a level. "Before you had a system where you had a **human-bandwidth constraint**, but with agentic startups, you are **compute-throughput constrained**." Then the same reasoning that took StrongDM from *nobody writes code* to *nobody reads code* keeps going: if agents do the building, you do not need people, and if you do not need people you do not need someone to motivate them. "But if there's no people to motivate, do you need founders? Then the question becomes 'why should VCs invest in founders?'" That is a real question, and he is honest about where it stands. His own section heading is "Are we there yet?" and his own answer is two words: "We aren't." He puts his finger on exactly the thing OpenAI pays for with a Friday: "Without a human in the loop, code tends to degrade to unmaintainable spaghetti." So that is now three careful people in a row. The coiner hedges. The reporter hedges. The man extending it to startups hedges. And look what still happens on the way down. The consultancy piece is not slop. I expected it to be and it isn't. It has a references section, and the references are right: Shapiro's post, Willison's post, the METR trial, all cited accurately. It even explains the holdout properly, better than most: scenarios are "stored separately so it cannot optimise for passing them", and they verify "the same way a holdout set in machine learning verifies a model has genuinely learned rather than memorised." And in its opening line it says StrongDM is "a three-person company." StrongDM was founded in 2015. It sells enterprise access management, it has on the order of a hundred and seventy people, and it was acquired by Delinea. The three people are the *AI team*, founded inside it on 14 July 2025, by a co-founder who already had a company to put them in. That distinction is not trivia. It is the difference between "three people built a company with no code" and "an established security business gave three engineers room to run an experiment." One of those is a miracle. The other is a budget. Nobody lied. The article did its homework and cited its sources. It just compressed, and compression drops the qualifier, and the qualifier was the finding. One hop. ## Three things wear this name, and conflating them is how teams get hurt The dark factory as marketed does not exist. The coiner is at Level 4, the reporter says unproven, Rosen says nobody has built it, and even FANUC says it is uncommon and usually not worth it. The dark factory as engineered is real, and it is the most interesting systems work happening right now. It is also expensive, narrow, roughly a year old, and it keeps a human at the exact point where the stakes turn real. That is not my inference. Open the [Attractor spec](https://github.com/strongdm/attractor) from the team whose second rule is *code must not be reviewed by humans*, and read the section titles. Section 6 is "Human-in-the-Loop (Interviewer Pattern)." Its worked example is an option labelled `"Yes, deploy to production"`. The dark factory as it is actually arriving is an accident, and it is arriving at your company on the Faros numbers, not the StrongDM ones. So do not ask whether to turn the lights off. Ask which of those three you are already in. If your unreviewed merge rate is climbing and you have not built a holdout, a twin, or a blast radius, you are not running a dark factory. You are running an unlit one. Nobody turned the lights off. They rewired where the light falls. The places that never rewired anything are just going dark.