What a Software Factory Actually Is, from Hitachi in 1969 to AI Agents

Part three gave one agent a spec. A factory runs many of them on one line, and the idea is fifty years old. What a software factory is, why every era rebuilt one, when it fails, who runs them, and one real factory followed from a whiteboard to production.

In 2017, at an air operations centre in Qatar, the plan for refuelling aircraft over the Middle East was drawn on a whiteboard. According to Airman Magazine, it was an eight hour task for six people, every day. A team of about a dozen airmen and civilian programmers replaced the whiteboard with an application in 120 days. After that, one person did the job in three hours.

The team was Kessel Run, and the United States Air Force called it a software factory.

The phrase is everywhere again this year, now attached to pipelines of AI coding agents. It is older than most of the people using it. Hitachi opened a software factory in 1969. So before the word gets worn out, here is what it has meant, what it was for, and where it broke.

What it is

A software factory is a way of building software where the process is fixed, the parts are reused, the routine steps are automated, and every piece of work moves along the same line from a request to a release. You stop deciding how to build each project, and you only decide what to build.

The meaning changed with every era. The parts did not.

1. 1968 to 1990, the Japanese factories. Bob Bemer at General Electric described a factory in 1968 as a programming environment with "measures and controls for productivity and quality". Hitachi opened its Software Works in 1969, Toshiba its Fuchu factory in 1977, and NEC and Fujitsu followed. Michael Cusumano at MIT studied them for his 1991 book, Japan's Software Factories. He described the move away from "craft or job-shop modes" towards standard methods, reusable components, a division of labour and strict quality control.
2. 2004, Microsoft. Jack Greenfield and Keith Short published Software Factories. Their definition was narrower: "a development environment configured to support the rapid development of a specific type of application". The idea was to find what repeats in one kind of application and turn it into frameworks, small languages and tools that assemble the rest.
3. 2017 onward, the United States Department of Defense. Kessel Run came first. By February 2022 the department counted 29 software factories, including Platform One, the Army Software Factory and Kobayashi Maru for the Space Force. Here the factory is a delivery pipeline. Code is built, tested, approved and released with as few human handoffs as possible.
4. 2025 onward, AI agents. StrongDM's factory, started in July 2025, has two rules: "Code must not be written by humans" and "Code must not be reviewed by humans". Stripe's Minions open over 1,300 pull requests a week, with no human written code and a human review on every one. Vercel's Foreman puts an agent on each stage and stops at a draft pull request.

The same line, four times

Hitachi, Microsoft, the Department of Defense and the agent pipelines each built these five parts, with different tools in each box.

Why every era built one

Each era had the same complaint: projects ran late, cost too much, and shipped with too many defects. The factory was the answer every time, and the numbers it was judged on stayed the same.

The Japanese figures are the most detailed, and they come from the companies themselves, as Cusumano reported them:

1. Toshiba. Output went from 1,390 to over 3,100 lines per person per month between 1976 and 1985. Reused code went from 13% to 48%. Major faults after final test fell from between 7 and 20 per thousand lines to between 0.2 and 0.05. Cusumano names reuse as the main reason.
2. Hitachi. Projects delivered late fell from over 72% in 1970 to about 12% on average between 1975 and 1985.
3. Fujitsu. Defects in its basic software fell from 0.19 to 0.01 per thousand lines.

The Department of Defense had a more expensive version of the same problem. The contract to modernise the air operations centre software grew from $374 million to $745 million and slipped more than three years before it was cancelled. FedScoop reported in 2018 that Kessel Run took about 124 days from an idea to operational use, against "on the order of eight years" on the traditional route.

The AI factories add a new reason. When an agent can write code faster than a person can read it, the bottleneck moves to deciding whether the code is right. The factory is how you decide that without a person at every step.

When it works, and when it does not

The model works when the work repeats. Cusumano found that factories needed "a product focus" and did best on similar projects. Greenfield argued for one specific type of application, not software in general. Stripe's agents do best on configuration changes, dependency upgrades and small refactors. The pattern is the same each time: a narrow domain, well defined tasks, and many of them.

It fails when the work does not repeat, and the history has plenty of examples:

1. System Development Corporation opened the first American software factory in 1975. After its leader left, it "fell gradually into disuse" and then closed. One project's specification ran a year late, and the programmers at the end of the line had nothing to do.
2. Hitachi's first reuse library failed in the early 1970s, because nobody yet knew how to write a module that somebody else could reuse.
3. Fujitsu found that a central factory did not suit work that needed close contact with the customer.
4. Microsoft's factories never caught on. In 2007 The Register said the effort "may prove no more than an interesting experiment". Greenfield himself called the runtime "primitive".
5. Kessel Run had an outage during the Afghanistan evacuation in August 2021. Its commander later wrote that known scaling work had been put off. The call to fix it lasted twelve hours.
6. The Space Force command and control program that Kobayashi Maru builds for was five years into development in 2023. The Government Accountability Office found it had not yet replaced the most critical system it was built to replace.

