AI software factories explained (paste one prompt, get shipped code)

Picture a coding workflow where you write a single planning document, walk away, and come back to find a working feature already merged. No pull request review. No line-by-line reading of the diff. Just a spec going in one end and shipped code coming out the other.

That setup has a name now: the AI software factory (some people call it the "dark factory," a nod to fully automated manufacturing plants that run with the lights off because no humans need to see). It sounds like a stretch until you realize the pieces to build one already exist, and some of them are free and open source.

This guide breaks down what an AI software factory actually is, why it depends on getting a handful of fundamentals right first, and how to start building your own version instead of just reading about the concept.

What is an AI software factory?

An AI software factory is a system where a product requirements document (PRD) goes in, gets automatically split into individual tasks, and comes out the other side as tested, shipped code. Nobody manually reviews the code in between. The system plans, implements, tests, reviews, and deploys on its own.

This is the extreme end of a spectrum that most people call AI coding autonomy. The concept of AI coding autonomy describes how much a system can do without a human making decisions at each step. At one end you have autocomplete suggesting your next line. At the other end you have a fully self-operating pipeline. A dark factory is a fully automated production facility that runs without human workers — it operates in the dark because no one is there to turn on the lights.

Right now, this level of autonomy is rare in production. Pure Level 5 systems — fully autonomous end-to-end with no human involvement — are not in widespread production use. The engineering and trust requirements are significant. But partial versions of it are already running, and the gap between "cool demo" and "reliable daily driver" is closing fast.

Why does the PRD matter so much?

The whole system hinges on that first document. If the PRD is vague, everything downstream inherits the vagueness — task breakdown, implementation, testing, all of it. This is exactly why spec-driven development has become such a big theme in AI coding circles this year. A minimal spec has three parts: requirements (what the feature must do, written as user stories and acceptance criteria), design (data models, API contracts, which files change), and tasks (an ordered implementation plan where each step lists its dependencies).

The data backing this up is blunt. Claude Code's first-attempt success rate on small-to-medium PRs without detailed guidance sits around one-third, according to Anthropic's own RL Engineering team. Two-thirds of the time it either misses requirements, interprets scope too broadly, or chooses the wrong implementation path. A well-written PRD is the difference between a factory that ships garbage and one you can actually trust.

What are the five levels of AI coding autonomy?

Before building a factory, it helps to know where your current workflow sits. Autonomy in AI coding isn't one thing — it's a spectrum, and different tasks call for different levels.

The first level of autonomy is not really autonomy at all. Inline suggestions, refactors, and quick fixes in a single file. This is GitHub Copilot-style autocomplete — helpful, but the human is driving every keystroke.

From there, things scale up through chat-assisted help, agentic task execution, harness-driven workflows, and finally the fully autonomous factory. Multi-agent coordination — Different agents handle different concerns: one plans, one codes, one tests, one reviews, one deploys. They communicate, hand off work, and resolve conflicts. A single agent chatting with a developer isn't enough. That's what separates a chatbot from a factory — specialization and coordination, not just a bigger model.

It's worth being honest about the risk of skipping steps. The most common mistake is jumping from Level 2 directly to Level 4 without the right foundations. Autonomous agents doing sloppy work on a codebase with no tests is worse than not using them at all. Test coverage and clear specs aren't optional extras here — they're the load-bearing walls of the whole factory.

Which level should you actually be working at?

Higher isn't automatically better. The taxonomy has five levels, defined by a single variable: how much of the work does the agent do autonomously before returning to you for feedback? For each level, the goal is the same: understand what it's actually good for, and when to reach for something else. It's not a ranking, and higher is not always better. A good rule of thumb: if you can describe "done" in a sentence with no ambiguity, an agent can probably handle it without you watching. If you can't, you need to be in the loop. If you're just looking for in-the-moment help on a file you already have open, that's basic autocomplete territory.

How do you actually build one of these factories?

You don't need to invent this from scratch. A handful of open source projects already handle the "spec → plan → tasks → code" pipeline, and you can wire them into whatever coding agent you already use.

What is Archon, and how does it fit in?

Archon is the closest thing to an off-the-shelf harness for this exact workflow. Archon is a workflow engine for AI coding agents. You define your development processes as YAML workflows — planning, implementation, validation, code review, PR creation — and run them reliably across all your projects. The comparison people keep reaching for is infrastructure tooling: like what Dockerfiles did for infrastructure and GitHub Actions did for CI/CD, Archon does for AI coding workflows — think n8n, but for software development.

