Software Factories Without the Buzzword: Full-Lifecycle Development at Whatever Scale Fits
The phrase of the season, stripped of buzzwords. What a software factory really is, who actually needs one, and why a single laptop can run one.
Somewhere in the last year, “software factory” became the phrase of the season. Microsoft now describes its own transformation as an agent factory. Vendors sell software factory platforms that promise to turn bug reports into shipped software. Listen to the pitch alone and you would think a factory is something a company with hundreds of engineers buys: a building full of agents running pipelines while managers watch dashboards.
Strip the buzzword and the idea is much older, and much smaller, than the pitch implies.
The factory dream is nearly sixty years old
The term dates to 1968. R. W. Bemer, an engineer at General Electric, proposed a software factory in an IFIP position paper on the economics of program production: software built the way cars are, in a controlled environment with standard tools and every step measured, according to his IEEE profile. The same year, at the NATO Software Engineering Conference in Garmisch, the field coined the phrase “software crisis,” and Douglas McIlroy argued for software assembled from mass-produced components. Hitachi opened the first named example, its Software Works, in 1969, and Japanese firms ran the model at scale through the 1970s and 1980s. Microsoft gave the idea another life in 2004 with a book called Software Factories.
Every wave of automation has revived the dream since. That history matters because it explains the pitch: a factory is what people claim whenever tooling gets good enough to industrialize. The tooling changed. The dream did not.
What a factory actually is
A software factory is not a product you can buy. It is a configuration: people, process, and tooling arranged so that software moves from request to release through repeatable steps, with a quality gate and a human review between them. Requirements and bug reports go in one end. Deployed, tested software comes out the other. The stations in between are the full development lifecycle: intake, planning, implementation, testing, review, release, and the monitoring loop that turns field reports into new inputs.
None of those stations require a factory building. They require decisions about how work moves from one station to the next, and who approves it at each gate. That configuration is what actually scales, and it exists at every size.
Three sizes, one lifecycle
An enterprise software factory is mostly coordination. Thousands of developers, dozens of repositories, compliance obligations, and a review culture that needs a paper trail. The machinery that matters is the plumbing between systems: an issue tracker that feeds pull requests, continuous integration that runs tests on every branch, required approvals before anything merges, a deployment pipeline, and integrations that let input arrive where people already talk, like Slack. When a company says it runs a software factory, that plumbing is the substance of the claim.
A small team needs a fraction of it. Git, an issue tracker, a CI service, and a rule that someone reviews every change will carry a five-person shop a long way. The tools are cheap. The habit is the investment.
A solo developer needs almost none of the coordination machinery, because there is no one to coordinate with. But the solo developer still faces the same lifecycle. Code still needs planning, testing, review, and a repeatable way to ship. This is where agentic AI changed the math: one person with an agent harness can now run the whole lifecycle, and most of the factory stations can be implemented as skills.
Here is what that loop looks like when it is working. A customer reports a broken export in Slack. The harness picks up the report, opens a ticket, and routes the work through a bug-fix skill that starts from a reproduction. A fix becomes a pull request. CI runs the test suite, an automated review checks the diff, and the change sits until a human approves it. Approval triggers the deploy, and the monitoring step feeds anything that breaks back into the same queue. None of the stations are exotic. Every one is an ordinary product you can install or a skill you can write yourself.
Skills are the factory at human scale
The connection worth making: a well-written skill set implements much of what people now call a software factory. Skills are the stations, packaged as files. I compared the major skill sets in the last post: a brainstorming skill handles intake and planning, test-driven development skills enforce a quality gate, a code review skill acts as a second set of eyes, and a finishing skill walks the work to merge and deploy. Superpowers is one complete example; my own agent runs a version of it. When I ask it to build something, the first move is a planning skill that interviews me about what I actually want, and only then does implementation start. Nothing about that sequence needs more than one machine.
The stations that are not skills are ordinary services. Hermes Agent, Claude Code, and Codex are the harnesses that run the skills against your files. Git holds the work. GitHub Actions runs the tests on every push. The harness’s configuration file sets the rules, and you sit at the gate. No fleet of agents is required. One agent, following a process on purpose, with tests and a person reviewing, is a software factory at human scale. It just does not look like the ones in the marketing.
What you need is the principles, not the plant
The factory principles apply at every scale: repeatable process, quality gates, captured procedures, a human approving what ships. What does not scale down is the plant. The shared queues, the fleets of agents, the governance boards, the coordination infrastructure built for hundreds of contributors. A large organization genuinely needs that infrastructure, because coordination is its bottleneck. An individual or a small shop would be buried by it. Confusing the plant for the principles is how you end up buying a factory you do not need.
Match the plant to the coordination problem, not to the marketing. And remember the loop: most new setups deploy and then stop watching. The feedback station, the thing that turns a broken export in production into a ticket in the queue, is where a factory earns its keep. It is also the cheapest station to add, because it is mostly habits: CI notifications, an issue template, and a habit of reading what the field reports.
If you are new to AI-assisted development, do not adopt the word. Adopt one station at a time. If your agent produces code that never gets tested, add a testing skill and a CI check. If it builds the wrong thing, add a planning step that makes you say what you want before code exists. If nothing gets reviewed, sit at the review gate yourself. This is how the configuration compounds, and the earlier posts in this series are a guide to each piece: the harness architecture, the configuration files, and the skill sets.
The factory is an old dream because the promise keeps coming true: repeatable process, fewer surprises, software that ships because the steps around it are deliberate. What changed recently is that the whole floor can run on one laptop. Configuration tells the agent who it is. Skills tell it how to work. You hold the gate. That is the factory, at whatever scale fits you.