Digital Economy Dispatch #299 -- The Return of the Software Factory

In the 1990s, some of my earliest experiences of large-scale software development and delivery involved the concept of a software factory. The ambition was to industrialise the way large teams designed, built, and maintained complex software-intensive systems by standardising key tasks and roles, to make delivery more predictable than anything previously experienced, and to do it at managed cost. This involved reusable components, standardised processes, defined roles, and measurement at every stage. The movement's intellectual backbone came from scholars such as Michael Cusumano at MIT Sloan, whose review of Japan's software factories documented in detail how Hitachi, Toshiba, NEC, and Fujitsu had applied their production management skills to writing code. For a while it looked as though software was about to grow up and behave like manufacturing.

It didn't work out that way. The factory metaphor brought some elements of discipline, and a good deal of what became modern engineering practice can be traced back to it. But the factory floor never quite materialised, because the expensive part of software was never mass producing identical goods. It was working out what to build, coordinating the people building it, and absorbing the constant change that arrived while they were building it and after it had been shipped.

The idea did not disappear. It reappeared as the global software supply chain, and I spent a good deal of the following decade studying what that looked like inside large organisations. The lesson from that generation was not that industrialisation failed outright. It was that distributing and standardising the work moved judgement around rather than removing the need for it. Every efficiency we gained created a corresponding demand for someone, somewhere, to understand what was arriving and whether it was any good.

Which is why it is striking that with AI the term “software factory” has come back. Unfortunately, it seems to be focused in the wrong place.

The Idea Already Has a Name

In January 2026, Dan Shapiro, chief executive of Glowforge, published a five-level model of AI-assisted programming borrowed from the road vehicle automation taxonomy. Level 2, where he reckons most self-described AI-native developers are stuck, is pair programming with an AI tool, with every line co-created and verified. Level 3 is the shift where most of the code is generated, and the engineer becomes a full-time reviewer of work they didn't write. Level 4 turns that engineer into something closer to a product manager who writes specifications, checks the tests and no longer reads the code at all. Level 5 is what Shapiro calls the dark software factory: nobody reviews AI-produced code, ever. The name borrows from lights-out manufacturing, where robots work in an unlit building because robots do not need to see. Simon Willison amplified the framing days later, and it has since become one of the most widely referenced maturity models in the field.

Weeks after that, the idea acquired a working example. StrongDM, an access management and security company, described a Software Factory operating under two rules: no human writes the code, and no human reviews it. Humans define intent, specify scenarios and watch the scores. Agents generate, validate against simulated environments and iterate until behaviour converges. The company's Attractor repository famously contains no code at all, only markdown specifications intended to be fed to a coding agent. Writing at Stanford's CodeX, one commentator put the uncomfortable point plainly: a firm building security infrastructure has decided that human code review is an obstacle rather than a safeguard.

The debate this has generated is almost entirely about autonomy. How much can the machine do unaided? How far up the automation ladder is your team? I think this is the wrong focus, and the two precedents the metaphor draws from both explain why.

Two precedents, Both Misread

Start with the kitchen. A dark kitchen is not primarily an automation story. There are still people cooking. What changed was the shape of the business. Stripping out the dining room decoupled the brand from the production site, which meant one kitchen could serve a dozen restaurants that existed nowhere except inside an app. It changed who employed whom, where the margin sat, which planning and hygiene regimes applied, and how much of the operation any customer or inspector could actually see. Dark warehouses did something similar to retail. The automation mattered, but the reorganisation of the value chain mattered more.

Apply that to software and the interesting questions change character. If delivery capability can be assembled as a configuration of agents rather than a human team, then the software factory decouples from the firm in exactly the way the kitchen decoupled from the restaurant. What happens to the systems integrator whose business model rests on placing bodies? What happens to the in-house platform team whose value was continuity of knowledge? A dark kitchen serves many brands from one site. An agentic delivery capability could serve many clients' backlogs from one specification pipeline, and the winner is whoever owns the pipeline rather than whoever owns the relationship. Dark kitchens also created a major inspection problem, because premises that used to be in plain view became an industrial unit behind a retail park. For anyone working in regulated sectors or the public sector, the equivalent question for software factories should raise concern.

