Suddenly everyone is building an AI software factory

tldr: The AI software factory is 2026's loudest category: a system where coding agents take tickets to verified pull requests with no human in the middle. The hype is real and citable, from Cursor conference talks to vendors naming themselves after the term. So is the gap underneath it: not one public benchmark measures whether any of these factories actually deliver.

The moment

A fifty-year-old term is having its third moment, and this time everyone showed up at once.

Cursor is on stage teaching it: Eric Zakariasson's talk "Building your own software factory" frames the shift as developers moving from writing lines to defining intent, constraints, and verification, then managing the production system that does the rest. Morning Brew's co-founder is explaining it to people who have never opened a terminal: Alex Lieberman's What the hell is a Software Factory? (1 June 2026) tells a business audience that "the humans move up a level, from doing the work to directing it." A defence contractor is riffing on lights-out manufacturing: BrainGu's Enter the Dark Software Factory (6 May 2026) describes "a pipeline where AI handles the path from requirement to pull request" and then spends most of its length on why you should not run one without governance.

The vendors have gone further than writing about the category. There are now funded companies carrying the term in their names and taglines, and more of them arrive each quarter. When companies start branding themselves after a category noun, the noun has become the market.

Here is what has not shown up yet: evidence. There is no public benchmark for ticket-to-merged-PR reliability, no cross-vendor comparison, no standard way to check any factory's claims against another's. The naming is outrunning the measuring, which is the definition of a hype cycle. That does not make the category fake. It makes it unpriced.

Why this term, and why now

"Software factory" has been reborn twice before, and each rebirth industrialised a layer the previous one could not touch.

The first era standardised the humans. Hitachi organised programmers on factory lines from 1969, and Michael Cusumano's Japan's Software Factories (1991) documented how far Hitachi, Toshiba, and NEC pushed standardised process and reuse. Microsoft revived the phrase in 2004 for model-driven product lines. The unit of automation was the method; people still wrote everything.

The second era automated the path to production. A 2010s software factory is a DevOps platform: golden pipelines, CI/CD, security scanning. The US Department of Defense still runs accredited software factories with names like Kessel Run and Platform One, which is why so much search traffic for the term carries government intent. Delivery became repeatable. Implementation stayed manual, billed by the engineer-hour.

The third era automates the implementation itself, and that is the one being hyped now. Agents write the code. Nothing in the first two eras attempted that, which is why a term from 1969 is suddenly on conference stages.

What an AI software factory actually is

Strip the branding and every shipping product in the category runs the same five-stage loop. Each stage below is documented by the vendors themselves, not projected.

• Intake. Work arrives as a ticket, spec, or logged bug from Linear, Jira, Slack, or a support queue, rather than as a prompt typed into an editor.

• Isolation. A sandbox spins up, clones the repositories, and is destroyed when the run ends.

• Implementation. A coding agent does the work inside that sandbox. Some factories run proprietary agents; some route to the agent you choose per task.

• Verification. The run executes the repository's own checks, retries on failure, reviews its own diff, and for UI work drives a real browser and records the session. This stage is the whole difference between a factory and an agent left alone overnight.

• The pull request. One PR per changed repository, with the diff, check results, and recording attached. A human reviews and merges.

The boundary against the tools you already use comes down to when a person is required. A coding assistant needs you typing. A coding agent needs you in the session, steering, which is the entire subject of our Codex and Claude Code comparison. A factory wants a person at exactly one point: review. That pattern now has a name, the background coding agent, and the useful definition rests on where the loop runs and who closes it, rather than on which model sits underneath.

Who actually ships one

Four products define the category as of 27 July 2026. Every claim below comes from the vendor's own site as of that date, and all of it is vendor-reported. No independent measurement of any row exists.

Disclosure: FactoryKit is ours. It was born at Bug0, whose open-source engine Passmark has grown into one of the fastest-growing Playwright AI libraries, used by more than 200 teams, and the founders built FactoryKit as the next step of that work: the same verification-first approach, pointed at unattended coding agents.

What the hype skips

Four gaps sit under the category's noise. They are also the four problems FactoryKit was built around, which is not a coincidence: the founders shipped verification tooling at Bug0 and Passmark before pointing it at coding agents.

Nobody can prove reliability, so every run has to prove itself. No vendor in this category publishes a first-attempt merge rate, ours included. FactoryKit's answer is to make each run carry its own evidence rather than asking for trust: it executes the repository's own checks with fix attempts, reviews its own diff, and for UI work drives a real browser and records the session. You are not asked to believe a benchmark that does not exist. You watch the recording attached to the PR.

Parallelism is the pitch and the bill. Ten sandboxes clearing tickets overnight is the demo. Ten sandboxes retrying failed checks at full token price is the invoice, because the models underneath charge for every attempt, successful or not. This is the discipline the team carried in from Passmark, an engine built on the premise that you cache what has already been verified instead of paying a model to rediscover it. Verification placed inside the run is a cost position as much as a quality one, because failure caught at the check stage is cheaper than failure caught by a human three days later.

Review is the bottleneck, and the fix is arriving pre-argued. Lieberman's line about humans moving up a level has a sharp edge he does not dwell on: a factory produces pull requests faster than senior engineers can responsibly read them. FactoryKit's browser QA stage runs on Passmark, so a UI change lands with the session recording and assertion results already attached, and the reviewer starts from evidence instead of from scratch. BrainGu's dark-factory piece makes the same point from the defence side: the lights can go out on implementation, never on ownership.

The security surface moved. An unattended agent with repository access raises one question above the rest: what can it leak? Sandbox isolation is table stakes. FactoryKit's position is that the agent should never hold a secret at all, so GitHub tokens and model keys stay outside the sandbox and a firewall injects them into outbound traffic, scoped per repository. A compromised or misbehaving agent has nothing to hand over. Whatever factory you evaluate, ask this question first; it separates products faster than any demo.

What to check before you buy one

Three questions, in order of how quickly they end sales calls.

1. What is your first-attempt merge rate on repositories like mine? Not a demo repo. If the answer is a benchmark that does not exist, you have learned the category's real maturity.

2. What does a failed run cost me? Retries bill full price. Get the retry policy and the per-run economics in writing.

3. Where do my secrets live during a run? If the answer involves credentials sitting inside the sandbox with the agent, keep asking.

FAQ

Is the AI software factory just hype?

The category is real and the market around it is ahead of its evidence. Products exist, enterprises are deploying them, and the architecture is consistent across vendors, which is usually the sign of something durable. What does not exist is any independent measurement of whether they deliver. Both things are true at once, which is what the middle of a hype cycle looks like from inside.

Should my team build a software factory or buy one?

Building means the Zakariasson path: making your codebase legible to agents, defining guardrails and verification, and wiring your own pipeline from coding agents you already pay for. It suits teams with strong platform engineering and unusual constraints. Buying gets you the sandbox, credential, and verification plumbing on day one, and makes sense the moment the build would take a quarter. Either way the review bottleneck is yours to solve; no vendor sells you out of it.

What does an AI software factory cost to run?

Two meters. The platform, where usage-based pricing without per-seat licensing is the emerging pattern. And the tokens underneath, which scale with parallelism and retries, so cost per finished task is the number to track rather than cost per run. A factory that needs three attempts per ticket costs triple its demo, and the rate cards driving that math change often enough that we maintain them on a live page.