Vercel shipped Foreman in mid-August. It splits the agent loop into four stations, each one an agent in its own sandbox, and the reviewer runs on a different model than the writer, so no agent gets to rubber-stamp its own work. It is the most careful piece of engineering in the category.
Vercel calls it a software factory. So does everyone else, about everything in this space.
The name is backwards, and the backwardness is not cosmetic. It is already shaping how teams buy these systems, what they measure once they have one, and who they blame when the output is wrong.
Everyone building one describes the same machine
The clearest definition I have seen came from @ctatedev on August 12: the software factory idea is that software changes should not come from ad-hoc conversations with an agent, they should move through a system of “sandboxed execution, bug reproduction, verification and review.”
Nothing in that definition touches speed or volume. Every noun in it is a checkpoint.
The same shape shows up everywhere the term appears. @Granite0x described Foreman’s design as splitting the loop specifically so that no single agent is “writing, reviewing and merging its own work, rubber-stamping its own bugs.” Guillermo Rauch, Vercel’s CEO, argues the substrate should be a monorepo holding all company context, design and marketing and sales and support included, so agents build on the same ground truth. @diptanu expects every company to run a “multi-player software factory” where teams own the architecture and engineers steer agents running the pipeline. @mfishbein has the solo-operator version, a personal factory that “turns ideas into working products while I sleep,” and even that one is mostly a description of a self-managing context system rather than a code generator.
This is no longer a metaphor people reach for casually. @dexhorthy is convening a dinner in San Francisco and screening attendees for being the “technical lead for internal ai software factory” at a company with at least 100 engineers. That is a job now. Factory AI, meanwhile, launched a partner network backed by a $100 million investment in partnerships, which is a company spending real money to own the word.
So the category has a definition, a labor market, and a vendor buying the naming rights. What it does not have is a name that matches the thing.
The word is sixty years old and never meant this
The term did not arrive with agents. Robert Bemer was writing about a software factory at General Electric in the late 1960s, and in 1969 Hitachi opened Hitachi Software Works, the first facility actually run and managed as one. Michael Cusumano documented the whole lineage in Japan’s Software Factories, with case studies of System Development Corporation, Hitachi, Toshiba, NEC, and Fujitsu, running from the mid-1950s through the late 1980s.
The problem those organizations were attacking was not typing speed. It was reuse and coordination. Programs were being written in isolation by large teams who kept rebuilding things that already existed somewhere else in the building. The factory was an answer to duplicated effort across hundreds of people, and the discipline it imposed was standardization so that work done once could be used again.
The military meaning is different again and equally unrelated to generation. Kessel Run was the Department of Defense’s first software factory, and Platform One now manages a set of them including Kessel Run, Kobayashi Maru, Space CAMP, and Unified Platform. What those organizations exist to remove is the accreditation bottleneck. Getting code into production in that environment was never limited by how fast anyone could write it. It was limited by the path from a working build to an authority to operate.
| Dimension | Hitachi, 1969 | DoD software factories | Agent pipelines, 2026 |
|---|---|---|---|
| What it standardized | Reusable components | The path to production | Review stations |
| The actual bottleneck | Duplicated effort across teams | Accreditation | Trusting generated output |
| What “faster” meant | Less rebuilding | Fewer approval cycles | Fewer bad merges |
| Where the value sat | A component used twice | An authority to operate | A change that survives review |
The three eras attacked three completely different constraints, and in none of them was the bottleneck a human typing too slowly. The 2026 pitch is usually delivered as though generation speed were the obvious thing to fix and agents finally fixed it.
A factory is a machine for making many of the same thing
A factory is a specific economic object. It exists to drive down the marginal cost of producing an additional identical unit. You build one when you need the ten-thousandth copy to be cheaper than the first, and the entire apparatus of tooling, standardization, and line work is in service of that curve.
Software already has a marginal replication cost of approximately zero. It has had one since the beginning. Copying the ten-thousandth instance of a working program is free and always was. @_coenen put the objection sharply: the whole point of factories is to make lots of the same thing, and software is already infinitely replicable, so what you actually want is a “software studio” that makes it easier to design, craft, maintain, evolve, and debug.
I think he is right about the diagnosis and wrong about the replacement. “Studio” imports a different bad idea, that this is craft work resistant to systematization, which is exactly what these pipelines disprove. But the diagnosis holds. Nobody building one of these systems is trying to produce many copies of the same program. They are trying to produce one correct change, repeatedly, under conditions where the thing generating the change cannot be trusted to evaluate it.
What they built is back-pressure
Foreman’s reviewer runs on a different model than the writer. That is not a throughput optimization. Running a second model over the output is strictly slower and strictly more expensive than not doing it. It exists because the alternative, an agent grading its own homework, produces confident garbage.
I wrote about this failure mode in the context of inherited AI codebases: an agent dropped into a repo it does not understand will rewrite the architecture, miss most of the surface area, and hand you a pull request that passes the tests it wrote for itself. The uncomfortable part is that those tests really do pass. Passing is not the same as being right, which is the same gap I picked at in conformance is not trustworthiness.
Every station in one of these pipelines is a place where work can be rejected. Sandboxed execution is a gate. Bug reproduction is a gate. Verification is a gate. A separate reviewer on a separate model is the most expensive gate of all. Addy Osmani makes the practical version of the point: humans stay in the loop for product intent, system design, and the quality bar, and the thing to watch for is “where automated back-pressure breaks.”
change
│
▼
┌──────────────────────┐
│ sandboxed execution │ ──── reject ────┐
└──────────────────────┘ │
│ │
▼ │
┌──────────────────────┐ │
│ bug reproduction │ ──── reject ────┤
└──────────────────────┘ │
│ │
▼ │
┌──────────────────────┐ │
│ verification │ ──── reject ────┤
└──────────────────────┘ │
│ │
▼ │
┌──────────────────────┐ │
│ review, model B │ ──── reject ────┤
└──────────────────────┘ │
│ ▼
▼ back to the writer
mergeEvery station is a place the change can die. The arrows on the right are the product.
Back-pressure is the right word and it is the opposite of what a factory does. A production line’s job is to keep material moving. This system’s job is to stop bad changes from moving. The value is concentrated entirely in the refusals.
The metaphor picks the metric
Call something a factory and you will measure it like a factory, which means measuring output. Pull requests opened. Issues closed. Agents running concurrently. Tokens burned. Every one of those numbers goes up when the system is working and also goes up when the system is producing plausible slop at high speed, and you cannot tell the two apart from the dashboard.
I have made this argument about AI spend before, and the trap is the same one wearing new clothes. The velocity chart was a polite fiction before agents arrived. Agents did not invent the fiction, they just made the line go up faster, which made the fiction look more like proof. Naming the whole apparatus after a throughput machine bakes that error into the org chart.
The honest metric for a gate is what it refused. How many changes did the reviewer reject, and were they right to. How often did something reach production that the pipeline should have caught. What is the rate of changes that pass every automated station and still get reverted by a human within a week. Those numbers are harder to collect and considerably less fun to put on a slide, and they are the only ones that tell you whether the machine works.
The jokes are measuring the same gap
The backlash on X is not really about agents. It is about the gap between the word and the thing, and it is funny precisely because everyone can feel the mismatch without naming it.
@charles_irl: “just one more harness bro. i promise just one more harness and we’ll go from slop cannon to software factory bro. it’s just a more powerful harness bro. please just one more.”
@forgebitz, more bluntly: “everybody wants to build a software factory. nobody wants to build good software.”
Both landed hard, which tells you the audience recognized something. Read them against @ctatedev’s definition and the tension is obvious. The people actually building these systems are describing careful, slow, gated machines. The people selling and hyping them are describing a slop cannon with better branding. Those are not the same product, and the shared name lets the second one borrow credibility from the first.
What to ask before you buy one
If someone is selling you a software factory, or you are about to staff one internally, the useful questions all point at the gates rather than the line.
What does it refuse to merge, and can you see the log of refusals? A system with no rejection rate is not a pipeline, it is a very expensive way to run one agent.
Does the reviewer run a different model than the writer, and if not, why not? Same model reviewing its own output shares the same blind spots, and the review step becomes theater.
Who is accountable when it merges something wrong? “The factory did it” is not an answer, and the absence of a name here is usually the tell that nobody has thought about it.
Where does back-pressure break? Every one of these systems has a station that is nominally a gate but in practice always passes. Find it before you depend on it.
What happens to the rejection rate under deadline pressure? Gates that get widened when the quarter is ending were never gates.
Call it a gate
The systems being built right now are good. Foreman’s architecture is genuinely thoughtful, the enterprise pipelines are solving a real coordination problem, and the practitioners building them are doing careful engineering rather than magic.
They are just not factories, and the people building them keep accidentally proving it every time they add another checkpoint. A factory that keeps adding inspection stations until inspection is most of the cost has stopped being a factory. It has become a quality gate that happens to have a generator bolted to the front.
That is a fine thing to build. It might be the most useful thing to build in 2026. It deserves a name that tells you where the value is, because the name you use is the number you will end up on a slide defending.