Now the second precedent is the one I lived through. The objection to software factories was well made at the time. When Microsoft's Software Factories was published in 2004, and a copy was provided to every attendee at OOPSLA, Martin Fowler used his conference write-up to take a deliberate shot at the manufacturing metaphor, describing an instinctive negative reaction to the book's industrialisation framing. He was careful to add that there were good ideas underneath it, particularly around domain-specific languages. But in The New Methodology he set out the objection at length: the factory model rests on a Taylorist assumption that the people doing the work are not the people best placed to work out how it should be done, and the damage the engineering metaphor does is to encourage the separation of design from construction. Software, he argued, is creative professional work, and that separation is exactly the wrong approach.

Manufacturing has since made much the same point about itself. Genuinely lights-out plants remain exceptions rather than the rule decades after the idea took hold, and for most manufacturers the realistic destination is what one industry series calls the grey factory, where partial automation lets people and machines share the work and humans handle the exceptions.

So, both precedents point the same way, and neither says what the enthusiasts want it to say. What changed in dark kitchens was where the value sat, not whether people were needed. What changed in software factories was where judgement sat, not whether it was needed. Borrowing the word "dark" and reading it as "empty of humans" gets both stories backwards.

Why Agile is a Better Starting Point

If the factory is the wrong frame, agile product delivery is the right one, and it turns out to be a much more useful place from which to think about what AI is good for.

The Agile Manifesto was a rejection of that idea that a system can be specified completely before it is built. Its authors chose responding to change over following a plan, and the second principle asks teams to welcome changing requirements even late in development. Requirements are not gathered; they are discovered, and they are discovered mainly by putting something imperfect in front of somebody and watching what happens. The iteration was never a scheduling convenience. It was a position about how anyone comes to know what a system should do.

What is interesting is that Agile teams never wanted long loops. They wanted the shortest loop they could pay for, and the price was set by how long it took to build something real enough for a user to react to. That was weeks, so sprints were weeks. The economics set the rhythm, not the philosophy.

That cost has now collapsed. A team can build three working versions of a contested feature in an afternoon and put all three in front of a user, which is what the method wanted from the beginning and could never quite afford. This is the most valuable thing AI does for delivery, and it argues for more human contact with the work rather than less.

The second thing worth pointing AI at is the drudgery. Test scaffolding, fixture data, dependency upgrades, framework migrations, the long tail of maintenance, the documentation nobody wants to write, and so on. These are the parts of delivery that no amount of human judgement improves, and handing them over frees the scarcest thing on any team, which is attention. That is the honest promise of the technology, and it is a huge step forward.

What neither of those addresses is the cost of being wrong about the user needs. That has not moved. If anything, it has risen, because a pipeline that converges in hours can build a beautiful wrong solution at a scale that makes the error much harder to spot and considerably more expensive to unwind. And this is precisely where the dark factory design fails. Agile approaches put a person at the end of the loop deliberately: a customer, a user, a product owner, somebody with a stake in the outcome and the standing to say this is not what we meant. In the dark factory, the loop closes against a scenario that was itself derived from the specification, so the system validates its interpretation of the requirement against a formalisation of the same requirement. It converges. That is not in dispute. The question is what it converges on, and consistency with a specification is not the same thing as fitness for purpose.

Ethan Mollick has reached similar conclusions. In a recent essay he uses StrongDM as his example of an early dark factory, then proposes an alternative he and Lilach Mollick call the Twilight Factory: agents do most of the work, but a facilitator agent decides when to pull humans in, for approval, for expertise the model lacks, for diversity of thought, and for the parts of the job that are actually interesting. His warning is the one I would reinforce. If agents take every interesting decision and leave people the approvals, the exceptions, and the failures, we will have automated the wrong half of the job, and we will stop producing the experts whose judgement the whole arrangement depends on.

That is the choice in front of today’s digital leaders, and it is a design choice rather than a technology forecast. The dark factory is the default, not because it is right but because removing people is the easy thing to build. Deciding where the lights stay on takes deliberate effort.

So, two questions for your next delivery review. Where has the collapsing cost of building a candidate solution let you put working software in front of a real user sooner, and if the answer is nowhere, what have you bought? And if your engineers stop reading code, who in the building will be qualified to tell you that something has gone wrong? Or how to fix it?

The software factory did not fail because the ambition was foolish. It failed because we mistook the visible part of the work for the valuable part. It would be a shame to repeat that with AI.