The problem it's solving is real. When you ask an AI agent to "fix this bug," what happens depends on the model's mood. It might skip planning. It might forget to run tests. It might write a PR description that ignores your template. Every run is different. Archon forces consistency by turning your process into a defined, repeatable workflow rather than a fresh improvisation every time.

Getting started is straightforward. Archon includes a web dashboard for chatting with your coding agent, running workflows, and monitoring activity. Register a project by clicking + next to "Project" in the chat sidebar, entering a GitHub URL or local path, then start a conversation, invoke workflows, and watch progress in real time.

What is spec-driven development, and why does it pair with a factory?

Spec-driven development (SDD) is the discipline that makes the factory trustworthy in the first place. Spec Driven Development (SDD) is a workflow that separates planning from execution. Instead of jumping straight into code, you create a series of specification documents that define what you're building, how you'll build it, and what steps you'll take. Only after these specs are reviewed and approved do you move into actual implementation.

If you're on Claude Code specifically, there are a few solid open source options for wiring this in. GitHub's Spec Kit is the most widely adopted. The core SDD process ships ready to use: Spec → Plan → Tasks → Implement. Define what to build before building it. Each phase produces a Markdown artifact that feeds the next — giving your AI coding agent structured context instead of ad-hoc prompts.

Installing it takes two commands, straight from the official Spec Kit documentation:

1. Install the CLI: uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
2. Scaffold your project: specify init my-project --integration copilot (swap copilot for claude, codex, or whichever agent you use)

From there, the workflow itself runs entirely through slash commands inside your agent: specify what you want to build (/speckit-specify), plan how you will build it (/speckit-plan), break down the plan into actionable tasks (/speckit-tasks), implement the tasks (/speckit-implement), and converge the implementation against the spec, plan, and tasks (/speckit-converge). The docs also note you should establish your project principles once with /speckit-constitution as a one-time step per project before you start specifying features.

If you want an alternative built specifically around Claude Code, claude-code-spec-workflow follows a similar Requirements → Design → Tasks → Implementation structure and is worth comparing against Spec Kit for your setup.

How do you know when the factory is ready to run unsupervised?

This is the part most people skip, and it's the part that actually determines whether the factory produces something you can ship or something you have to quietly throw away.

What foundations need to be in place first?

Test coverage is non-negotiable. If your agent can't verify its own work against a real test suite, you're not running a factory — you're running a slot machine. A software module with comprehensive tests is a natural candidate: the agent can refactor, optimize, or even re-implement as long as all tests pass. The key enabler is clear specs with comprehensive validation. This shifts from "spec-driven" to "spec-centric": the source-of-truth is captured well enough that the agent can be let loose on the code.

Evidence beats assertions, too. Don't let an agent just tell you it's done — have it show its work. Have Claude show evidence rather than asserting success: the test output, the command it ran and what it returned or a screenshot of the result. Reviewing evidence is faster than re-running the verification yourself.

And know where multi-agent setups still get shaky. Multi-agent coordination is the stage where markdown alone stops working. Claude Code's Agent Teams feature is experimental, disabled by default, and costs 3-4x as many tokens as single-agent sessions. Practitioners report the lead agent sometimes "goes rogue and does the work itself." If you're building toward a factory, budget for that overhead and keep a human checking the orchestrator level even after you stop reading individual diffs.

When should you not bother with a full factory setup?

Not every task deserves this ceremony. Skip spec-driven development entirely for single-file bug fixes, formatting changes, or well-understood CRUD operations that a single prompt can handle. Writing a specification for these costs more than it saves. The factory model earns its keep on recurring, well-defined feature work — not one-off tweaks.

What should your first factory project actually look like?

Start small and boring. Pick a feature with a genuinely clear definition of done — something you could describe in one unambiguous sentence — and run it through the full spec-to-code pipeline before trusting the system with anything bigger. Write the PRD yourself first. Let the agent turn it into requirements, then a plan, then tasks. Review the plan and the task list closely (this is where mistakes are cheap to catch), then let implementation run with test-driven verification at each step.

Once you've done that a few times and the agent's task breakdowns start looking right without much correction, you can pull back further — approving PRDs but skimming less of what happens in between. That's the real path to a working factory: not skipping the boring setup work, but doing enough of it that skipping the code review afterward actually feels safe instead of reckless.

The teams getting real value out of this right now aren't the ones chasing full autonomy on day one. They're the ones treating specs, tests, and task breakdowns as infrastructure — then letting the automation do exactly what it's good at, one verified task at a time.