What Is a Software Factory?

Earlier this year, our team at 8090 took apart the billing engine of a large entity. It was 18 million lines of COBOL and Assembly that had been accumulating since before some of our engineers were even born. Nobody fully understood it anymore but by using our Software Factory, we reverse-engineered it into more than 100,000 plain-English rules in 40 days. In finishing that work I realized why the phrase "software factory" was suddenly being used by everyone else as well.

The concept is being appropriated because it implies a certain level of industrial reliability that enterprises want but aren’t getting. Software factories have fifty years of history behind them, and its singular defining feature is something that enterprises need more than ever - a production system that guarantees output. This sits in contrast to a growing frustration about a sprawling set of tools that empower individuals but are making entire systems more chaotic.

The term is older than most people realize

Hitachi opened "Software Works" in 1969 as a literal factory: a building where software was produced under statistical quality control, with defect rates measured per thousand lines of code, standardized processes and a management team accountable for output quality. Toshiba, NEC and Fujitsu followed, and through the 1970s and 1980s these Japanese software factories shipped some of the most reliable code ever written. The systems they produced ran banking, rail and power infrastructure for decades.

In 2004, two Microsoft architects published a book called "Software Factories" arguing that software should be built the way cars are built: from proven components, on repeatable production lines, with variation controlled by upfront design rather than fixed by heroics downstream. The US Air Force runs software factories today. Kessel Run builds and operates mission software for the Department of Defense, and when that software breaks they own it.

Across sixty years, one thing stayed consistent until this AI wave. A factory was never a tool or a productivity hack, no matter how good. A factory was a system of production that took inputs, produced finished goods and stood behind the quality of those goods. Said differently, Ford never sold you a wrench, some parts and wished you good luck. Ford sold you a car, and if the car failed, Ford recalled it, because it was their factory that produced it.

That is the standard, and I would argue that modern software factories must conform to it too.

The five tests

A software factory should pass five tests. Miss any one of them and you have something else. That something else is most likely a developer tool, which can be useful, but is a different product with a different obligation.

Test one: a factory starts from business intent. A factory's input is what the business needs, expressed in the language of the business: requirements, rules, regulatory constraints, desired outcomes. If the input, instead, is a Jira ticket written by an engineer for another engineer, you are looking at a power tool bolted onto an existing process. The whole point of a factory is that the customer describes the product and the factory figures out the production.

Test two: a factory maintains coherence under continuous change. This is the hardest test, and it is the one almost nobody in the AI tooling market talks about, because their products make it worse.

Writing new code was never the bottleneck in enterprise software. The bottleneck is that a real system gets changed every week by dozens of people. Every change is a chance for the system to pull apart. Requirements drift from documentation. Documentation drifts from code. Code drifts from tests. Give that drift twenty years to compound and you get the billing engine I described at the top: 18 million lines nobody understands in its entirety, a maintenance contract with vendors that go up 5 to 8% a year and an organization that can no longer change its own software without fear.

A functioning software factory keeps intent, specification, code, tests and production behavior synchronized as a single governed object. Change the requirement and the code changes. Hotfix the code and the requirement updates. Ask a vendor to show you this loop closed, live on a real system. If they cannot, they are selling code generation. And while useful, it is a different thing.

Test three: a factory operates independent of any specific person. A tool is only as good as the person holding it. Hand the same coding agent to two engineers and you will get radically different output depending on who writes the prompts, who reviews the diffs and who catches the mistakes. That variance is acceptable in a tool. It is disqualifying in a production system. A factory should produce at predictable speed and quality regardless of who is on shift, which is exactly what Hitachi's statistical controls were built to guarantee: quality as a property of the line, not the operator.

The way a factory achieves this is that knowledge compounds in the system instead of in individuals. When a person joins, the factory hands them everything it has already learned. When a person leaves, nothing walks out the door. Most enterprise software fails this test catastrophically. The reason a billing engine becomes illegible is not bad code. It is that the understanding of the code lives in people, and over many years the people change. If their knowledge is never captured by a system, the system will slowly become a black box.

To be clear, this does not mean people don't matter or that a factory doesn’t demand accountability. A factory always has someone specific who answers for the output. It just never depends on any one of them being irreplaceable. A system that needs a hero to function has neither accountability nor a factory. It has a hero, and heroes eventually find new adventures.

Test four: every unit of output is traceable. In a real factory, every part has a “lot number”. When something fails, you trace it back through the production line to the batch, the machine and the shift. Regulated industries require exactly this from software, and it is why they have been slowest to adopt AI coding tools. "The model wrote it" is not an answer an auditor accepts. A software factory produces the audit trail as a byproduct of production itself: this rule exists because of this requirement, approved by this person, implemented in this change, verified by this test, deployed at this time. Provenance has to be built into the production line which means documentation written after the fact doesn't count.

Test five: someone is accountable for the finished product. This is the test that separates a software factory from a developer tool, because it is the one most tool vendors are unwilling to meet.

A factory ships a product it stands behind. When the billing engine miscalculates a claim, when the trading system produces a wrong number, when the manufacturing validation approves a bad part, someone specific answers for it, fixes it and eats the cost. I have now read a lot of AI tooling contracts and the intellectual property sections run for pages but the accountability section is usually one sentence, and the sentence says that the output is provided as-is and verification is your problem. This is completely disqualifying for a factory.

One of our customers, a publicly traded health insurer, turned its payable-claims rules into a deterministic pre-filter and cut the claims routed to a pay-per-catch vendor by more than 80%, avoiding more than $20 million over four years. Numbers like that only happen when the party doing the work is on the hook for the result.

What isn't a factory

Apply the tests and many who call themselves a factory are, instead, something else.

Coding agents, no matter how good, are tools. They take engineering tasks as input, produce code as output, and transfer all verification and accountability to the customer's engineers. Calling a fleet of them a factory doesn't change this.

Agent orchestration dashboards are supervision tools. They make it easier to watch agents work.

Benchmarks are measurement harnesses for tools. A high score tells you a tool is good at benchmarked tasks. It cannot tell you whether your system stays coherent after two years of continuous change by mixed teams of humans and agents.

Why the definition matters right now

The cost of producing software is collapsing. And when production costs collapse, value will migrate to whoever can guarantee the output. This has happened in every industrialization process before this one and it will happen again now in AI.

The startups grabbing at the word "factory" understand this instinctively. But many are reaching for the credibility of industrial production without accepting the obligation that created that credibility in the first place.

So ignore demos and benchmarks, and ask every software factory one question: when the system breaks in production, who takes the call?

In the case of a software factory, the answer must be “we do”.