Software factory vs DevOps

A software factory is not an alternative to DevOps. It is a layer that sits on top of a working DevOps practice and changes who writes the first draft of a change and where work starts. The pipeline, the branch protection, the deploys and the monitoring stay. If a team does not have those, it does not have the foundation a factory needs, and the comparison is premature.

The question comes up because the two phrases get used in the same sentence by vendors, and because "software factory" has a separate meaning inside the United States Department of Defense that overlaps heavily with DevOps. This guide separates the three things: DevOps as a practice, the 2026 software factory as an AI delivery loop, and the DoD software factory as an organisation.

The short answer

DevOps is a practice about how a team builds, tests, ships and runs software, with automation and shared ownership across development and operations. A software factory, in the sense engineers use the phrase since early 2026, is a repeatable loop where a ticket starts an AI coding agent, the agent opens a tested pull request, and a person approves the merge. The factory uses the DevOps machinery as its gates. It does not replace any of it.

What stays the same

Everything that decides whether a change is safe to ship stays exactly where it is. The factory depends on these pieces and makes most of them more important, because they are now the only thing between an agent's pull request and a reviewer's time.

Teams sometimes expect to buy a factory and get CI with it. It is the other way round. The factory assumes CI, and a weak suite shows up within the first week as pull requests that pass checks and fail review.

What changes

Four things change, and they are all about the front of the pipeline rather than the back.

The change in review load deserves a closer look. In most teams, review is where work waits, because the reviewer is also an author with their own tickets. In a factory, a share of the authoring moves to the agent, so the same people have more time to review and fewer things to context-switch from. Review does not get lighter per pull request; there are more pull requests worth reviewing and fewer half-finished branches.

The change in where work starts is organisational rather than technical. When a ticket's move to a column is what starts work, the quality of tickets becomes visible immediately. A vague ticket produces a pull request that misses the point, within the hour. Teams that run a factory for a few months write better tickets, not because of a policy but because the feedback is fast.

The DoD software factory is a different thing

Search the phrase and a large share of results are about the United States military. A DoD software factory is an organisation, not an AI workflow. The Air Force's Kessel Run, started in 2017, and Platform One, its DevSecOps platform, are the best-known examples; the Army Software Factory in Austin trains soldiers to build software for the Army. Each combines a team, a secured and accredited platform, and a continuous authority to operate, so that software can be shipped to users in weeks rather than passing through the traditional acquisition cycle.

In other words, a DoD software factory is DevOps, specifically DevSecOps, applied inside an institution that did not have it. The word "factory" there means a standing capability for producing software, in contrast to procuring it project by project. AI coding agents may or may not be used inside one; they are not what the term refers to.

The two meanings do meet. A DoD software factory already has the foundation this guide says a 2026 factory needs: a pipeline, gates, a platform, an accredited way to deploy. It is a plausible place to run an agent-driven loop. But when someone says "software factory" and means Kessel Run, they are talking about the organisation and its platform, and when someone says it and means the agent loop, they are talking about a workflow. Ask which before you compare. The Wikipedia entry covers the older, process-oriented meanings as well.

Metrics: the four that stay and the four that join them

The delivery metrics most DevOps teams already track, lead time for changes, deployment frequency, change failure rate and time to restore service, remain the measures of whether the system as a whole is healthy. A factory should improve lead time on the class of work it handles and must not worsen the failure rate. If it does, the gate is too loose or the suite is too thin.

Four factory-specific measures sit underneath those and explain them. Tickets turned into pull requests tells you whether tickets are good enough to work from. Check pass rate tells you whether the rules file and the suite are doing their job. Time from ticket to pull request shows where the queue is. AI spend per pull request tells you whether a class of work is worth running through the loop at all. All four can be read from the repository host and the model provider's usage page without a new dashboard.

Resist setting targets in the first month. The early numbers are diagnostic. Once the pass rate on one class of work is boring, widen the class.

A migration path from DevOps to a software factory

Because the factory sits on top of the pipeline, the migration is additive. Nothing is torn out. The order below is the one we use, and each step is useful on its own even if the team stops there.

1. Audit the foundation. Tests run in CI on every pull request, branch protection requires a review and passing checks, deploys are scripted, secrets live in a secret store. Fix any gap before adding an agent, because the agent will find it.
2. Pick one repository and one class of work. Bug fixes from one board with written acceptance criteria is the usual choice. Not the monolith, not the billing service.
3. Write the rules file. Setup and test commands, conventions, forbidden paths, the definition of done. Keep it short enough that the team maintains it.
4. Add the trigger and the run. A workflow that starts when a ticket is labelled or moved, checks out the repository in a clean runner, runs the agent and opens a pull request. The Claude Code GitHub Action is one tested way to do this; our tutorial on building a software factory with Claude Code walks through the files.
5. Close the loop to the ticket. The run reports its result on the ticket, and merge moves the ticket to done. A product manager should be able to follow work without opening the repository.
6. Review every change for as long as it takes. Use the first months to improve tickets and the rules file. Move the autonomy dial for a narrow class of change only when the factory's own history justifies it.
7. Widen. Add a second class of work, then a second repository. Each widening repeats steps three to six for the new scope.

If you want the path above walked for you inside your own tools, that is the shape of our software factory setup service: one repository, one workflow, and your team approving every merge.

Common questions