Software factories have a history stretching back nearly sixty years. Large language models expand what we can automate within them. What they do not supply is the part that makes a factory yours. A company’s own developers, working with the people who know its customers and operations, build and evolve the workflows, integrations, controls, and feedback that reflect how that company competes. Judge a packaged factory on that point: how much of that work it lets those developers do, and whether it improves cost, speed, and reliability while they do it.

At the 1968 NATO software engineering conference in Garmisch, Robert Bemer described a software factory: a machine-controlled environment for building, testing, and controlling programs. Customizing was on his list of what that environment would control. In the same report, Douglas McIlroy made the case for mass-produced software components. Hitachi established its Software Works in 1969, the first facility labeled and run as a software factory. By 1970, Winston Royce had documented the distinct stages of delivering a large software system, including iteration between neighboring stages. Michael Cusumano’s 1989 history of the software factory already treated that sequence as one idea: standardized tools, management controls, modularity, and reuse. That history shows the factory predates the model. It does not show that a model adds nothing new to what a factory can automate.

The method follows the product

Car manufacturing is a useful comparison because the improvements differ with the car.

Ford’s moving assembly line changed how people assembled a vehicle from many parts. Tesla later used a single-piece rear underbody casting on versions of the Model Y, pouring one structure where a line had been welding dozens of pieces. Each change fit the product being built.

Now imagine every customer agreed to drive the same practical, boxlike vehicle. The same shape, the same features, enough room to bring lumber home from Lowe’s or Home Depot. Nobody chooses it to express an identity. If performance, quality, and service were identical too, manufacturers would compete on price and on what the vehicle costs to operate. Customers who want affordable transportation can accept that bargain. It is a thin basis for a company that has to sell a car people choose.

When the bargain applies

The boxlike car competes on price because that thought experiment also made performance, quality, and service identical. A software factory becomes the same bargain only when it leaves no room for a different business model, customer experience, or operating constraint.

A factory can standardize production and still accept different requirements, architectures, business rules, and acceptance criteria. The Department of Defense describes software factories that run multiple pipelines, serve multiple projects, and are tuned for different kinds of systems . Bemer had already put customization on the factory’s list.

The criticism that holds is narrower. A factory with too little room for the decisions that make a business distinctive can constrain that distinctiveness. Identical software capabilities cannot, by themselves, distinguish Lowe’s and Home Depot, Target and Walmart, or AWS and Azure. Integration, data, and use still can. For a capability that provides no distinctive advantage, competing on the cost and speed of delivery can be the right call.

If a company accepts the same application as its competitors, it may have little reason to fund developers to build that application again. Much of that work can sit with a shared provider, and the customer may still need engineering for its integrations, data, and operations. Where the company competes through distinctive software, its developers help turn that difference into something the factory can reliably deliver. They build and evolve the requirements, integrations, controls, and feedback that support it as the business changes.

Build the factory you compete with

Design the development lifecycle around the product, the people, and the business. Standardize the routine work. Keep authority over the choices that create value. How well a company combines the two can be an advantage of its own.

The company’s developers do that building, alongside the people who understand its customers and operations. Developers translate that business knowledge into the workflows, integrations, controls, and feedback that make the factory useful to this company. Shared platforms and purchased tools can supply much of the foundation. Developers build and evolve the parts on top of it that reflect how the company competes, and they keep changing those parts as the business changes. Their ability to improve that production system contributes to the company’s competitive advantage.

Seen from the developer’s side of the line, the difference is the part being made. Steel and a tool that cuts it can produce a car part or a small surgical instrument. The metal and the cut do not decide which one you get. What the part has to do, how exact it has to be, and the jig that holds the steel while the tool works decide that. A tool that can cut anything is a starting point. A factory is the structure built around that tool for a particular part, by people who know what the part is for.

Speed without acceptance is one place this goes wrong. A line that produces changes faster than anyone can responsibly accept them manufactures a backlog, which is the failure I described in The Dead Dark Factory . The factory earns its keep when the output is reliable and the business can use it.

Fix the station before you automate it. A factory is not a label, and a model is not a repair. If a station is not following its discipline today, because a check is skipped, nobody enforces a gate, or feedback arrives after the work has moved on, adding a model makes that station faster at producing the wrong result. Go to that station. Establish the correct way to produce its part, make the check real, and make the feedback arrive while the work can still change. Then a model can enhance that part of the line. The discipline has to exist before it can be automated.

The useful question is where a model earns its place along that line.

Automate the step when the result is reliable and a person would only repeat a check the line can already make. That is the step a jig already holds: the path, the test, and the feedback, with nobody required to watch. A step the model can still talk its way past is not ready for that.

Assist when the model makes someone faster and that person still owns the result.

Leave the decision with a person when the outcome depends on context that lives in the business or on risk the company carries. Business context changes, so its representation in the factory needs continuous validation.

Those answers change across requirements, design, coding, testing, deployment, and operations. They change again from one company to the next. A test that can be generated and checked is a different station from a requirement that says what a customer will pay for. The factory has to support meaningful changes to requirements, workflows, controls, and acceptance criteria. That support belongs in the factory for the company that will live with the result.

Keep improving the stages you already have. Shared tools, your own context, your own controls, your own judgment. The factory that comes out of that work should be recognizable as yours, shaped by what you build and by how you compete. Put the model where it makes that output more reliable, and where the output is worth more to the business.

If supply concentrates

Supplier concentration is a separate question, and it is conditional. Price competition among identical offerings can favor whoever holds more of the chain that produces them. That does not establish a single manufacturer, the end of software as a distinctive advantage, or the end of people writing software. Those would take causes this post does not have.

In 1930 Hearst’s papers, the largest consumers of newsprint, bought a minority stake in a Canadian paper company and opened negotiations for timber and waterpower . The same report says the papers would continue paying market prices. The stake protected future supply. It is an example of partial vertical integration, not of a publisher who could set the price from the tree to the page.

Terafab is the chip complex Tesla and SpaceX have said they will build and run. Texas announced it for Grimes County in August 2026, and the project filings describe power plants on the site . Gigasat , in Bastrop, is the factory the companies describe for the solar panels and the AI satellites. Scale and dates in those announcements belong to the companies making them. What the plans show is vertical integration across power, chips, panels, and satellites. They do not show that the software must come out identical, or that one supplier is the necessary result.

If a buyer accepts a factory that cannot vary the decisions that make the business distinctive, and if the means of building that software sit in few hands, little remains to compare besides price. Shopping will be easy. That is the warning, and it is a conditional one.

Either way, the question for a company is which development capability it needs to retain in order to compete. For the parts it shares, that work can sit with the provider. For the parts that carry its difference, its developers build and improve the factory that delivers them: fixing the stations that do not follow their discipline, holding the context as it changes, and putting the model where it enhances production. Their responsibility for that production system is the takeaway.