journal / retrospective
a brief history of
the software factory.
the software factory did not begin with coding agents. For decades, people have been asking a related question: which parts of creating software can become repeatable, without making every product the same?
this is a history written today, not an archive of posts from those years. The dates below identify the developments and source documents.
1968
reusable parts
At the NATO software engineering conference, M. D. McIlroy proposed families of reusable software components. The ambition was to make reliable building blocks available to other programmers, rather than rebuild each program from scratch. This is an early conceptual root, not evidence that McIlroy invented the term “software factory”.
NATO conference report, section 8.2
conference: 7–11 October 1968 · report: January 1969
1969
a factory becomes an organisation
Hitachi’s history records its software factory becoming independent from the Kanagawa Works in 1969. Here, the factory was an organisational idea: a dedicated operation for developing software. It was not a promise that software could be produced without people.
Hitachi’s software business history
event year: 1969
1999
families, not identical copies
The Software Engineering Institute described software product lines built from shared assets. Reuse extended beyond individual code components to the engineering and organisational practices needed to create related products. Variation was part of the system, rather than an exception to it.
SEI: a framework for software product line practice
source edition: September 1999
2000
a repeatable build
Martin Fowler and Matthew Foemmel documented a process that automatically built and tested software throughout the day. Continuous integration helps explain how delivery could become more repeatable. The article’s date is a milestone in documenting that practice, not its invention.
Fowler and Foemmel: Continuous Integration
article: 10 September 2000
2004
the software factories methodology
Jack Greenfield’s SPLC keynote described Microsoft’s Software Factories methodology: product lines, models, components, patterns and automation. The aim was to capture knowledge about a domain so that related applications could be assembled more systematically.
SPLC 2004 keynote abstract
keynote year: 2004
2010
delivery becomes part of the system
The Continuous Delivery book helped articulate a broader goal: keep software deployable and make releases routine. The factory’s useful boundary could no longer end at a successful build. Tests, environments and deployment were part of the work too.
Jez Humble: Continuous Delivery
book publication: 2010
2023
shared platforms
CNCF published a white paper on platforms for cloud-native computing. Internal platforms provide shared capabilities that teams can use to build and deliver applications. This extends the reuse idea into infrastructure and developer services; 2023 dates this paper, not the beginning of platform engineering.
CNCF platform white paper announcement
announcement: 11 April 2023
2026
agents, specifications and evidence
StrongDM described an agent-driven factory in which specifications and scenarios guide implementation and validation without human code review. Three days later, Stripe described unattended coding agents whose changes still received human review. These are the companies’ accounts of their own systems. Together, they show why “AI software factory” should not be treated as one universal level of autonomy.
StrongDM: Software Factories and the Agentic Moment
StrongDM: 6 February 2026 · Stripe: 9 February 2026
Stripe: Minions, one-shot end-to-end coding agents
Vercel’s September 2026 explainer offers another framing: repeatable agent work, checks and acceptance, with automatic merging optional.
what we take from this
the recurring ambition is repeatability. The reusable unit has expanded from components to product assets, shared platforms and agent workflows. That is our interpretation of these sources, not a claim that one approach inevitably led to the next.
for a buyer, the useful question is less “how automated is the factory?” and more “how will we know the result works?” Clear scope, meaningful checks and responsibility for the outcome still matter.
Software Facto offers software factory as a service, starting with a free assessment and bespoke pricing. The historical examples here describe other organisations; they are not claims about our delivery machinery.
let’s exploreThis article was developed with AI assistance and checked against the linked sources. Our editorial approach.