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. The reality is that code generation accelerates drift. If your agents produce ten times more code against specifications that aren’t kept synchronized, you are inducing drift at unprecedented speed. The 18-million-line problem took four decades to build by hand but agent fleets without governance will build this in a few years. 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