What is a software factory?
Published September 21, 2026 · by the AQ team
A software factory, in the sense the term carries in 2026, is a system that turns a queue of well-specified tasks into merged, production code by running AI coding agents in a continuous loop: work enters from a task tracker, each task is dispatched to an agent in its own isolated environment, the output is verified by tests and drained through a review gate, and the loop re-runs as the queue and the goals change. The word "factory" means the assembly-line properties specifically: standardized intake, repeatable per-station processing, quality control before anything ships, and throughput that comes from the line running continuously rather than from any one worker being fast. The term has had several distinct lives since 1968, and search results, vendor pages, and government procurement documents still use all of them at once, so the history section below is not optional trivia.
The 2026 meaning: an agentic loop over a task queue
The pattern that made the term current again is best seen in two public, dated examples.
Stripe's Minions are the flagship. In a two-part engineering blog series (the second part published February 2026), Stripe described internal one-shot coding agents that engineers invoke with a task description and walk away from: each Minion runs inside an isolated, pre-warmed cloud sandbox, orchestrates its work through "blueprints" that mix deterministic steps with agent loops, and produces a pull request with code, tests, and documentation. Stripe reported more than 1,300 pull requests merged per week containing zero human-written code, every one still passing human review before merge.
Will Larson's software factory experiment named the pattern for the rest of the industry. In "Trying the software factory pattern" (lethain.com, September 20, 2026, front-paged on Hacker News the same day), Larson describes an agent skill that reads a Linear project, audits the project's goal definition against its design docs and dashboards, reviews the state of its metrics and issues, adds newly discovered work, updates issues that have moved, and then works the unblocked tasks: writing pull requests, updating existing ones, and pinging humans for review. The loop re-runs as the project drifts, which also catches post-release regressions like adoption drops. Notably, Larson frames the factory as the top of a stack his team built first: one CLI-based coding agent workflow, one task system as the source of truth, and an internal agent-fleet harness modeled on Stripe's Minions.
Strip the branding from both and the anatomy of the 2026 software factory has five parts:
- A task queue that is the source of truth. An issue tracker (Linear and GitHub Issues are the common ones) holds work in a form specific enough for an agent to act on. Vague tickets stall the line; the factory forces the specification discipline upstream.
- Dispatch. A mechanism that moves a task from the queue to a running agent: a human command, a label, a schedule, or an event. Event-driven coding agents covers the automatic end of that spectrum.
- Isolated execution per task. One agent per task, each in its own sandbox or git worktree, so parallel lines never contaminate each other. This is the same requirement an agent fleet has, because the factory's workers are a fleet.
- Verification, then a review gate. Tests and CI catch what is mechanically wrong; a human decides what merges. Every serious factory writeup, Stripe's included, keeps the human gate.
- The loop itself. The factory re-audits goals, notices drift, updates the queue, and picks up the next unblocked task. A batch of one-off agent runs is not a factory; the continuity is the point.
A term with three prior lives
"Software factory" is one of the oldest recurring metaphors in the industry, and each revival meant something different:
| Era | Meaning | Key artifacts |
|---|---|---|
| 1968 to the 1980s | Industrializing programmers: standardized process, reusable components, measured output | Bob Bemer's 1968 position paper proposing a software factory; Hitachi's Software Works (1969); the Japanese factory programs at Hitachi, Toshiba, NEC, and Fujitsu documented in Michael Cusumano's "Japan's Software Factories" (1991) |
| 2004 to ~2010 | Model-driven product lines: assembling families of applications from patterns, models, and templates | Greenfield and Short's "Software Factories" book (2004) and the methodology in Microsoft's Visual Studio tooling |
| ~2018 to present (defense) | A DevSecOps software development organization inside the US Department of Defense | Kessel Run (the DoD's first software factory), Platform One, and the dozens of members of the DoD Software Factory Coalition |
| 2025 to present | A continuous agentic loop turning a task queue into reviewed, merged code | Stripe's Minions posts (February 2026), Larson's factory experiment (September 2026), Addy Osmani's factory essays (2026) |
One more disambiguation: Factory (factory.ai) is a company, an agent-native development platform whose agents are called Droids and whose marketing leans on the factory metaphor by name, covered separately in AQ vs Factory.
Light factories, dark factories, and where factories fail
The sharpest vocabulary inside the 2026 discourse is Addy Osmani's split, from "Software Factories, Light and Dark" (July 2026): a light factory keeps humans in the loop, trading speed for judgment at the review gate, while a dark factory (borrowing the manufacturing term for a plant that runs with the lights off) lets agents scope, build, and ship without a human reading the changes. Osmani's own definition of the factory is many harnessed agent loops running at once, fed by a queue of work and drained through a review gate into production, with humans owning the system from above.
The skepticism is as loud as the enthusiasm, and worth taking seriously:
- The review gate is the bottleneck, and it concentrates. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. A factory that multiplies output without distributing review makes one person the quality department for the whole line.
- Quality debt compounds. A widely upvoted response on Larson's Hacker News thread called the pattern a setup for "a massive pile of janky cruft." The honest counter is not that agents write clean code; it is that the factory only works where verification is strong enough to catch what review would have.
- The harness is not enough. Dex Horthy of HumanLayer argued this in a talk titled "Why Software Factories Fail (or: harness engineering is not enough)," and a September 2026 Hacker News thread titled "Nobody has built a software factory" made the definitional version of the same point: most teams claiming the pattern have built impressive dispatch and execution, while the intake discipline (tasks specified well enough to one-shot) and the drain (review capacity) lag behind.
The failure modes cluster at the two ends humans own: what goes into the queue, and what gets out of review. The middle (running many agents in parallel, in isolation, without babysitting) is increasingly a solved problem.
Software factory, agent fleet, harness: which word for which layer
These terms nest rather than compete. A coding harness is the software wrapped around one model to make it act: tools, context, execution. An agent fleet is many agents operated as a group: dispatched centrally, isolated per task, visible in one place. Agent orchestration is the tooling that coordinates the fleet. The software factory is the end-to-end system above all three: the queue, the fleet working it, the verification, the review gate, and the loop that keeps it running. Larson's stack makes the nesting explicit: harness first, fleet second, factory last. The layer that runs many different vendors' harnesses side by side is what AQ calls a harness of harnesses; the factory is what a team might eventually operate on top of it.
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In factory terms, AQ is deliberately a light factory's floor: it provides the intake, isolation, persistence, and visibility layers, and keeps a human at the start of every run. Work enters from Linear: label an issue ai-task and a workspace appears, with status syncing both ways and ownership following the assignee; a human then starts the agent, never an auto-launch. Each workspace gets its own isolated git worktree (branch ai/{id}-{slug}, dependencies installed automatically, one-click rebase onto main), so parallel tasks never collide. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, so the line keeps moving overnight and survives closed laptops. And the review gate is a team surface rather than one person's terminal: teammates open the same workspace, watch the same live session, and the PRs each agent opens are tracked per workspace, which is how a team distributes the review load instead of reproducing the one-reviewer bottleneck. If what you want is a dark factory that merges its own output, AQ is intentionally not that; if you want the factory pattern with humans owning intake and review and the machine work handled, that is exactly its shape. Verifying AI coding agent work covers the review half in depth.
Frequently asked questions
What is a software factory in AI development?
A software factory is a continuous system that turns a queue of tracked tasks into merged code by running AI coding agents: tasks enter from an issue tracker, each is dispatched to an agent in an isolated environment, output is verified by tests, and a human review gate decides what merges. The loop then re-runs as goals and the queue change. Stripe's Minions (over 1,300 agent-written PRs merged weekly, per Stripe's February 2026 engineering posts) and Will Larson's September 2026 factory experiment over Linear are the canonical public examples.
Is a software factory the same as running coding agents in parallel?
No. Parallel agents are necessary but not sufficient. The factory adds a task queue as the source of truth, dispatch from that queue, verification and a review gate on the way out, and a loop that re-audits goals and picks up new work continuously. A batch of one-off agent runs, however parallel, is not a factory; the continuity and the intake-to-merge pipeline are what earn the word.
What is the difference between a light factory and a dark factory?
The terms come from Addy Osmani's July 2026 essay "Software Factories, Light and Dark." A light factory keeps humans in the loop: agents produce the work, humans review everything that merges. A dark factory, borrowing the manufacturing term for a plant running with the lights off, lets agents scope, build, and ship without human review of the changes. As of September 2026, the credible public examples, including Stripe's, are light factories: high agent throughput with a human review gate intact.
Didn't 'software factory' already mean something else?
Yes, three times. From 1968 through the 1980s it meant industrializing programming itself (Hitachi's Software Works, the Japanese factory programs in Cusumano's 1991 book). In 2004 Microsoft revived it for model-driven product lines (Greenfield and Short's book). Since roughly 2018 the US Department of Defense has used it for its DevSecOps development organizations such as Kessel Run and Platform One. The 2026 usage, an agentic loop over a task queue, is the fourth life of the term, so date any definition you read.
Why do software factories fail?
At the two ends humans own. On intake, tasks specified too vaguely for an agent to one-shot stall the line or produce confidently wrong work. On the drain, review capacity does not scale with agent output: a July 2026 LeadDev analysis of 25,264 agent-generated pull requests found the same developer both reviewed and modified the agent's contribution in 79 percent of them, so one person quietly becomes the merge bottleneck for the whole line. The middle of the factory (parallel, isolated, persistent execution) is the most solved part.