The software factory returned to enterprise vocabulary in 2026, this time with autonomous coding agents inside it. Consultancies now describe delivery organisations where agents build, test, and ship continuously while people define business intent and review outcomes, with organisations at that level reporting average productivity gains of three to five times.
The term is older than most of the people using it. Hitachi opened the first facility labelled and managed as a software factory in 1969, and Toshiba, NEC, and Fujitsu followed with standardised processes built around reuse, automated tooling, and quality control. The stated motive then is the one cited now: difficult technology, a shortage of skilled engineers, and projects too large to run as craft work.
That history matters because the model has been rebuilt twice since, and both times the same thing happened. Output went up. The constraint moved somewhere else.
01The idea has already been rebuilt twice
The Japanese factories of the 1970s and 1980s produced genuine gains in defect rates and cost control. Their limit was structural rather than technical: a factory is efficient to the degree that the next thing it builds resembles the last, and internal business software rarely obliges.
The second rebuild was defence. Kessel Run, the US Department of Defense's first modern software factory, was founded in 2017 and borrowed the manufacturing language deliberately, to make software delivery legible to leaders accustomed to aircraft production. Platform One, Black Pearl, and the Army Software Factory followed. By 2025 the model had been audited by the people who built it: a State of DevSecOps report that March counted more than fifty software factories existing in name, with only a few delivering real outcomes, and Kessel Run's own founder has written that the model was diluted into platforms and pipelines, technology rather than people and process.
Every version of the software factory industrialised the part of the work that was visible and countable. That part was never the constraint.
Skaleminds Advisory Team
02What the agentic version genuinely changes
The 2026 version differs in one respect that deserves credit: the throughput claims are specific, and some of them come from operators rather than vendors. Spotify has reported merging roughly 650 AI-generated pull requests a month and cutting large-scale migration time by around 90%. Read these as company-reported figures, not independent measurement, and they still describe a real change in build economics.
For an operations leader, three consequences follow, and only the first is about speed.
- The build compresses. Work that was priced in person-months is now priced in person-days, which changes what is worth building at all.
- The build-versus-buy line moves. Custom tools that could not previously justify their cost now sit below the threshold where configuring a package was the only sensible answer.
- Maintenance budget becomes available. Legacy modernisation shelved for being too expensive becomes arguable again, which frees spending that was structurally stuck.
The gains are real and they are narrow. Every serious account of the agentic factory, including the ones selling it, concedes that output quality depends on how precisely an organisation can state what it wants, and that agents are only as effective as the codified knowledge they can reach. Neither capability is included in the purchase.
03Where the cost moves
Throughput is the metric AI inflates, which makes it the wrong one to buy on. GitClear's analysis of 623 million code changes between 2023 and 2026 found refactoring line moves down 70%, cross-file function calls down 35%, and long-term legacy maintenance down 74% against 2022 levels, alongside an 81% rise in duplicated code blocks. More code ships; less of it is reused, and more of it is rewritten shortly after it lands.
Delivery data points the same way. Google's DORA research found that each additional 25% of AI adoption corresponded to roughly 7% more delivery instability, and a randomised controlled trial by METR found experienced developers took 19% longer with AI tools while believing they had been 20% faster. That trial used sixteen developers on mature open-source repositories they knew well, so it does not transfer directly to new internal tools; the perception gap does transfer to anyone buying on self-reported productivity.
Security is the least ambiguous of the three. Veracode's testing across more than 100 models found 45% of generated samples introduced an OWASP Top 10 vulnerability, with no improvement across cycles from 2025 into early 2026, and a scan of 5,600 publicly deployed applications built on AI app builders found roughly 2,000 critical vulnerabilities and 400 exposed secrets in production.
04The question that survives all three waves
What the three waves share is what each of them industrialised: the visible, countable part of the work. What none of them industrialised is choosing which problem to solve, obtaining access to the systems holding the data, and owning the result once the builders move on.
That is why the defence factories were eventually told to measure mission outcomes rather than delivery cadence. It is also why the agentic accounts concede the knowledge problem: architecture decisions live in message threads, business rules live with long-tenured staff, and a factory pointed at an undocumented business will build quickly against the wrong assumptions.
What this means in practice
Four questions separate a factory that helps from one that produces volume: which problem was chosen first and on what evidence, whether you can watch the system being built rather than see a finished demo, who owns the source code and data, and what the next change costs after the first engagement ends. Our own model carries a trade-off worth stating plainly: building a first tool in 5-7 days concentrates the risk in the discovery conversation, because a fast factory aimed at the wrong problem produces the wrong tool quickly.
This holds regardless of sector or company size: the factory metaphor keeps returning because building is the part of software that is easiest to see and easiest to count. Judge any delivery model, agentic or otherwise, on what it leaves behind and who can maintain it, not on how much it produces.