How to build an AI dark factory that ships its own code

Picture a repository that reads a one-page spec, plans the work, writes the code, tests it, fixes its own bugs, and opens a pull request ready to merge — all before you've finished your coffee. No human touched a single line. That's not science fiction anymore. It's a pattern some engineering teams have started calling the "dark factory," and it's quietly becoming one of the most talked-about workflows in AI-assisted development.

The term comes from manufacturing. In industrial manufacturing, a "dark factory" (sometimes called a "lights-out factory") is a facility that operates entirely through robotics and automation. Apply that idea to software, and you get a codebase where AI agents handle the entire development loop — planning features, writing code, running tests, and deploying — without a human reviewing or approving any of it. No pull request sitting in someone's inbox. No engineer merging a branch at the end of the day.

This guide breaks down what a dark factory actually is, why it's suddenly realistic, and how you can start building your own version of it — even if you're not ready to remove humans from the loop entirely just yet.

What exactly is an AI dark factory?

At its core, a dark factory is an AI coding pipeline that plans, writes, tests, and deploys code autonomously — no human code review in the path to production. The core architecture is planner → generator → evaluator → deployment, often with a monitoring layer watching for anything that goes wrong.

It's worth being precise about the difference between this and the AI-assisted workflows most developers already use. An AI coding agent harness uses AI agents to produce code that humans then review and approve. A dark factory removes the human review step entirely. The harness has a human gate before deployment; the dark factory doesn't. That single distinction — whether a human sits in the approval loop or not — is what separates "AI helps me code" from "the codebase ships itself."

The mechanism that makes this safe (relatively speaking) isn't blind trust in the model. A dark factory doesn't just give AI agents raw access to a codebase and hope for the best. It uses a harness: a structured environment that controls what agents can access, what actions they can take, and how their work gets reviewed. Think of a harness as the scaffolding around an agent. It defines the boundaries within which the agent operates.

Is anyone actually running this in production?

Yes, but with an important caveat: most of what's running today still keeps a human somewhere in the chain. Full dark factories — where no human reviews anything before deployment — are still rare in production. What's more common are dark factory components running inside human-supervised pipelines.

The examples are striking, though. Stripe's Minions system generates over a thousand AI-written pull requests per week. But humans still review them. It's a dark factory that stops one step before the lights go fully out. Similarly, Shopify's approach, sometimes called "Roast," uses AI agents to identify and fix code quality issues — but within a defined scope, with humans approving what gets merged.

There are more experimental efforts pushing further. One widely discussed writeup described teams reporting a million lines of code, none of it hand-written, built in a tenth of the usual time, with both teams reporting 3–10x sustained velocity. Costs matter here too — one report noted StrongDM reported roughly a thousand dollars per day per engineer-equivalent, which is still way cheaper than a salary.

Why does full autonomy fail so spectacularly when it fails?

This is the part worth taking seriously before you get excited about removing all your review gates. The risk isn't that agents are dumb — it's that mistakes compound at agent speed. Full autonomy is not free. The same systems that let agents move fast also let them make large mistakes fast. If a planning agent produces a flawed plan, every downstream agent builds on that flaw.

And because the whole pipeline runs without anyone watching, by the time the error surfaces in testing or deployment, the system may have produced thousands of lines of code based on a wrong assumption. That's the nightmare scenario — not one bad file, but an entire architecture built on a bad premise.

There's also an operational risk that doesn't get talked about enough: agent sprawl. Once teams start spinning up specialized agents for every task, coordination gets harder, debugging becomes nearly impossible, and agent sprawl is the dark factory equivalent of microservices bloat — the same organizational problem, just in a different medium.

This is why the safeguards matter as much as the ambition. Responsible implementations lean on automated test suites that must pass before any merge, agent harnesses that limit what the agent can write to, isolated execution environments that prevent cross-agent contamination, full audit logs of every agent action, and staged rollout of permissions that expand only as the system proves it can be trusted.

How do you actually start building one?

You don't need to build a custom orchestration engine from scratch to experiment with this pattern. The most accessible entry point right now is Claude Code running in headless mode, wired into your existing CI/CD pipeline. As one analysis put it, the practical path is to start with an existing harness (Claude Code in headless mode is a popular choice), wire it to your CI/CD pipeline, and progressively remove human checkpoints as confidence builds in specific task categories.

Here's the general shape of that build:

Step 1: Set up headless mode

Claude Code's headless mode documentation covers the -p (print) flag, which is the foundation of any automated pipeline. When you add this flag, Claude Code processes one prompt, runs the full agent loop (thinking, calling tools, editing files) and then stops automatically. No terminal UI, no waiting for you to click approve — just input in, result out.

