What is a software factory?

A software factory is a repeatable workflow that turns a ticket into a tested pull request with little or no hand-carrying by people. A ticket starts the work, an AI coding agent writes the change in an isolated environment, automated checks test it, and a person approves the merge. The factory is the loop itself, not any single tool inside it.

That is the meaning the term has taken on since early 2026. It describes how a team runs AI coding agents, not which agent it runs. The same phrase has been used for other things over the last sixty years, so this guide covers the current meaning, the older ones, the parts of the loop, what a factory is not, and the kinds of work teams actually put through one.

The 2026 meaning and the older ones

The phrase is old. Bob Bemer used "software factory" in a 1968 paper, at a time when the question was whether programming could be organised like manufacturing, with standard parts and a measurable process. Through the 1970s and 1980s, several large Japanese firms ran organisations they called software factories: disciplined process, reuse libraries, and a strong emphasis on measurement. The Wikipedia entry on software factories covers this lineage.

Microsoft gave the term a second life in 2004. Jack Greenfield and Keith Short published "Software Factories", a book about model-driven development: domain-specific languages, templates and tooling that generate much of an application from a specification. That meaning lived mostly inside the Visual Studio ecosystem and faded as agile practice spread.

The United States Department of Defense uses the phrase in a third way. A DoD software factory, such as Kessel Run or Platform One in the Air Force, or the Army Software Factory in Austin, is an organisation: a group of people, a secured DevSecOps platform and a continuous authority to operate, set up to ship software to the field faster than traditional acquisition allows. There is no requirement that AI writes any of the code. If you search the term and find uniforms, that is the meaning you have landed on.

The 2026 meaning grew out of coding agents that can hold a task from start to finish. Once an agent can read a ticket, edit a codebase, run the tests and open a pull request, the interesting question stops being "what can the model do" and becomes "what loop do we put it in". Addy Osmani describes a factory as harnessed agent loops run at scale, in his essay Software Factories, Light and Dark. Nx makes the same point from the other side in A Software Factory Is a Workflow, Not a Product: you assemble it from the tools you already have, with a modest amount of script.

The six parts of the loop

Every working factory we have seen has the same six stations, whatever the brand of ticket tool or agent. Remove one and the loop either stops or becomes unsafe.

1. A ticket with acceptance criteria. Work enters the factory from the board the team already uses, usually when a ticket is moved into a named column. The acceptance criteria are the specification the agent works from, so vague tickets produce vague pull requests.
2. An agent with project rules. The coding agent reads the ticket, the codebase and a rules file kept in the repository: conventions, test commands, areas it must not touch. The rules make results repeatable across the team instead of depending on who wrote the prompt.
3. An isolated run. Each task runs in a fresh environment, typically a CI runner or a container, never on someone's laptop. The run can be inspected, repeated and thrown away, and it holds only the credentials it needs.
4. A pull request. The agent's output is a branch and a pull request linked to the ticket, with a plain summary of what changed and why. Nothing is pushed to the main branch directly.
5. Tests and checks. The team's existing CI runs the test suite, linters and build. Failures go back to the agent, which fixes and tries again within limits the team sets.
6. An approval gate, then deploy and status. A person reviews and approves the merge under normal branch protection. The existing deploy runs, and the ticket is updated with the result, so status flows back to where the work started.

The order matters less than the gates. The two that make the factory safe are the isolated run, which limits what a mistake can reach, and the approval gate, which keeps a person responsible for what lands in the main branch.

What a software factory does, step by step

A worked example makes the loop concrete. Suppose a product manager writes a ticket: "Fix the empty state on the invoices page", with three acceptance criteria: show a message when no invoices exist, keep the filter bar visible, and cover the change with a unit test. The ticket sits in the backlog like any other.

A developer, or the product manager, moves the ticket to a column named for the factory. That move is the only trigger. A workflow picks it up, checks out the repository in a clean runner, and starts the agent with the ticket text, the project rules and the task of satisfying the criteria.

The agent reads the invoices page, finds the component that renders the list, adds the empty state and a test, and runs the test command named in the rules file. If the tests fail it reads the failure and tries again. When they pass it opens a pull request on a new branch, references the ticket number, and writes a summary a reviewer can read in a minute.

CI runs on the pull request exactly as it would for a human author. A reviewer on the team opens it, reads the diff and the test, and approves or asks for changes. On merge, the normal deploy runs and the ticket moves to done with a link to the merged pull request.

What the factory did, in plain terms: it removed the copying and pasting between the ticket tool, the editor and the pull request, and it made the result the same no matter who moved the ticket. What it did not do: decide what to build, or decide that the change was good enough to ship. Those stayed with people.

Light and dark factories

Not every factory keeps a person at the merge gate. A dark software factory, a term from Dan Shapiro's five-level model of AI-assisted development, is one where no human reviews the code at all; the StrongDM Software Factory, published in February 2026, took this position deliberately. A light factory keeps human judgment at the gate and automates everything around it. We build light factories, for reasons laid out in our guide to light and dark software factories. The short version: the gate is where accountability lives, and most teams' test suites have not yet earned the right to replace it.

What a software factory is not

The term is new enough that it gets attached to things that are not factories. Four cases come up often.

• It is not a chat assistant. A developer pasting a ticket into a chat window and pasting code back is using an assistant. Useful, but the work still travels by hand, and the result depends on the person. A factory starts from the ticket and ends at the pull request without that courier.
• It is not a platform you buy. Several vendors sell products with "factory" in the name, and some are good. But the loop is a workflow across tools you already pay for: your board, your repository host, your CI, an agent. Buying a platform can shorten the setup. It is not the factory.
• It is not a replacement for tests. The factory makes the test suite more important, not less, because the suite is what decides whether an agent's change reaches a reviewer. A codebase with weak tests gets a noisier factory, not a faster one.
• It is not a room full of autonomous robots shipping to production. That is the dark version, and it is the exception. Most factories in use today end at a pull request that a person approves.

Examples of factory workflows

Teams rarely start by putting their whole backlog through a factory. They pick one repository and one class of work where the acceptance criteria are clear and the tests are trustworthy, then widen from there. These are the workflows we see most.

What these have in common is a written definition of done and a test that can tell success from failure without a person watching. Work that lacks either belongs with a developer, at least until the ticket is rewritten.

If you would rather have the loop built inside your own Jira or ClickUp, GitHub and CI than assemble it yourself, that is what our software factory setup service does, starting with one repository.

Common questions