An AI dark factory ships reviewed, deployed code from a spec with no human in the loop. Here's what that means and how the five autonomy levels get you there.
What is an AI dark factory in coding? #
An AI dark factory is a code repository that ships its own code with no human reviewing or approving the work along the way. You feed it a spec, usually a PRD (product requirements document) or a ticket describing what to build next, and the system plans the work, writes the code, tests it, validates it, and opens a pull request (or merges outright) on its own. The term borrows from manufacturing, where a “dark factory” runs machines in the dark because no human workers need to be on the floor. Applied to software, it means a codebase that can grow and ship features without a person reading a diff.
This isn’t a hypothetical. As coding-capable LLMs and the harnesses wrapped around them have gotten more reliable, teams and individual builders have started running real experiments where an agent takes a spec all the way to production. It’s still early and it’s not reliable for every kind of application, but the pattern is spreading fast enough that it’s worth understanding on its own terms.
TL;DR #
- An AI dark factory is a repo that turns a spec into shipped, validated code with zero human review in the loop. - The concept sits at the top of a five-level autonomy scale, borrowed from self-driving car analogies, running from “spicy autocomplete” to full hands-off shipping. - Most serious builders currently operate at level three, where the agent writes the code but a human still plans and validates, and that remains the most reliable level for production work today. - A working dark factory needs a harness, not just a strong model: planning steps, a separate critique or review agent, defined validation strategy, and a clear workflow loop (prime, plan, implement, validate, commit, PR). - Coding agents run in headless mode(no interactive terminal session) so the whole loop can trigger automatically, often off a GitHub issue that represents the spec. - Dark factories work well for scoped, testable projects like games or internal tools, and are considered experimental for complex, high-stakes production codebases. - Building one starts with a solid PRD, since the spec is the only real input the system receives before it starts working autonomously.
What are the five levels of AI coding autonomy? #
The five-level framework, popularized by writer Dan Shapiro using a driving analogy, maps how much control a developer hands over to an AI coding agent.
Level zero is the most manual: AI is used only for “spicy autocomplete,” small in-line suggestions while a developer writes almost all the code by hand. It’s the equivalent of driving stick shift.
Level one and two move into pair-programming territory. The agent starts generating boilerplate or small functions autonomously, but the developer is still directing most of the actual writing and stitching pieces together.
Level three is where a coding agent writes most of the code, and the developer is effectively hands-off the wheel for the writing itself. The human is still deeply involved in planning what to build and validating that it works once it’s done. This is where most experienced AI-assisted developers operate today, and it’s widely considered the most reliable level for shipping real production work, because a person is still catching mistakes before they land.
Level four starts removing the human from parts of the planning and validation loop, with the agent taking on more of that responsibility itself.
Level five is the dark factory: there’s no steering wheel at all for the specifics. The only input is a high-level destination (the spec or PRD), and the agent figures out the entire path: planning, implementation, testing, validation, deployment. The human sets direction, not the route.
Why does level three remain the safest bet for most teams? #
The tradeoff at level three is that the human is still the bottleneck. Every feature needs a person to review the plan and check the output before it ships, which limits how fast a team can move even if the coding agent itself is fast. But that bottleneck is also the safety net. Because a person is validating the work, mistakes get caught before they reach production.
Moving to level four or five removes that bottleneck, which is exactly why it’s appealing: work ships far faster when nobody has to review it. But it only works if the harness around the agent is reliable enough to catch its own mistakes, since there’s no longer a human doing that job. Skipping straight to a dark factory without first learning to work with AI coding assistants at the lower levels is a good way to end up shipping broken or insecure code with nobody noticing.
How does an AI dark factory actually work? #
A dark factory isn’t just “give a model a prompt and let it write files.” It’s a harness, an engineered system of steps and checks that wraps the coding agent so it can operate reliably without supervision. The pieces that tend to show up in a working setup:
A spec as the single input. Usually a PRD or a ticket (commonly represented as a GitHub issue) describing what to build. This is the only thing a human provides before the loop starts.
Remy doesn't write the code. It manages the agents who do. #
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
A defined workflow loop. A repeatable sequence the agent follows for every piece of work: something like prime (load context), plan, implement, validate, commit, open a pull request. Having this loop explicit, rather than improvised per task, is what makes the system predictable.
A second agent for critique. Rather than trusting a single agent to both write and grade its own work, a separate agent reviews the primary builder’s output, acting as an internal reviewer before anything ships.
A validation strategy. Automated tests, checks, or criteria that let the system confirm its own work actually meets the spec, since no human is doing that check manually.
A headless coding agent. The agent runs without an interactive session, since nobody is present to answer prompts or approve steps live. Most major coding agents support this mode.
A repository structure that tracks specs as issues. Each incoming spec becomes a ticket, the workflow processes it, and the output is a pull request representing a fully built, self-validated feature, ready to merge without a human review pass.
The quality of the resulting system depends heavily on how well each of these pieces is engineered up front. That’s the real work in building a dark factory: not writing a clever prompt, but designing the scaffolding so the agent can plan, build, and check its own work without a person catching what it misses.
What kinds of projects suit a dark factory today? #
Scoped, testable, incrementally extendable projects are the best current fit. Games are a good example: it’s easy to keep adding discrete features (a new enemy type, a new upgrade, a new level) without the application becoming an unmanageable pile of feature bloat, and it’s straightforward to see whether a feature works by playing the result.
Applications with fuzzier requirements, or ones where correctness is hard to check automatically, are harder to trust to a fully autonomous loop. A dark factory can produce a real, usable application (a working tower-defense game or an internal chat tool that searches a content library, for instance), but the underlying approach is still considered experimental for production-grade software in general. The honest framing is: a dark factory is a genuine glimpse of where AI coding is heading, not yet a default choice for mission-critical systems.
Frequently Asked Questions #
Is an AI dark factory the same as vibe coding?
No. Vibe coding usually implies loosely prompting a model and accepting whatever it produces with little structure. A dark factory still involves heavy upfront engineering: a defined workflow, a critique agent, and a validation strategy. The agent is trusted with full autonomy, but only because a deliberate harness was built to make that autonomy reliable.
Do I need a custom-built harness, or can existing coding agents do this out of the box?
Most mainstream coding agents (Claude, Codex, and others) support headless, non-interactive execution, which is a prerequisite. But headless execution alone isn’t a dark factory. The planning steps, review/critique layer, and validation checks around the agent are what make the system trustworthy enough to skip human review, and those need to be designed deliberately.
What’s the input to a dark factory?
#
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
A spec, typically a PRD or an equivalent requirements document, often represented as a ticket or GitHub issue. That’s the only thing a person supplies. Everything after that, planning, coding, testing, and shipping, happens without further human direction.
Should every team move toward level five autonomy?
Not necessarily, and not quickly. Level three, where a human still plans and validates while the agent writes the code, remains the most reliable level for production work generally. Level four and five make sense once a team has already built confidence and tooling at the lower levels, since removing human review only works if the automated checks are strong enough to replace it.
What happens if the dark factory’s validation misses a bug?
Since no human is reviewing the code before it merges, whatever the validation strategy fails to catch ships as-is. This is the core risk of the approach, and it’s why the validation and critique steps built into the harness matter more than the raw capability of the underlying model.