The Software Factory Died Twice. Here Is What Has to Be True for the Third Time.

There is a phrase going around again. Software factory. Digital factory. Agentic software factory, if the deck has a budget behind it.

I like the idea. I also recognise the smell. This is not a new word, it is a reheated one, and the two previous times we served it, the room went quiet afterwards. Nobody selling it in 2026 seems especially eager to bring that up, which is usually a sign the history is worth thirty seconds of your time.

So: two obituaries, then the part that is genuinely new.

The first death: Japan actually built the thing

In the 1980s, Hitachi, Toshiba, NEC and Fujitsu built real software factories. Not a metaphor, not a McKinsey diagram. Buildings, with process control, standardised methods, reuse libraries and quality gates, run by people who had already industrialised cars and televisions and saw no reason software should be special.

And here is the annoying part for everyone who wants this story to be a simple failure: it worked. Toshiba's Fuchu works took code reuse from 13% in 1979 to 48% by 1985. Output per person went from roughly 1,390 lines a month in 1976 to over 3,100 by 1985. Michael Cusumano wrote a whole book about it in 1991 that was, essentially, a warning to American management. Those are not vanity numbers. Most engineering organisations I have worked with could not produce a metric that clean today.

Then the eighties ended, and the thing they had built turned out to be excellent at exactly one kind of software: routine, specified, production-shaped work. Automate a plant, drive a robot, run a switch. Where it struggled was operating systems and applications, the stuff where nobody hands you the spec because nobody knows what it is yet. The factory could execute an answer beautifully. It was not built to find one.

Japan came out of that decade with world-class hardware and no globally competitive software industry. The factory was not a fraud. It was a very good machine pointed at a subset of the problem.

The second death: US Defense built twenty of them

Fast forward. Kessel Run, Platform One, and by some counts around twenty other Air Force software factories. Same instinct, different desperation: the acquisition process was so slow that the only way to ship software was to build a small country inside it that had different rules.

The early wins were real, and a generation of defence engineers learned modern practice there. I do not want to be glib about that.

But read what the community said about it afterwards, because it is brutal and it is coming from insiders, not critics. Software factories were measuring the wrong things, or in some cases not measuring at all. They built platforms and polished slide decks while shipping relatively little that a user in the field actually wanted. There was not enough talent in the Air Force to staff twenty platforms, so most of them were not good. The word people ended up using was innovation theatre. Kessel Run has since shifted to a vendor-led model.

Two very different cultures, forty years apart, and the same shape of failure. That is not bad luck. That is the metaphor doing what the metaphor does.

The thing factories do to you

A factory is a machine for maximising throughput of a countable unit. That is the entire idea, and it is a magnificent idea when you know what the unit is. Cars. Bottles. Switches.

The problem is that in software, the countable unit is never the valuable one. Lines shipped, tickets closed, PRs merged, story points burned down. Every one of those correlates with value right up until you start optimising for it, at which point it stops, because you now have a machine whose job is to produce the proxy.

Japan optimised reuse and process discipline, and got a system that could not do discovery. Defense optimised escape velocity from procurement, and got a system that measured its own existence. Both got exactly what they built for.

So when someone tells me they are building an agentic software factory, my first question is not about the agents. It is: what is the unit, and what happens to this organisation when we get very, very good at producing it?

What is actually different this time

Now the fair part, because something has genuinely changed and it deserves a straight answer.

The old factories automated everything around the coding. Planning, tracking, integration, release. The code itself was still typed by a person, so the person remained the throughput ceiling and everything else was scaffolding around them. The agentic version automates the coding step. That is a different machine, not a faster one.

And it is not hypothetical. Uber published theirs this year and the numbers are hard to wave away: over 70% of their pull requests are now attributed to local or cloud agents. Between February and August 2026, weekly active users across their agentic tooling grew 7x and weekly agentic requests grew 9.4x. BCG Platinion claims 3 to 5x productivity for organisations operating this way, citing among others Spotify at around 650 AI-written PRs a month. I would treat the consultancy number the way you treat any number a consultancy puts in a headline, which is to say: directionally interesting, contractually optimistic. Uber's, I take seriously, because they published the plumbing alongside it.

And that plumbing is the part that should reset your planning. It is also the reason I think most companies attempting this in 2027 will produce the third obituary.

