A dark factory turns a planning doc into shipped code with no human reviewing it. Here's how AI software factories work and if they're ready.
What is an AI software factory? #
An AI software factory, also called a “dark factory,” is a pipeline where a planning document goes in and shipped code comes out, with no human reading the code in between. You write a PRD (product requirements document), the system breaks it into individual tasks, coding agents build each one, other agents review the pull requests, and the whole thing merges and deploys to production on its own. The term comes from manufacturing: a “dark factory” is a plant so automated it can run with the lights off because no people are on the floor. Applied to software, it means no human eyes on the diff before it ships.
TL;DR #
- An AI software factory takes a high-level planning document as input and produces deployed, working code as output, without a person reviewing individual pull requests. - The concept is built on five levels of AI coding autonomy, a framework popularized by Dan Shapiro, ranging from AI-assisted typing at level one to full autonomous decision-making at level five. - Most professional AI-assisted coding today sits around level three, where an agent writes the code but a human plans and validates each ticket. - A working prototype of this idea has already been built and deployed: an AI tutor chatbot created end to end by a dark factory pipeline with zero lines of code personally reviewed. - The honest verdict right now is that dark factories are reliable enough for prototypes and spikes, not yet proven for complex or critical production systems. - The next phase of testing this idea involves building something intentionally harder to automate, like a video game, to find where the reliability actually breaks down. - Tools like Archon are being used as the underlying orchestration layer that drives planning, task splitting, and agent coordination inside these pipelines.
Other agents start typing. Remy starts asking. #
Scoping, trade-offs, edge cases — the real work. Before a line of code.
How does a PRD-to-production pipeline actually work? #
The pipeline starts where most software work starts: a document. Someone (or some AI-assisted process) writes a PRD describing what needs to be built, at a level of detail similar to what a product manager would hand to an engineering team. From there, the factory takes over:
Decomposition. The system parses the PRD and splits it into discrete tasks or tickets, the same way a human tech lead would break a feature down into tickets in a project tracker.Building. Coding agents pick up each task and write the actual implementation, generating code, tests, and whatever else the task requires.Review. Instead of a human opening a pull request and reading the diff, another agent (or set of agents) reviews the work against the original requirements and codebase conventions.Merge and deploy. Once a task passes review, it merges and moves through to deployment, straight to production, without a human gate.
The core distinction from normal “AI-assisted coding” is that step 3 removes the person. In most agentic coding setups today, a human is still the last checkpoint before code ships. A dark factory removes that checkpoint entirely and replaces it with automated review.
What are the five levels of AI coding autonomy? #
The five-level framework (originating from a blog post by Dan Shapiro) maps AI coding autonomy the way self-driving car levels map vehicle autonomy:
Level one is basically autocomplete: AI assists a human who is still writing and deciding everything.Level two has AI generating larger chunks of code, but a human is heavily editing and directing nearly every decision.Level three is where an agent writes essentially all the code for a given task, but a human is deeply involved in planning that task and validating the result before it ships. This is where most serious professional AI coding workflows sit today.Level four starts handing over more of the small in-the-moment decisions to the agent, with humans stepping back to a higher-level supervisory role.Level five is the dark factory itself: there’s no steering wheel left. A human still sets direction through a planning document, but every smaller decision, including what counts as “done” and what gets merged, is made by the system.
The driving analogy is useful because it captures the risk tradeoff plainly. Nobody argues a level five self-driving car is inherently bad, the question is whether it’s reliable enough for the roads it’s driving on. The same question applies to code: is the factory reliable enough for the kind of software you’re shipping?
Is a dark factory reliable enough to use right now? #
It depends heavily on what you’re building. The honest answer from anyone actually running these experiments is: yes for some things, not yet for others.
#
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
A real test case already exists. An AI tutor chatbot, an agentic chat application that answers questions grounded in a creator’s YouTube content and course material, was built entirely through a dark factory pipeline. No line of code in that application was written or reviewed by a human directly. It’s live in production and usable today. That’s a genuine proof point that the level-five approach can produce a working, deployed application.
But that application is also relatively simple: a chat interface wired to a knowledge base. It doesn’t stress-test complex state management, tricky edge cases, or large, tangled codebases where subtle bugs hide. The next stage of testing this concept intentionally aims for more complexity, with video games floated as a good candidate specifically because they resist becoming a “feature-bloated mess” the way simpler web apps do. There’s almost always another feature, another system, another layer of complexity you can add to a game, which makes it a better stress test for how far a factory-style pipeline can be pushed before things break down.
For now, the realistic use case being talked about is prototyping and spiking product ideas. Cheap, fast large language models make it economically reasonable to generate a lot of throwaway code just to validate whether an idea is worth pursuing further. That’s a lower-stakes environment than a production system a business depends on, and it’s where dark factories look most immediately useful.
Why are companies already experimenting with this? #
Three things are improving at the same time: the underlying large language models, the coding agent harnesses built around them, and the broader workflows that stitch agents together into pipelines. None of these alone would make a dark factory realistic. Together, they’re starting to close the gap.
That’s part of why this isn’t purely theoretical. Businesses are reportedly implementing dark-factory-style systems for at least portions of their development process already, not necessarily for their most critical systems, but for the kind of work where speed matters more than perfect certainty: internal tools, prototypes, and experiments where the cost of a mistake is low and the cost of slow iteration is high.
There’s also a second-order benefit for anyone building these pipelines: removing the human safety net forces the harness itself to get better. If nobody is checking the agent’s work, every weakness in planning, task decomposition, and automated review becomes visible fast. That pressure tends to produce more reliable agentic workflows overall, even for people who never plan to run a fully autonomous factory in production.
What does the underlying tooling look like? #
Under the hood, these pipelines tend to rely on orchestration layers that manage planning and task routing rather than a single monolithic agent doing everything. One example referenced in this space is Archon, an open-source workflow tool used to drive the process of turning plans into tasks and tasks into code. The factory concept sits on top of tooling like this: the orchestration layer handles the mechanics of splitting and routing work, while the “factory” is the opinionated set of rules, checks, and pipeline steps wrapped around it that determines how autonomous the whole system gets to be.
Frequently Asked Questions #
What’s the difference between an AI software factory and normal AI-assisted coding?
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Normal AI-assisted coding still has a human reviewing pull requests before anything merges or ships. A software factory (level five autonomy) removes that human review step entirely: the agent’s output goes straight to merge and deployment based on automated review alone.
Where does the term “dark factory” come from?
It’s borrowed from manufacturing, where a fully automated plant can run with the lights off since no human workers are on site. Applied to coding, it describes a pipeline that can run without a human looking at the code.
Can a dark factory build complex, production-critical software today?
Not reliably yet, based on current public experiments. Simpler applications, like a chatbot grounded in a knowledge base, have been built successfully end to end. More complex systems, like games with many interacting features, are the next stress test being used to find where reliability actually breaks down.
What’s the most practical use case for this right now?
Prototyping and spiking product ideas. Because running large numbers of coding agent tasks has gotten cheap, it’s economically reasonable to generate a full working prototype just to test whether an idea is worth building for real, even if you wouldn’t trust that same pipeline with your production codebase yet.
Do I need to build my own orchestration system to try this?
Not necessarily. Open-source orchestration tools already exist for managing agent workflows, and some open-source software factory projects are being built specifically so people can install a working pipeline with minimal setup rather than building one from scratch.