The AI version has one more problem. Stanford's CodeX centre put it plainly in February 2026: "the same class of technology that writes the code also decides whether the code works". I wrote about that in Stop Letting AI Mark Its Own Homework, and a factory makes it worse, because it multiplies whatever the judge gets wrong. The productivity evidence is also thin. In 2025, METR measured experienced developers as 19% slower with AI tools while they believed they were 20% faster. Its February 2026 update calls the evidence for a speedup "only very weak".

Who builds them, then and now

Then, a factory took a big organisation with a lot of similar work. Cusumano's tables give Hitachi's Software Works about 4,000 staff and Fujitsu's systems engineering group about 5,000.

1. In Japan, the computer makers built them: Hitachi, Toshiba, NEC and Fujitsu. Toshiba's factory was led by Yoshihiro Matsumoto from 1977 and built software for industrial control customers.
2. In the United States, System Development Corporation built the first one in 1975, for customers such as weather satellite control and the Los Angeles Police.
3. At Microsoft, architects in its developer tools group, with Greenfield and Short at the front.
4. In the military, small teams of airmen who learned the trade with Pivotal Labs, in mixed teams of engineers, product managers and designers. By 2018 Kessel Run had 13 of these teams. Its users were the planners in the operations centre, and from 2020 also NATO.

In all of these, people stood on every station. Managers designed the line, and programmers worked along it in a division of labour.

Now, the team can be tiny, because the agents are the ones on the line.

1. StrongDM's factory team is three people.
2. Stripe's engineers run the Minions and review every pull request they open.
3. Vercel publishes Foreman as a guide for anybody to build on.

The people did not leave. They moved to the two ends of the line. At the start they write the specifications and the test scenarios. At the end they decide what merges. Vercel's guide sums up the second job in five words: "You mark ready and merge."

That is the real change between then and now. Then, a factory saved each programmer from deciding how to build. Now, it saves people from building at all, and leaves them only the deciding.

How it works: one factory, one application

Here is the tanker planning tool from the opening, followed from the whiteboard to production. Kessel Run called it Jigsaw. The stages come from several accounts of Kessel Run, so the order is my reconstruction, not a document they published.

One change through Kessel Run

1. Sit with the users. The developers went to the operations centre and watched the planners work the whiteboard. The requirement was a person doing a job badly because the tool was a pen.
2. Cut a thin slice. The first version did one thing: build the refuelling plan. It did not try to replace the whole operations centre system that had just cost $745 million and failed.
3. Build in pairs, tests first. Two engineers at one terminal. That is the fixed process, and it is the same for every team.
4. Let the pipeline carry it. Every change goes through the same automated build, test and release path. Nobody hands a file to another department. By 2022, code went through the pipeline about every 3.3 hours, and a change reached production in about eight hours on average.
5. Release it to the real network. This was the step the factory could not fully automate. Moving software onto a classified network still took manual work.
6. Watch it being used, then go round again. The team shipped three, four or five versions before they said, in their words, "We're good. Push it out."

The result, from Airman Magazine: the plan took one person three hours instead of six people eight. The Air Force needed one less tanker in the air. It saved between 400,000 and 500,000 pounds of fuel a week, and the roughly $1.5 million the tool cost was paid back in a single week. Those are the Air Force's own numbers, and the sources disagree on the old baseline. I am quoting one source and naming it.

None of these stages is new. Pairing, small releases and a pipeline were ordinary practice by 2017. The factory was the decision to make every team build that way, on the same pipeline, so that the second application cost less than the first.

How it works in 2026: an agent on every stage

Kessel Run put people on every stage of the line and automated the handoffs between them. The 2026 factories keep the line and change who stands on it.

Vercel published the clearest example in August 2026, a guide to a factory it calls Foreman. Its own summary is that it "puts an agent on every stage of your development loop and keeps you on the judgment calls". A change moves through it like this:

One change through Foreman

1. A classifier reads the issue and decides what kind of work it is.
2. An analyst works out what to change. A researcher agent can join here when the work needs it.
3. An implementer writes the change. When the continuous integration run fails, it gets two attempts to fix it.
4. A reviewer reads the change, and sends it back to the implementer at most twice.
5. The line stops at a draft pull request. In the guide's own words: "You mark ready and merge."

Put that next to Jigsaw and the stations are the same. Somebody understands the request, somebody cuts it to size, somebody builds it, somebody checks it, and a pipeline carries it to release. What changed is that four of the five are now agents, and the person moved to the last station.

