Believe it or not, but a vast corpus of knowledge on building Software Factories already exists. It's called Agile - yes, that Agile with Scrum, Kanban and other dated buzzwords that you barely hear these days - but 20 years ago they were hot, and for a good reason.
These practices developed to fix the limitations of what we'd now call the "naive" way of building software - which also happens to be the common-sense way. Why cannot we treat software projects the same way as large construction or mechanical engineering projects? Make some designs, translate into specifications, split into workstreams, and deliver?
Turns out, software projects don't work this way. If you really want to, you can try - but then it will likely take N times longer and the final result will be completely wrong, despite matching your specification to the T. And the reason for this has nothing to do with technology or with social dynamics between people building it.
Software is a crude approximation of some aspects of the real world, a model of sorts. But unlike with construction or hardware, most of the properties of what's being modelled are not known at the start of the project. It's simply nowhere to be found - it is not in anyone’s head. Only tiny fractions of it were done before (and for that we have reusable libraries) - but the bulk is completely unknown, and needs to be discovered along the way.
Because of that, the common-sense approaches that optimise for efficiency don't work with software. If you first design the whole thing, then architect it, then plan it, then have teams of engineers build it, you will only learn from the real world at the very end of this process. But the proportion of unknown unknowns in software projects is so high that with a 99% likelihood after the first contact with reality you will have to make major changes if not outright start over; and you will have to repeat that loop a number of times.
What works instead is optimising for uncovering and eliminating as many unknowns as possible, as quickly as possible - aka "short feedback loops". Instead of working backwards from a pre-designed end goal like you would with a building or a machine, you structure work to optimise for frequent reality checks that reduce the unknowns bit by bit. Instead of working for months towards a Big Release, it is much better to find a way to get some users to use a half-baked prototype (aka MVP) built a couple of weeks. This will most likely produce new information that meaningfully change your understanding of what needs to be built.
For similar reasons that stem from high uncertainty in software projects you’d want your product teams work in sprints of 1-2 weeks max (Scrum), ship changes to production as frequently as possible (Continuous Integration), and limit work in progress (Kanban). All of these methods aren’t “people management” practices - they are “statistical workarounds” to get as much of unknown unknowns identified and resolved as early as possible. What became known later as the “shift left” principle in DevOps can be viewed as a generalisation of these approaches.
With agents, it’s not any different. Regardless of how the code gets written, most of what should be known by the end of the project isn’t known at the beginning. Just like with engineering teams, 90% of the information is not in anyone’s head - it can only be discovered by making contact with reality. So same statistical workarounds apply - it is just faster now. What took a human engineer several hours or days, an LLM can produce in minutes.
So what does it mean for software factories?
Successful software factories will work shockingly similar to high-output engineering teams under the hood. All the counterintuitive statistical workarounds that allowed humans to take on progressively larger software projects apply here as well, just adjusted for shorter time scales - imagine something like a “squad” of agents shipping major features in 2-hour sprints.
We will likely see a new breed of tools that requires 100% attention from the “maker” using them, but running continuously on the server in multi-player mode. The reason is again purely empirical, nothing to do with technology. It is simply more efficient for humans to focus on one thing at a time. Context-switching is cognitively expensive, and I think this is why a small number of interactive CLI sessions remains the most popular way to use Claude Code and similar agents: you just get more done this way.
Bad news for software consultancies / agencies / dev shops. Their entire business model is producing “bespoke” software, just like made-to-order clothing. And we now have a “factory method” so to speak. Every bit of techical work that can be outsourced - as in does not require iterative refinement along the way - can also now be automated.
Some great books and materials on the topic:
- 1975 - The Mythical Man-Month by Frederick P. BrooksJr.
- 1999 - Extreme Programming Explained: Embrace Change by Kent Beck
- 1999 - Refactoring: Improving the Design of Existing Code by Martin Fowler
- 2003 - Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck
- 2004 - User Stories Applied by Mike Cohn
- 2005 - Agile Estimating and Planning by Mike Cohn
- 2010 - Continuous Delivery by Jez Humble and David Farley
- 2010 - Kanban: Successful Evolutionary Change for Your Technology Business by David J. Anderson
- 2011 - The Lean Startup by Eric Ries
- 2014 - Spotify Engineering Culture by Henrik Kniberg (Part 1, Part 2)
Build your software factory is easier on OpenComputer