All posts
What is a software factory?
A software factory turns requests into shipped software with a repeatable, quality-checked process. Here's where the term came from, how AI software factories work, and how to start one.
Ben Ong
October 25, 2026
ai-agents
product-development
Request, Agents, Tests, Review and Ship cards connected by arrows on a light orange background, with a green check on Ship
A software factory is a system that turns requests into shipped software through a repeatable, quality-checked process. Today the term usually means a pipeline where AI coding agents do most of the implementation: work comes in as a ticket or a message, agents build and test the change in an isolated environment, and people decide what ships.
The idea is older than AI. What changed is who does the work inside the factory. This guide covers where the term came from, how a modern software factory works, real examples, and how to start running one on your own codebase.
Where the term "software factory" came from
The phrase goes back more than 50 years. According to MIT professor Michael Cusumano, Hitachi was the first company to set up a software facility "labeled and managed as a factory." It opened in 1969 as the Software Works, more literally the Software Factory. System Development Corporation (SDC) in the US and Toshiba, NEC and Fujitsu in Japan followed with their own versions.
Those early factories were about discipline rather than automation. In Cusumano's summary, they emphasized standard methods and tools, systematic reuse of components, divisions of labor, disciplined project management and product quality control. The goal was to stop treating every project as a one-off craft job.
The term came back in 2004, when Microsoft's Jack Greenfield and Keith Short published Software Factories. Their version assembled applications from patterns, models, frameworks and tools, so teams could reuse more and hand-write less.
The US Department of Defense uses it too. In 2022, the Pentagon counted 29 software factories across the military, including the Air Force's Kessel Run. In that sense, a software factory is an in-house team with a shared DevSecOps platform and a continuous delivery pipeline.
Since 2025, the most common meaning is the agentic one. Addy Osmani puts it this way: "you are no longer just writing code. You are building the factory that builds your software."
How a software factory works
A modern software factory is a loop. Each stage has a clear input, a clear output, and a check before the next stage starts.
- Intake. Work arrives where the team already talks about it: a Slack thread, a Linear or Jira ticket, a bug report, a customer request.
- Plan. The request becomes a spec the agent can act on. Good factories read the codebase first and write down the approach, the files involved and what "done" means.
- Build. One or more coding agents implement the change in an isolated environment with the real dependencies, so parallel runs don't collide.
- Verify. Tests, type checks and linters run. Many teams add an agent that reviews the change and a live preview where people can try the result.
- Review and merge. A pull request goes through the team's normal CI, required reviews and branch protection. A person with merge rights decides.
- Learn. Review comments, failed runs and incidents feed back into the specs, rules and context the agents read next time.
The factory part is the structure around the agents. A single coding agent in a terminal is a tool. A software factory is the system of intake, environments, checks and approvals that lets many agent runs happen safely at once.
Software factory examples
Stripe. Stripe's internal coding agents, called Minions, produce over 1,300 merged pull requests a week that contain no human-written code. Every one is reviewed by a human.
StrongDM. StrongDM runs what it calls a software factory with two rules: "Code must not be written by humans" and "Code must not be reviewed by humans." It's the clearest public example of a fully automated, "lights off" factory.
Harvey. Harvey built an internal platform called Spectre to move coding agents from engineers' laptops into shared cloud sandboxes, with durable run records and review in Slack, on the web and in pull requests. We break down what they learned in Harvey built their own software factory.
Production loops. In a LeadDev guide, Chris Kelly describes building a factory "one production line at a time," starting with three loops: pull request to merge, ticket to pull request, and alert to resolution.
Software factory vs DevOps
A software factory doesn't replace DevOps. It runs on top of it. DevOps built the pipeline, and a software factory changes who does the work inside that pipeline.
| DevOps | Software factory | |
|---|---|---|
| Who writes the code | Engineers | Coding agents, with people reviewing |
| What CI/CD does | Checks human work | Checks agent work, often at higher volume |
| Where the bottleneck sits | Writing and reviewing code | Clear specs and trustworthy review |
| What people spend time on | Implementation | Deciding what to build and judging results |
If your team already has solid CI, tests and branch protection, you have most of the foundation. The factory adds agents, isolated environments and a way to feed them work.
Lights on vs lights off
The biggest design choice in a software factory is how much human review it keeps.
- Lights off, or a dark factory. Agents write and merge code without human review. StrongDM is the public example. It needs very strong automated verification and suits teams that can accept that risk.
- Lights on. Agents write the code, and people approve what merges. Stripe's Minions work this way. Most teams start here, because review is where they catch wrong assumptions as well as bugs.
Lights on doesn't mean slow. The goal is to make each review faster, with a clear plan and a working preview attached to every change, rather than to remove the reviewer.
What you need to run a software factory
- Context. Agents need access to the codebase, tickets, docs, conventions and past decisions. Every input they can't reach is a kind of problem they can't solve.
- Isolated environments. Each run needs its own sandbox with real tooling, so agents can install, build, run and test without touching anyone's machine or each other's work.
- Verification. Tests, type checks, agent review and live previews catch problems before a person spends time on them.
- Approval controls. Roles, required reviews and branch protection decide who can propose a change and who can merge it.
- Model choice. No single model is best at everything, so it helps to switch between agents and use the subscriptions your team already pays for.
- Feedback. Corrections from review should improve the next run. Without that loop, the factory repeats its mistakes.
If you want a stage-by-stage view of where your team is today, see The 5 Stages of AI Nativeness, which runs from copilot to agentic software factory.
Who runs the factory?
Most software factories are built by engineers, for engineers. One engineer feeds tickets to agents and reads the pull requests that come back. Product managers, designers and ops sit at the edges, filing requests at the start and seeing results at the end.
That made sense when writing code was the slow part. Once agents can build a change in an afternoon, the slow part moves to deciding what the change should be. That knowledge mostly lives with the people closest to customers.
A multiplayer software factory brings them in. They start work in plain language, shape a shared plan before any code is written, and check the live preview, while engineers keep the merge. We go deeper in What is a multiplayer software factory? and The software factory needs to become a product factory.
How to start a software factory
You don't need to build a platform like Spectre on day one. Start with one production line.
- Pick one repetitive workflow. Copy changes, UI fixes, small bugs and internal tools are common first lines.
- Make the inputs clear. Write down what a good request looks like and what "done" means for that kind of change.
- Give agents a safe place to work. Run each change in an isolated environment with a preview, never on a shared machine.
- Keep your existing review rules. Route every agent pull request through the same CI and approvals as human work.
- Measure request to merge. Track how long a change takes from request to merged pull request, and compare it with the same kind of change done by hand.
Once one line works, add the next. That is how most teams in the examples above got there.
How LightSprint fits
LightSprint is a software factory for your existing codebase that the whole product team can use. Anyone can start a change from LightSprint, Slack, Linear or Jira. LightSprint reads your repo and turns the request into a visual plan the team reviews together. Each change runs in an isolated sandbox with a live preview, using Claude, Codex or your own model subscription.
Builders, typically PMs, designers or ops, can propose changes and view previews but can't merge. Approvers, typically engineers or leads, review and merge through your current CI and review rules. Details on guardrails are on our engineering page and security page.
FAQ
What is a software factory?
A software factory is a system that turns requests into shipped software through a repeatable, quality-checked process. Today it usually means AI coding agents do most of the implementation in isolated environments, while people set the work and approve what merges.
Where does the term software factory come from?
Hitachi set up the first facility managed as a software factory in 1969. Microsoft's Jack Greenfield and Keith Short revived the term in 2004 for building apps from reusable patterns and models. Since 2025, it mostly refers to pipelines run by AI coding agents.
Is a software factory the same as DevOps?
No. DevOps built the delivery pipeline of CI/CD, testing and deployment for human engineers. A software factory runs on that pipeline but has coding agents do most of the implementation, with people reviewing and approving the results.
What is a dark software factory?
A dark or "lights off" software factory writes and merges code with no human review. StrongDM's factory is a public example. Most teams run a "lights on" factory instead, where agents write the code and people approve every merge.
Do I need to build my own software factory?
Not necessarily. Companies like Stripe and Harvey built internal platforms, but you can start with one workflow and existing tools. LightSprint gives your team agents, isolated sandboxes, live previews and approval controls on your existing GitHub repo.