The scale is real at a few companies. InfoQ reported in March 2026 that Stripe's agents, which it calls Minions, open over 1,300 pull requests a week. Every one is reviewed by a person and none contains code a person wrote. They do best on configuration changes, dependency upgrades and small refactors, which is exactly the repeating work Cusumano said factories needed in 1991.

What it means today

In 2026 a software factory is a line of agents with a person at the end of it. The five parts from the first diagram are all still there, and the reusable parts look different:

1. The fixed process is a specification. StrongDM's factory starts from specs and scenarios, the documents part three was about.
2. The reusable parts are test worlds, not code libraries. StrongDM builds what it calls a Digital Twin Universe: copies of Okta, Jira, Slack and Google's applications, so an agent can run its work against something that behaves like the real service.
3. The measuring is kept away from the worker. StrongDM found its agents gaming the tests, writing code that simply returned true or rewriting a test to match the bug, according to Simon Willison's write up. So it keeps its scenarios outside the codebase, where the agent cannot see them, and scores the result as "satisfaction".

That third point is the one I keep coming back to. Toshiba measured faults after final test. Kessel Run measured how long a change took to reach production. An agent factory has to measure whether the work is right, and the worker on the line is very good at producing things that look right.

It also costs real money. StrongDM set a benchmark of $1,000 a day in tokens for each engineer, and Willison estimates that at about $20,000 a month. That is a salary spent on the line, before anybody checks what it made.

Where it is heading

The direction is clear. How far it goes is not.

Dan Shapiro drew the direction in January 2026 as five levels, from "spicy autocomplete" to what he calls the dark factory. At level 5 it is "a black box that turns specs into software", and humans are "neither needed nor welcome". StrongDM is already trying to work that way: its two rules say no person writes the code and no person reviews it.

The evidence has not caught up with the direction. METR's February 2026 update gives speedups of 18% and 4% with wide margins either side, and calls it "only very weak evidence". Stanford's CodeX centre points out that when the code is built and checked by agents, "nobody knows who is liable" when it fails. Willison doubts that shipping unreviewed code is a sensible strategy at all.

My reading, and it is a reading rather than a measurement, is that the history says where this goes. The worker was never the problem in any of these factories. The line was. Hitachi, Toshiba and Kessel Run lasted because they fixed the process, reused the parts and measured the result. System Development Corporation and Microsoft had a good idea and a line nobody kept up. Agents make the worker cheap, fast and tireless. They do nothing for the line, and the line now has to answer a harder question than it ever did: not "did it ship", but "is it what we meant".

The factories that work in 2028 will be the ones that took the measuring station seriously in 2026.

This is the fourth post in a short series on building an agentic harness. A harness runs one agent safely. A spec tells it what you meant. A factory is what you get when you try to do both for every agent, every day, on the same line. If you are building one, I would like to know which station you found hardest. My guess is the measuring. Tell me if I am wrong.

References

1. Michael A. Cusumano, The Software Factory: Origins and Popularity in Japan, MIT Sloan working paper BPS-3268-91, 1991.
2. Michael A. Cusumano, Japan's Software Factories: A Challenge to U.S. Management, Oxford University Press, 1991.
3. Jack Greenfield, The Case for Software Factories, Microsoft Architecture Journal, July 2004.
4. Jack Greenfield, Keith Short, Steve Cook and Stuart Kent, Software Factories, Wiley, 2004.
5. The Register, Software factories: an interesting experiment?, 27 March 2007.
6. Airman Magazine, Kessel Run, 5 November 2018.
7. FedScoop, Project Kessel Run and Pivotal, 15 May 2018.
8. Breaking Defense, New DIUx software saves Air Force millions of pounds of tanker gas, 19 September 2017.
9. Air and Space Forces Magazine, Making the Kessel Run, 23 March 2022.
10. Breaking Defense, The Pentagon wants to turn its 29 software factories into one ecosystem, 7 February 2022.
11. Government Accountability Office, Space Command and Control, GAO-23-105920, 8 June 2023.
12. StrongDM, Software Factory.
13. Simon Willison, StrongDM's software factory, 7 February 2026.
14. InfoQ, Stripe's autonomous coding agents, 20 March 2026.
15. Dan Shapiro, The Five Levels: from Spicy Autocomplete to the Dark Factory, 28 January 2026.
16. Vercel, Building a software factory with eve, 25 August 2026.
17. Stanford CodeX, Built by agents, tested by agents, trusted by whom?, 8 February 2026.
18. METR, Measuring the impact of early 2025 AI on experienced open source developer productivity, 10 July 2025.
19. METR, Uplift update, 24 February 2026.

---

Originally published at juliantellez.com. Part 4 of 4 in a series on building an agentic harness.

Building with AI and want it to hold up in production? Join Vibe Coding to Production, a free community where I share the spec-driven workflow I use with Claude Code and Cursor, plus free courses.