What is a software factory? How to build one with AI coding agents
Updated November 13, 2026 · first published September 21, 2026 · by the AQ team
A software factory is a repeatable system for producing software changes. Work enters from issues, specs, alerts or schedules; AI coding agents build each task in an isolated environment; automated checks and an independent review decide whether the change is good enough; and the change merges and ships, with people approving at points the team chooses in advance. The loop then picks up the next task and repeats.
AQ is a platform for running a team software factory: issues go in, AI coding agents like Claude Code and Codex plan, build and test in their own branch, a second agent reviews, and your team approves the plan and the merge together.
AQ is where teams put AI agents to work turning tasks into reviewed pull requests and recurring jobs, using the agents and subscriptions they already have (Claude Code or Codex, for example) on private cloud machines of their own. Crews plan, build and review the work, and bots start it from Linear, GitHub, schedules or webhooks.
The rest of this page covers where the term comes from, the stations every factory needs, how to check that each one works, what to assemble yourself and what to buy, and a short setup you can run in AQ today.
Where the term comes from
"Software factory" has been used for more than fifty years, and each era meant something different by it. Date any definition you read.
| Era | What the term meant | Primary references |
|---|---|---|
| 1969 to the 1980s | Applying manufacturing discipline to programming: standard processes, reusable components, measured output | Wikipedia's Software factory entry names Hitachi Software Works (1969) as the first company to use the term, followed by System Development Corporation (1975) and NEC, Toshiba and Fujitsu (1976 to 1977). Michael Cusumano documented the Japanese programs in "Japan's Software Factories" (1991). |
| 2004 to about 2010 | Model-driven product lines: assembling families of related applications from templates, schemas and framework components | Greenfield and Short, Software Factories (Wiley, 2004), the source Wikipedia's current definition follows |
| About 2018 to today (US defense) | A DevSecOps development organization with its own hardened pipeline and platform | The DoD Enterprise DevSecOps Initiative, a joint effort of the DoD CIO and the acquisition undersecretary's office, which describes deploying "a DoD-hardened Software Factory" |
| 2026 | A continuous loop in which AI coding agents turn a queue of work into reviewed, merged code | StrongDM, Stripe, Will Larson and OpenAI, below |
Wikipedia's entry still describes the older meaning: "a structured collection of related software assets" that produces applications "through an assembly process." Search results for "software factory" mix all four, so a DoD procurement page and an AI agent post can both rank for the same query.
The 2026 meaning, from the people who used it
- StrongDM. Justin McCarthy, StrongDM's co-founder and CTO, published "Software Factories And The Agentic Moment" on February 6, 2026. It describes "non-interactive development where specs + scenarios drive agents that write code, run harnesses, and converge without human review," with two rules: humans do not write the code, and humans do not review it. It is the strictest public version of the idea.
- Stripe. Stripe's engineering blog described Minions, its unattended coding agents, in part 1 (February 9, 2026) and part 2 (February 19, 2026). Part 2 reports that over 1,300 pull requests merged each week are "completely minion-produced, human-reviewed, but containing no human-written code." Stripe does not call Minions a software factory, but later factory writing uses it as the reference system.
- Will Larson. In "Trying the Software Factory pattern" (September 20, 2026), Larson describes an agent skill that reads a Linear project, audits its goal against the design doc and metrics, updates the issues, and works the unblocked tasks by writing or updating pull requests and asking for review. His definition: "looping on a broad goal, and then relying on the harness to drive progress towards that goal."
- OpenAI. Gergely Orosz's "Inside OpenAI's agentic software factory" (The Pragmatic Engineer, September 15, 2026) reports that a person defines the desired outcome, Codex gathers context and implements it, and the agent "babysits the PR until it's 'green'." Changes are classified by risk: high-risk changes may need more AI reviews or a required human review, and some low-risk areas let an agent approve. After a person approves, another agent watches the rollout. A loop called Perf Factory turns production latency regressions into proposed fixes.
The four differ most on one question: where people stay in the loop. StrongDM removes human review by rule, Stripe keeps a human review on every change, and OpenAI routes the decision by risk. Addy Osmani's essay "Software Factories, Light and Dark" (July 20, 2026) names the two ends: a light factory keeps people at the review gate, and a dark factory, after the manufacturing term for a plant that runs with the lights off, ships without a person reading the change.
Factory, with a capital F, is also a company: its agents are called Droids and are covered on AQ vs Factory.
The stations of a software factory
Every working factory has the same seven stations, whether a team builds them from scripts or buys them. Each station has a typical way of failing, and each can be tested on its own.
| Station | What it needs | Common failure | How to check it works | Where AQ fits today |
|---|---|---|---|---|
| Intake | One source of truth for work (an issue tracker, a spec folder, an alert stream, a schedule) and a rule for which items enter | Vague tickets enter the line and agents produce confident, wrong work | Pick ten recent items at random; a teammate who has never seen them should be able to say what "done" means for each | Bot routines fire on a Linear label, a new GitHub issue, pull request, push or release, a schedule, Gmail, Calendar or a webhook. The ai-task Linear label also creates a work item without starting an agent. |
| Spec and plan | A written plan per task: steps, files, tests to add, and what is out of scope | The agent starts editing before anyone agreed on the approach | For a sample of merged changes, compare the plan with the diff; large unplanned changes mean the plan step is too weak | A crew's Lead proposes a plan and, with the plan gate on, waits for a person to approve, edit, or run it as one thread |
| Build | An isolated checkout per task, the repository's toolchain, credentials scoped to the person or service, and a record of every command | Parallel tasks share a checkout or a database and break each other | Run two tasks on the same repository at once; neither should see the other's files. Check ports, processes and databases or other runtime state separately, because a worktree alone does not keep those apart | Each work item gets its own branch and git worktree. Agents work on the subscriptions the team already has (Claude Code or Codex, for example) or on AQ's built-in agent. |
| Verify | Tests, CI checks and a running preview of the app for each change | Checks pass because the agent weakened them, or nothing exercises the change at all | Plant a known bug in a task brief and confirm the checks catch it before review | A live preview per work item; the pull request card shows CI checks, and a crew's Test role runs tests and reports the commands it ran with their exit codes |
| Review | A reviewer that did not write the change: a person, an agent from another vendor, or both | The same person, or the same model, writes and reviews, so the review repeats the author's blind spots | Track how often review finds something; a review step that never comments is not reviewing | A crew's Review role prefers another vendor and account than the builder's; the Changes panel pins review findings to lines |
| Merge and release | A merge rule (who approves, which checks must pass) and a deploy pipeline | Merges happen while checks are pending or after the reviewed code changed | Push a commit after approval; the merge should wait for a new review | Merge from the Changes panel squashes on GitHub and refuses, with the reason, while checks are pending or failing or while the review is older than the head commit. Deploys stay in your own pipeline. |
| Observe and learn | Signals from production and from the factory itself: failure rate, rework, review findings, cost per task | Nobody measures the line, so the same mistakes repeat and the same tasks fail | Once a week, read the failed and reverted tasks and change one rule, prompt or check | Each routine run keeps a record (trigger, outputs, approvals, cost); shared rules in Memory reach every agent. AQ does not measure or tune the factory for you: evals and improvement loops stay with your team. |
Most failures cluster at intake and review, the two stations people own. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests found that in 79 percent of them the same developer both reviewed and modified the agent's contribution. A factory that raises output without adding reviewers turns one person into the quality gate for the whole line; the self-review problem covers this in detail.
Levels of automation
Teams rarely jump from autocomplete to a factory. A common progression runs: an assistant suggests code in the editor; one agent completes a task while a person watches; several agents run in parallel, each in its own worktree; agents start from a queue or an event and a person reviews every change (a light factory); and finally some classes of change merge without a person reading them (a dark factory, which StrongDM's rules describe). Each level needs every station of the previous one to be dependable first. A team at the third level with weak checks gets more broken pull requests, faster.
Build or buy
A software factory is assembled from parts most teams already own, so building one yourself is realistic. The work goes into the joins between the parts.
What you assemble yourself
- Headless agent CLIs. Claude Code (
claude -p) and Codex (codex exec) both run without a terminal session, so a script or a CI job can start them with a brief. - A queue and a dispatcher. Labels or a status column in your tracker, plus a job that turns new items into agent runs and records which run belongs to which item.
- Isolated environments. A git worktree, container or VM per task, with dependencies installed and secrets scoped to that run.
- CI and a merge rule. Your existing CI, branch protection and required reviews.
- A review path. A second agent from another vendor, a human reviewer, or both, and a way to send findings back to the builder.
- Records. Logs of what each run did, what it cost, and why it failed.
Building it yourself fits a team with platform engineers, one repository with strong tests, and a reason to keep everything inside its own CI. Larson's post is a good account of that route: his company first moved every engineer onto Claude Code, then made Linear the single source of work, then rolled out an internal agent harness modeled on Stripe's Minions, and only then added the factory loop.
What platforms provide
Several products now sell parts of the factory. Each statement below comes from the vendor's own pages, read on November 13, 2026; none of it is an AQ test.
- Factory. Factory's Automations start Droids from schedules, Slack, GitHub events (which run in GitHub Actions) and webhooks, and its docs describe delegating a task, reviewing the diff and merging from the Factory app or a terminal.
- Warp. Warp's November 4, 2026 post defines a production software factory as "a measurable, improvable cloud-based system for scaling coding agents." Oz runs the cloud agents, Warp-hosted or on your own infrastructure.
- Ona (formerly Gitpod, now part of OpenAI). Ona's background agents trigger from GitHub, Linear, Slack or schedules, and each runs in its own short-lived environment.
- CircleCI. The Chunk CLI runs a CircleCI pipeline that validates an agent's changes and opens a pull request when it passes, which covers the verify station.
- Cursor. Cursor Automations start cloud agents from schedules and events in GitHub, GitLab, Slack, Linear, Sentry, PagerDuty and webhooks.
When comparing them, ask the same questions of each: whose credentials and model accounts a run uses, where the code executes, who can see a run while it works, what a reviewer can inspect, and who can change the automation. A trigger list alone does not tell you whether the review and observe stations exist.
Where AQ fits
AQ is a platform for running a team software factory: issues go in, AI coding agents like Claude Code and Codex plan, build and test in their own branch, a second agent reviews, and your team approves the plan and the merge together.
AQ (aq.dev) is where teams put AI agents to work turning tasks into reviewed pull requests and recurring jobs, using the agents and subscriptions they already have (Claude Code or Codex, for example) on private cloud machines of their own. In factory terms, AQ covers intake, plan, build, verify, review and merge, and the run records feed the observe station:
- Agents you already pay for. Agents work on the subscriptions the team already has (Claude Code or Codex, for example), or on AQ models priced per token.
- One worktree per task. A work item is a branch, a worktree, a live preview and the agent threads working in it, on a machine that stays up when a laptop closes.
- Crews. A Lead plans, a person approves the plan, and Build, Test, Review and Research roles do the steps, each on the model the organization picked for that role.
- Bots and routines. A bot's routines start work from Linear labels, GitHub events, schedules and webhooks, and run as the person who created them, on that person's accounts.
- Shared review. Teammates open the same work item, read the diff in the Changes panel, comment on lines, and merge once checks and review are current.
AQ does not decide what your team should build, write your tests, or run evals on your factory. Those stay with the team.
A starter factory in AQ
Every step is available to a new account today. Agents run on your own Mac with the AQ Mac app on the Free plan, or on a cloud machine on the AQ Pro plan.
- Connect a machine and GitHub. Sign in at aq.dev, connect your Mac or a cloud machine from the first-run checklist, then connect GitHub and pick a repository.
- Connect two agent subscriptions. In Settings, Connections, sign in to Claude Code and Codex (or any two vendors you use).
- Set the role picks. In Settings, Crews, put the Build role on one vendor and the Review role on the other, so the reviewer never shares the builder's model.
- Make a bot with an intake routine. Start a bot from the Bots group and tell it the job, for example: "When a GitHub issue is opened on acme/web, start a work item on that repository with the issue as the brief, and ask it to run as the Ship crew." The bot creates the routine. A Linear label works the same way through your connected Linear account (bots and routines).
- Approve the plan. When an issue arrives, the work item's Lead proposes a plan and waits. Approve it, edit it, or run it as a single thread (crews and roles).
- Review and merge. Builders work in their own worktrees, the reviewer from the other vendor pins findings to lines, and the Lead opens a pull request. Read the diff in the Changes panel and merge when the checks pass (changes, review and merge).
That gives you a light factory with two approval points, the plan and the merge. Remove one only after a month of records shows the station before it is dependable. The AQ API and MCP server let other systems start work items and read results, and the Linear integration covers label intake and two-way status.
How AQ's own website is built
AQ's own website is built this way. Agents write and update its pages in AQ work items, every change is reviewed before it goes live, and the live page is checked after each release. Over the past month that loop shipped more than 100 page updates, including same-day corrections when a vendor changed its plans or pricing. Read how AQ runs its website for the full loop.
Related reading
- Agent fleet: the workers a factory runs
- Agent orchestration: the tooling that dispatches and coordinates them
- Coding harness: the software around one model
- Event-driven coding agents: starting agents from events instead of a person
- Verifying AI coding agent work: the review discipline a factory depends on
- Multiplayer coding agents: how a team shares one live agent session
Frequently asked questions
What is a software factory?
A software factory is a repeatable system that turns incoming work (issues, specs, alerts, schedules) into shipped software. In 2026 the term usually means AI coding agents build each task in an isolated environment, automated checks and an independent review gate the result, and people approve at set points before it merges. Older meanings, from Hitachi's 1969 Software Works to the US defense software factories, describe standardized human development processes.
What does AI software factory mean?
An AI software factory is a software factory whose builders are AI coding agents. People decide what enters the queue and where approval is required; agents plan, write code, run tests and open pull requests. Stripe's Minions, which produce over 1,300 merged pull requests a week with human review per Stripe's February 2026 post, are the most cited public example.
What is an agentic software factory?
It is the same idea with the emphasis on agents acting on their own: they pick up tasks, gather context, fix failing CI and respond to review without a person driving each step. The Pragmatic Engineer's September 2026 report on OpenAI describes one in which agents also watch rollouts and turn production latency regressions into proposed fixes.
What is the software factory pattern?
Will Larson's September 2026 post uses the phrase for an agent loop over a project: read the goal and its metrics, update the issues, work the unblocked tasks, then re-audit and repeat. He describes it as looping on a broad goal and relying on the harness to drive progress toward it.
How is a software factory different from CI/CD?
CI/CD tests, builds and deploys changes that someone already wrote. A software factory includes CI/CD as its verify and release stations, and adds the stations before and after: intake of work, planning, agents that write the change, independent review, and a loop that learns from failures. A team with good CI/CD already has two of the seven stations.
What are examples of software factories?
Public examples include Stripe's Minions, OpenAI's Codex-based pipeline described by The Pragmatic Engineer, StrongDM's factory, which removes human code review by rule, and Will Larson's Linear project loop. Older examples include Hitachi Software Works and the hardened DevSecOps software factories of the US Department of Defense. Vendors including Factory, Warp, Ona and Cursor sell parts of the agent version.
Can a small team build a software factory?
Yes, if it starts small. One repository with good tests, one intake rule (for example, issues with a specific label), two agent vendors so one can review the other, and a person approving every merge is enough to run the loop. Add automation one station at a time, and only after its records show it works.
Is it safe to let agents merge their own code?
Only for classes of change where verification is strong enough to replace a reader: generated files, dependency bumps with full test coverage, or low-risk areas a team has measured. OpenAI's pipeline, as reported in September 2026, lets agents approve only in opted-in low-risk areas and routes high-risk changes to more review. Keep a person at the merge until the review and verify stations have a record you trust.
What is the difference between a light factory and a dark factory?
The terms come from Addy Osmani's July 2026 essay. A light factory keeps people at the review gate: agents build, people read what merges. A dark factory ships without a person reading the change, as StrongDM's rules require. Most published factories, Stripe's and OpenAI's included, keep at least some human review.