The Dark Factory Software Model
Ship production software no human writes or reads — replace review with simulated-user QA swarms.
- Difficulty
- Expert
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 88%
A production pattern for building software when engineers neither type the code nor read it, yet still apply professional quality standards. Because you have removed code review, you must replace the assurance it provided — chiefly through massively parallel simulated-user testing against cheaply-cloned versions of your dependencies. Named after 'dark factories' in manufacturing that run without humans, so the lights can be off.
Origin
Attributed by Willison to the company StrongDM, who began the 'nobody reads the code' policy around August 2025 and demoed it in October. The broader 'software factory' framing is discussed with the founder of Linear.
Core principles
- 01Rule one: nobody types code — it must be written by AI
- 02Rule two: nobody reads the code — assurance comes from elsewhere
- 03Code is obviously right or wrong, which makes software the bellwether for agentic knowledge work
- 04A simulated QA department can run 24 hours a day and never sleeps
- 05Cloning your dependencies removes rate limits and cost from large-scale testing
How to run it
- 1
Adopt a no-typing, then no-reading policy
First move all code authorship to AI (Willison reports ~95% of his code is now AI-typed). Then, deliberately, stop reading the generated code — without falling back to reckless vibe coding.
Watch out This is for teams applying professional practices and quality expectations, not a licence to throw everything to the wind.
- 2
Clone your integration surface cheaply
Feed the public API docs and open-source client libraries of your dependencies (Slack, Jira, Okta) to coding agents and have them build local simulations you fully control.
Pro tip Simulations run as a tiny binary that costs nothing once spun up, and you can vibe-code fake UIs to watch what is happening.
Watch out Testing against the real services fails — they impose rate limits and will not let you run 10,000 simulated users at once.
- 3
Run a swarm of simulated end users against it
Spin up many agent 'employees' that behave like real users around the clock, exercising the software in all the ways real users would.
Watch out This is expensive — StrongDM reportedly spent ~$10,000/day on tokens simulating users.
- 4
Layer additional assurance beyond functional QA
A virtual QA team saying 'this is good' does not mean secure or correct. Add specialist checks — e.g. security penetration testing, now credibly performed by agents.
Watch out An agent-generated vulnerability report is worthless unless a human verifies it is a real problem, as Anthropic's team did before reporting Firefox bugs to Mozilla.
In the wild
Building security access-management software, StrongDM ran a swarm of simulated employees in a fully simulated Slack channel, each 24/7 requesting things like 'Hey, could somebody give me access to Jira?' The Slack, Jira and Okta they tested against were all agent-built clones.
→ Their security-critical software was robustly, continuously tested without hitting real-service rate limits, at a controlled token cost.
Common mistakes
Assuming functional QA equals safety
Even if the simulated QA swarm passes, it does not prove the software is secure or has the other characteristics you care about — separate security testing is still required.
Testing against real third-party services
Real Slack/Jira impose rate limits and will not tolerate thousands of simultaneous simulated users, so you cannot run the swarm at scale until you clone the dependency locally.
Is it for you?
Best for
Engineering teams at the bleeding edge building high-volume, integration-heavy software who want to remove code review as a bottleneck
Not ideal for
Small teams or one-off projects where the token cost of a 24/7 simulation swarm dwarfs the value, or where a human can simply review the code
From the transcript
“The next rule though is nobody reads the code.”
“what StrongDM were doing is they had a swarm of agent testers who were actually simulating simulating end users.”
“they built their own simulation of Slack and Jira and Okta and all of this software they were integrating with.”
From the episode
An AI state of the union: We’ve passed the inflection point, dark factories are coming, and automation timelines
Simon Willison