An AI Context Graph of 24 million nodes and 80 million edges, 86 node types across more than 30 internal systems, so an agent does not have to interrogate your entire estate to learn what the company already knows. Over 3,600 agent skills built across the lifecycle, running more than 30,000 executions a day. Every tool interaction routed through one gateway fronting over a thousand MCP servers, so authentication and policy live in one place instead of thirty. Then uReview grading pull requests, and a house benchmark built from real PRs with known bugs, scoring models on precision, recall and F1, plus cost, latency, timeouts and noise.

Notice what almost none of that is. It is not a model. It is librarianship, plumbing, permissions and grading. It is someone writing down what the company knows in a form a machine can read, which is a job most organisations have been actively avoiding since about 2006.

The cost discipline tells the same story. Uber got cost per thousand model requests down 34% and cost per session down 52% from its June peak, not by finding a cheaper model but by cutting schema overhead and measuring which model was actually worth paying for on which task. That is not an AI achievement. That is an engineering organisation behaving like one.

BCG has one line in their material I would put on a wall: teams that skip codification risk automating chaos. That is the whole risk in six words. An agent does not clean up your mess, it industrialises it, at machine speed, with a very confident tone of voice.

What has to be true for the third one to work

I do not think the software factory is a bad idea. I think it is an idea that has been consistently attempted one layer too high. Here is what I would want true before I let anyone call it a factory.

Your company is legible to a machine. Not documented. Legible. Ownership, dependencies, decisions, past incidents, the reasons behind the weird bits, all queryable rather than tribal. Uber built the context graph for a reason. If a new senior hire needs six weeks to become useful in your codebase, an agent will not do better; it will just be wrong faster and never ask. This is the same argument I made about terrain rather than stages: the ground decides the result, and the factory is just a very expensive way to find that out.

You know where the bottleneck moves next. This is the one nobody plans for. If agents write 70% of your PRs, the constraint is no longer writing. It is review, verification and the human who is accountable when it breaks. Look at what sits in Uber's stack next to the agents: uReview on pull requests, and a benchmark built from real PRs with known bugs so they can actually tell whether the reviewing is any good. That is not decoration. That is an organisation noticing that generation volume lands on the approval layer, and building the dam before the water arrives. If you scale generation without scaling verification, you have not built a factory. You have built a firehose pointed at your most senior engineers, and they will leave.

You are counting an outcome, not an output. Both previous factories died measuring their own activity. If the dashboard says PRs, throughput and agent hours, you are already in the failure pattern. Count the thing the business would notice if it stopped.

You have decided what stays human on purpose. Not what humans happen to still be doing because the tooling has not caught up. An actual decision, written down, about which judgements do not get delegated. Japan's factory could execute an answer but not find one, and that limit only becomes dangerous when you forget it is there.

You are honest that this is an operating model change, not a tooling change. BCG's own long-running number is that 70% of digital transformations fall short. Not because the technology failed. Because the organisation around it did not change shape. Buying agents and keeping your existing approval structure is the most expensive way to discover this.

The short version

The factory metaphor has never failed because the engineering was wrong. It failed because a factory is superb at producing whatever you point it at, and both previous times we pointed it at something easier to count than the thing we wanted.

This round the machine is genuinely more capable, which means the pointing matters more, not less. The agents are the easy part; you can have those next week. The hard part is writing down what your company knows, and being disciplined about what you are actually counting.

Get those two right and I think the third attempt sticks. Get them wrong and someone writes a very similar post in 2031, with better graphics.

Sources

Everything I have quoted here is someone else's number, so here is where each of them comes from.

• Uber Engineering, Running a Software Factory Efficiently at Uber Scale (2026). The context graph, skills, gateway, uReview, benchmark, cost and growth figures. Worth reading directly: several summaries of this post in circulation quote figures that are not in it.
• BCG Platinion, The Agentic Software Factory. The 3 to 5x claim, the Spotify figures, and the line about automating chaos.
• Michael A. Cusumano, Japan's Software Factories: A Challenge to U.S. Management (Oxford, 1991). The Toshiba Fuchu reuse and output numbers, and the limits of the model.
• Rise8, Kessel Run Post-Mortem, and Defense Opinion, Defense Software Factories Need a Major Reset. The insider assessment, including the innovation theatre line.
• Air & Space Forces Magazine, Kessel Run Is Pivoting. The shift to a vendor-led model.
• BCG, Flipping the Odds of Digital Transformation Success. The 70% figure.