What is a software factory?

The term is older than the agents

A software factory is a repeatable system for turning requirements into shipped, verified software, built from shared standards, a persistent record of decisions, and automation for the work that repeats. In 2026 the automation is AI agents, and the discipline is keeping people in charge of the judgment and the approvals.

Jack Greenfield and Keith Short used the phrase in a 2004 book from Microsoft, Software Factories. Their factory was model-driven, which meant describing a family of applications precisely enough that tooling could generate most of each one from templates and patterns.

It did not take hold, for two reasons that still matter. The generation step was brittle, so a small change in requirements meant fighting the generator. And most software work was not repeatable enough to be worth modeling. The name survived mainly in government and defense procurement, where a software factory came to mean a standing team with a fixed pipeline.

What changed in 2025 and 2026

Coding agents made the generation step cheap and general. A model can write a working change from a plain description, so the brittle part of the 2004 factory is gone. What teams found next is that the bottleneck moved.

It moved to context, because an agent with no memory of last week's decision argues for last month's rejected design. It moved to review, because plausible output that cannot be traced takes longer to check than to write. And it moved to accountability, because nobody could say which agent did what, with what, approved by whom.

So the phrase came back with a new meaning. A software factory is now the system around the agents, made of the record they work from, the standards they follow, the permissions they run under, and the trail they leave.

Uber's engineering team has written about running one at scale, and several vendors have published their own definitions. They differ at the edges and agree on the center, which is that repeatable work goes to agents, judgment stays with people, and everything is recorded.

The order of the loop changed as well. a16z drew it as an inversion. The old loop ran idea, spec, design, build, ship, learn, and the new one runs idea, build, play, design, ship, learn, because a prototype is now cheaper than the meeting that used to scope it.

Building got cheap; knowing what to build did not. That moves the factory's weight from the spec that starts the work to the record that captures what the prototype taught, and to the person who decides what ships.

What a software factory needs

1. 01

   A shared record

   Requirements, decisions, tickets, code history and the conversations behind them, in one searchable place that persists between sessions. This is the raw material. Without it every run starts from nothing.

2. 02

   Standards written down

   How this team builds things: the starter kits, the patterns that hold under load, the questions to ask before writing anything. Agents follow written standards well and unwritten ones not at all.

3. 03

   Agents for the work that repeats

   Drafting a spec from a decision, writing the change and its tests, a first review, a security check, keeping the backlog in sync. Separate jobs with separate scopes rather than one assistant asked to do everything.

4. 04

   Permissions and review

   An agent reads and drafts on its own. A person decides what is ready to build, and every change is reviewed with its sources attached before it merges. What an agent may write to is set by people, not by whatever credentials happen to be in the environment.

5. 05

   A trail

   What was asked, what was read, what was done, who approved it and when it closed, recorded by the system rather than by somebody remembering to log it. The trail is what makes the factory auditable, and it is what lets the team ask why a year later.

How a software factory differs from a generator or a pipeline

It is not a code generator. Generation is the cheap step now, and a factory that is only a generator reproduces the 2004 failure with better output. It is not a CI/CD pipeline, though it contains one. A pipeline moves a change that already exists; a factory produces the change, with its reasoning attached.

And it is not a way to remove engineers. The teams that have made this work kept engineers in charge of architecture, scope, review and the merge, and gave the agents the repeatable middle.

Engineers own the judgment. Agents carry the repeatable work.

A worked example

TechFabric, the company that builds Fabric, ran into the problem before the agents existed. Every project depended on a few strong engineers, and hiring more of them raised the ceiling without removing it. So they wrote down what those engineers knew, as starter kits, components, the patterns that survive month six, and the questions to ask a client first. That took years and it was the whole ambition at the time.

When the models became good enough, the record was already there. Agents were given the repeatable jobs, with people deciding what was built and what merged, and every run recorded. Delivery work that took a team of ten now takes three, and the company runs its own delivery on the same system it sells. The full account, with the people involved quoted, is in the case study.

Everything that made a project go well lived in a few people's heads. Writing it down felt slow at the time. It was the only thing that ever actually scaled.

How to start

1. 01

   Write down what your strongest engineers know. Standards, starter kits, the decisions that keep coming up. This is slow and it is the step everything else depends on.

2. 02

   Connect the record. Put the documents, the tickets, the code and the conversations where one system can search them and cite them.

3. 03

   Give agents one repeatable job each, with a permission model. Start with drafting specs or first-pass review. Widen the scope only as the trail earns it.

Fabric is an open-source implementation of all five parts, free to use with your own model keys, hosted or self-hosted. It is one way to build a software factory. The parts above are what any way needs.