
Software Factory
Most engineering organizations build software as a craft. Each change is hand-made by whoever picks it up, with their own tools, their own order of operations, and their own idea of done. That works for one team and breaks at fifty. A software factory is the alternative: treat delivery as a production line with fixed stations, checks between them, and one standard that every repository follows.
Overview
The idea is older than most of the tools it now describes. Engineers at General Electric were writing about a "software factory" in the late 1960s, Hitachi opened the first facility run as one in 1969, and Michael Cusumano documented how Japanese firms industrialized software in his 1991 book on the subject. Microsoft revived the term in 2004 for template-driven assembly of applications, and the US Department of Defense adopted it in 2019 for DevSecOps pipelines with security controls built in, of which Platform One is the best-known example. The workers changed in every era. The through-line did not: standardize the path the work takes, not the craft of the person doing it.
The current revival attaches the term to fleets of coding agents, and that is where it matters to engineering leaders today. Agents can produce changes faster than people can review them, and a team that lets every developer run agents their own way ends up with fifty different pipelines and no way to reason about any of them. The factory is the answer to that problem at the organizational level. It is the operating model that an Agentic SDLC runs inside: the same intake, the same stations, the same gates, and the same audit trail, whether the work touches one service or all of them.
How it works
A factory is defined by its line, not by who works on it. Four properties make a delivery process a factory rather than a fast craft shop:
Standardized intake
Work enters the line in a known shape. A ticket, a pull request, a failing build, or a vulnerability alert arrives with an owner, a scope, and acceptance criteria, and a trigger starts the matching workflow. Nothing begins with a person deciding what to do next.
Stations run by agents
Each stage, from triage and specification through build, verification, and release, is a defined workflow with a fixed tool set. The same playbook runs on every repository, so a dependency upgrade in service one takes the same path as the one in service fifty.
Gates between the stations
Work cannot advance until a check passes. Some gates are automated, such as tests, policy checks, and static analysis. Others require a person, usually at the specification and the merge. Agents execute between the gates and never past them.
Measured and replayable
The line reports cycle time, defect rate, and throughput per workflow, not per developer. Every run records its inputs, prompts, model version, and policies, so a change can be reconstructed and audited after the fact.
Example in practice
A platform team supports fifty services, and a critical vulnerability lands in a dependency most of them share. In a craft shop, each service owner patches on their own schedule, in their own way, and the platform team chases them for weeks. In a software factory, the vulnerability alert is a standardized input. It triggers the same remediation workflow in every affected repository: an agent bumps the dependency in an isolated environment, runs the test suite, and opens a pull request with the diff and the test results attached. A verification gate checks policy and coverage. A human approves each merge. The team measures the line by one number, time from alert to patched service, and can replay any run if an auditor asks how a change got in.
What is Software Factory?
A software factory is an engineering operating model that produces software through standardized, automated pipelines with defined stations and quality gates, so that work of the same kind follows the same path, at scale, no matter which person or agent performs it.
Comparison: Software factory vs. the CI/CD pipeline
A CI/CD pipeline is one station inside a factory, not a competitor to it, and ad hoc agent use is the thing a factory replaces.
Run your SDLC as one standard line
Overcut runs agentic workflows across every repository in your organization, inside the guardrails you define, with people approving at the gates.
Get a demo


