How to Build an AI Dark Factory With a Claude Code Skill
A practical guide to installing a coding skill that turns a PRD into an autonomous "dark factory" harness with review, testing, and deployment.
What is an AI dark factory?
An AI dark factory is a repository that ships its own code. You send in a spec, usually a PRD (product requirements document) or a GitHub issue, and the system plans the work, writes the code, reviews it, validates it, and merges it without a human touching the keyboard. The term borrows from manufacturing, where a “dark factory” runs machines in the dark because no people are on the floor. Applied to software, it means a coding agent (or a small team of agents) handling the entire loop from spec to shipped code.
This isn’t a new coding assistant or a smarter autocomplete. It’s a harness: a structured system of workflows, review steps, and deployment gates built around a coding agent so that its output can be trusted without a human checking every line.
TL;DR
- A dark factory is a repo that takes a PRD or GitHub issue as input and outputs fully reviewed, tested, and deployed code with no human in the loop.
- The setup described here uses a Claude Code skill that interviews you about your workflow and autonomy preferences, then scaffolds the entire harness for you.
- Work is fed in through a GitHub issue queue, where each issue triggers a workflow of planning, implementation, validation, and pull request review.
- The system relies on blue-green deployment so new code can go live and roll back safely if validation fails after the fact.
- This maps to the top of Dan Shapiro’s five levels of AI coding, where level three (agent writes the code, human plans and validates) is still the most reliable level for most people, and levels four and five (dark factory) trade some reliability for speed and removing the human bottleneck.
- The skill was built from months of trial and error on a real dark factory project, an agentic chat app that searches a YouTube channel’s transcripts and course content, built without the creator reading a line of the shipped code.
- Dark factories are still experimental. They work well for scoped projects like games (easy to layer on more features) and are less proven for large, complex, or safety-critical production code bases.
How does the skill actually build the harness?
The skill is installed into an empty folder (or, in theory, an existing code base, though that path is less tested) alongside your PRD. From there, the process runs in two phases.
First comes an interview. The skill asks a series of questions before writing any code: how much autonomy you actually want, what your preferred coding workflow looks like (prime, plan, implement, validate, commit, PR is one example cited as a personal default), which supporting skills you want wired into the harness, and what your validation strategy should be, meaning how the system checks its own work before calling something done. This step matters because the harness gets modeled after how you already work, which makes it easier to keep customizing later instead of fighting an unfamiliar system.
Second, once the interview wraps, the skill scaffolds the full harness: the workflow structure, the review steps, and the deployment pipeline, based on patterns established from building a working dark factory over months of iteration.
How does work flow through a dark factory?
Once built, the factory is typically organized as a GitHub repository, and each unit of work comes in as a GitHub issue. That issue is the equivalent of a ticket: a spec for one feature, fix, or change.
From there, a single workflow drives the rest of the process for that issue: planning, implementation, testing and verification, and finally a pull request. That PR is where the final review and shipping decision happens, and in a fully autonomous setup, that whole loop runs without anyone manually stepping in between stages. Issues that don’t meet the bar can be rejected and closed; the ones that pass go all the way through to a merged, deployed change.
The coding agent underneath (Claude, or others like Codex, Amp, or similar tools) needs to run in what’s called headless mode, meaning it operates without a person interacting with it turn by turn. Nearly every major coding agent supports this mode, which is part of what makes dark factories realistic now in a way they weren’t a year or two ago.
Why does blue-green deployment matter here?
Blue-green deployment is a release pattern where two environments (call them “blue” and “green”) run in parallel. One is live in production, the other gets the new code. Once the new version passes its checks, traffic switches over. If something goes wrong, you switch back instantly.
For a dark factory, this matters because there’s no human standing between “code merged” and “code live.” If an autonomous agent ships something that breaks in production, blue-green deployment gives the system (or the operator) a fast, low-drama way to roll back without scrambling through a manual hotfix. It’s one of the safety nets that makes trusting an agent with deployment more reasonable than just merging straight to a single live environment.
Where does a dark factory fit on the autonomy spectrum?
One coffee. One working app.
You bring the idea. Remy manages the project.
It helps to place dark factories against Dan Shapiro’s five levels of AI coding, which uses driving as an analogy:
Level zero is manual coding with AI used only for “spicy autocomplete,” filling in small snippets. Levels one and two turn AI into more of a pair programmer, generating boilerplate but still supervised closely. Level three is where an agent writes most of the code while a human still plans and validates, hands off the actual typing but very much in the loop for direction and review. This is described as where most developers currently are, and for good reason: it’s the most reliable level because a person is still checking the work.
Levels four and five remove the human from planning and validation entirely. There’s no steering wheel for individual decisions, only a “console” for higher-level direction, the PRD or spec. You point at a destination; the agent figures out the route, writes the code, tests it, and ships it. The dark factory lives at this end of the spectrum. The upside is that you stop being the bottleneck. The tradeoff is that you need serious confidence in your harness, because you’re no longer catching mistakes before they ship.
Is a dark factory reliable enough for production code?
Not for everything, and not yet for most serious production systems. The honest framing is that this is a starting point and a preview of where AI coding is heading, not a guarantee of production-grade output across arbitrary code bases.
Where it does work well is in scoped, easy-to-extend projects. Games are a good example: it’s simple to keep adding features (new enemies, new mechanics, new stats) without the application becoming bloated or unfocused, which makes games a useful stress test for how far a dark factory harness can be pushed. An agentic chat application that searches through a large body of transcripts and course material is another example of something built end-to-end this way, with the shipped code never manually reviewed line by line, largely as a way to prove the concept.
The honest caveat: reliability depends heavily on how well-engineered the harness is, not just on how capable the underlying model is. A dark factory built carelessly on a good model will still produce unreliable results. The value of a pre-built skill is that the planning structure, review steps, and validation strategy are already encoded from prior trial and error, rather than something you have to work out from scratch.
Frequently Asked Questions
What’s the difference between a dark factory and normal AI-assisted coding?
Normal AI-assisted coding, even at higher levels of autonomy, still keeps a human in the loop for planning and validating the work before it ships. A dark factory removes that step: you submit a spec, and the system plans, builds, tests, and deploys the result on its own.
Do I need a PRD before I can use this?
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
Yes. The skill takes a PRD or a similarly detailed spec document as its starting input. It assumes you already have a way to produce that higher-level plan; the skill itself handles turning that plan into a working, autonomous harness, not writing the initial product spec from scratch.
Which coding agents work with this setup?
The approach relies on running a coding agent in headless mode, meaning it operates without turn-by-turn human interaction. Agents like Claude Code, Codex, and Amp support this mode, so the harness can be adapted to whichever agent you already use.
Is this the same as vibe coding?
No. Vibe coding usually implies loose, unstructured trust in an agent’s output with minimal process. A dark factory still involves significant upfront engineering: structured workflows, a separate review or critique step, defined validation strategies, and deployment safeguards like blue-green rollouts. The agent has full autonomy over the code base, but only inside a carefully built harness.
Should most developers be running a dark factory right now?
Not necessarily. Level three, where an agent writes the code but a human still plans and validates, remains the most reliable setup for most work today. Dark factories are worth exploring as an experiment or for well-scoped projects, but they’re not positioned as a replacement for human review across serious production systems yet.