Step 2: Wire it into GitHub Actions

Anthropic maintains an official action for exactly this purpose. Check out the Claude Code GitHub Actions documentation for the full setup. Claude Code GitHub Actions is a GitHub Action that runs Claude Code inside your repository's workflows. Mention @claude in a pull request or issue comment to have Claude analyze code, implement changes, and push commits. You can also configure it to run automatically on a schedule or in response to any GitHub event, which is what turns a helpful assistant into an actual pipeline stage.

A minimal setup needs three things: install Claude Code, expose the API key as a secret, and the call itself — npm install -g @anthropic-ai/claude-code as a separate step in the workflow, and the ANTHROPIC_API_KEY as a repository secret, never hardcoded in the workflow itself.

Step 3: Build the skill that defines your workflow

This is where the real customization happens. Claude Code's skills documentation explains how these work under the hood. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way. Skills add optional features: a directory for supporting files, frontmatter to control whether you or Claude invokes them, and the ability for Claude to load them automatically when relevant.

If you're building your first skill, don't write it entirely from scratch. Anthropic ships a guided tool for exactly this. Anthropic publishes an official skill-creator skill that runs a guided loop: it captures what you want the skill to do and when it should trigger, interviews you on edge cases and output format, writes the SKILL.md, then tests it with evals and helps you refine the description for better triggering. It is the recommended starting point for any new skill. You can find community and official examples in the anthropics/skills repository on GitHub.

Step 4: Write a spec that actually constrains the agent

The single highest-leverage thing you can do in this whole system is write a good spec. Think of it as a lightweight PRD — one that states the goal clearly, but just as important, states what's explicitly out of scope. An agent that doesn't know the boundaries of a task will happily wander outside them, refactoring files nobody asked it to touch or adding features nobody requested. A tight, unambiguous spec is what keeps the planner agent from building on a flawed assumption in the first place — which, as covered above, is the failure mode that does the most damage.

Step 5: Add a fail-safe merge gate

Even teams pushing hard toward full autonomy tend to keep one circuit breaker: an automatic check before merge that can kick a task back to the builder agent if something looks wrong, rather than shipping it straight to production. This is the staged-permission model in practice — you don't hand over the keys to deployment until a specific task category has proven reliable across dozens of runs.

What are the different levels of autonomy you can build toward?

Not every team needs to (or should) jump straight to zero human review. Think of it as a ladder:

AI-assisted with full human review — the agent writes code, a human reviews every line before merge. This is where most teams sit today.
AI-assisted with spot-check review — the agent writes and tests code, a human reviews only flagged or high-risk changes.
Scoped autonomy — narrow, low-blast-radius tasks (bug fixes, boilerplate, test generation) ship without review; anything touching auth, payments, or core architecture still gets a human gate.
Full dark factory — no human review anywhere in the pipeline, for teams and task types that have earned that level of trust through extensive track record.

Whether narrow, well-scoped tasks can run safely without review depends heavily on the task type and the quality of your evaluation layer, with narrow, well-tested tasks with low blast radius being the natural starting point for autonomy.

Which safeguards should you never skip?

If you take one thing from the safety side of this, take this list. Before you let any agent merge or deploy without a human watching, make sure you have:

Hard test gates. No merge happens unless the full automated test suite passes.
Scoped write access. The agent harness should only be able to touch the directories and files relevant to its task.
Isolated execution. Each agent run happens in its own sandboxed environment so one bad run can't contaminate another.
Full audit logs. Every action an agent takes should be logged and reviewable after the fact.
A retry cap. Set a hard limit — something like three attempts per spec — so a stuck agent doesn't spiral into runaway token costs.

That retry discipline matters more than people expect. Costs blow up from retries — hard cap at three attempts per spec, plus token monitoring with alerts.

Is this actually ready for your codebase?

Honestly, it depends on what you're building. If you're maintaining a mature product with strict compliance requirements, you're probably closer to level two or three on that ladder above — and that's fine. If you're iterating fast on an early-stage product where the blast radius of a bad deploy is low, pushing further toward autonomy on narrow task types makes a lot of sense.

What's changing quickly is the reliability of the underlying pieces. Better models make fewer planning mistakes. Better coding agents catch their own errors before they compound. And better harnesses — the skills, hooks, and subagent structures covered above — give you finer control over what an agent can and can't do without you standing over its shoulder.

None of this requires you to flip a switch and remove humans from your pipeline tomorrow. But it's worth building the muscle now: write a skill, wire it into a GitHub Action, run it against a low-risk task category, and watch what it gets right and wrong. The teams that figure out where the safe autonomy boundary sits for their own codebase are going to move a lot faster than the ones still reviewing every line by hand a year from now.