What Is a Software Factory? Why AI Coding Pipelines Run on Specs

A software factory is an automated pipeline where AI coding agents take work through structured steps: intake, spec, build, verify, and ship. Humans set intent and approve gates while agents do the typing. The spec decides what the factory builds.

Software factories are the jargon of 2026, and the numbers explain why: BCG Platinion reports 3x to 5x productivity gains for teams running them. But a factory only multiplies its input, so a vague spec becomes vague software, shipped faster and at scale. The teams pulling ahead treat the spec as the product and govern it exactly like source code.

What is a software factory?

The idea is simple. Instead of one engineer prompting one assistant, a team builds a system where many agents pick up tasks, work in parallel, and hand results to automated checks. BCG Platinion calls this a shift in "the relocation of human effort," not its removal.

Indy Leonard of Viberr put it plainly: software factories are "automated pipelines for agents to work on coding projects in structured sequences." The structure is the point. Without it, you have a lot of agents and no factory.

Where the term "software factory" came from

The phrase is older than most of the people using it. It has carried a different meaning in each era, but the goal has stayed the same: repeatable, high-quality software at scale.

• 1968: M. D. McIlroy argued for mass-produced software components at the NATO Software Engineering Conference.
• 1969 to 1991: Hitachi and other Japanese firms built formal software factories, later documented by MIT's Michael Cusumano.
• 2010s to 2025: The U.S. Department of Defense used the term for teams, tools, and processes built for continuous delivery.
• 2025 to 2026: The agentic software factory appears, where agents automate the coding step itself.

How does a software factory work?

Most agentic factories follow five stages. The names vary by vendor, but two human gates show up in nearly every serious design: one before code is written and one before it ships.

1. Intake: Issues, chat requests, and schedules become tasks an agent can pick up.
2. Specification: The team agrees on what to build and why. This is the first human gate.
3. Build: Agents write changes in parallel, in isolated environments.
4. Verification: Tests, scenario checks, and automated review run against the change.
5. Shipping: A person decides what reaches production. This is the second human gate.

GitHub's Spec Kit formalizes the front half of this flow as specify, plan, tasks, and implement. Amazon's Kiro, Cursor, and Claude Code support similar spec-first workflows. The pattern is converging fast.

What the numbers say about software factories

The headline gains are large, and they come from operating model changes, not from better autocomplete. BCG Platinion separates the two clearly.

• Spotify merges about 650 AI-generated pull requests per month, according to BCG Platinion.
• GitHub data showed agent-authored pull requests outnumbering human-authored ones in August 2026, per The Pragmatic Engineer.
• StrongDM runs a factory with two rules: no human writes code, and no human reviews it, as Simon Willison reports.
• 8090, the company behind a commercial "Software Factory," raised a $135M Series A in June 2026.

The bottleneck moved from code to intent

When agents write the code, the scarce resource is human judgment. BCG Platinion says governance shifts from reviewing code to verifying that what was built matches what was intended. That only works if the intent is written down, current, and reviewable.

The review gap is already measurable. A 2026 study of repositories with both human and agent contributors found that 69.9% of agent-authored pull requests had no recorded review or only agent review. More output with less oversight is how factories ship the wrong thing at speed.

Why long specs fail human review

• Review speed matters. Kemerer and Paulk found reviews at about 200 lines per hour or slower caught most design defects (IEEE TSE, 2009).
• Attention fades. Reaction times slowed after about 30 minutes on task in a vigilance study by Pattyn and colleagues (Physiology and Behavior, 2008).
• Models pad when unsure. Large language models add length when uncertain, and GPT-4 did so in 50.40% of tested cases (Zhang et al., 2024).

Put those together and the risk is clear. Agent-drafted specs get longest where they are least certain, and humans read them least carefully exactly there. A factory built on that spec inherits every gap.

What is a dark software factory?

StrongDM is the best-known example. Its team stores end-to-end scenarios outside the codebase, where coding agents cannot see them, and measures how often agent output satisfies those scenarios. That works because the scenarios act as a protected, human-owned statement of intent.

Stanford CodeX asked the obvious follow-up in its commentary, Built by Agents, Tested by Agents, Trusted by Whom? The answer is whoever owns the spec and the scenarios. Even a dark factory has a human-owned control point.

What a governed spec looks like

If the spec is the control point, it needs the same discipline engineers already apply to code. Here is the minimum standard we see working in AI-heavy teams.

This is the problem Crema was built to solve. Crema keeps the spec in one GitHub repository and breaks writing and review into decision cards sized for about 25 minutes of human judgment, each with a recorded reason. Agent proposals are capped at 2,000 words, permissions are set per proposer, and every decision lands in an append-only audit trail.

How to start building a software factory

1. Pick one workflow. Start with a contained job such as test migration or dependency upgrades.
2. Write the spec first. Define the outcome, the audience, and the reason before any agent runs.
3. Set two gates. Approve the plan before build, and approve the change before ship.
4. Size reviews for people. Keep each review unit small enough to finish in one focused session.
5. Record every decision. Keep who proposed, who decided, and why, in version control.
6. Measure satisfaction, not volume. Track whether output meets the spec, not how many pull requests merged.

Want a running start? Crema PRD is a free, MIT-licensed skill that structures spec writing for Claude Code, Cursor, Kiro, and Spec Kit. It is the fastest way to give your first factory a real spec.