Stop building software factories. Build a product factory.

Last week Cole Murray open-sourced his software factory and wrote one line that stuck with me: "you are not building a software factory, you're building the way your company works together." Rob Witoff replied that if your factory is just an engineering project, you're not thinking big enough. And then: "I do prefer 'Product Factory' though. The end result is better products, faster."

I've been chewing on that for a week. I think Rob is right, and I think the rename matters more than it sounds.

Everyone is publishing factory numbers

If you follow engineering blogs, September 2026 has been factory month. Uber says more than 70% of pull requests are now attributed to agents. Ramp went from 30% to 75% of merged PRs written by its in-house agent since January. Vercel's AI SDK factory authors a quarter to a third of merged PRs and closes most incoming issues. Cursor launched Projects, where you talk to a coordinator agent that delegates to thousands of subagents and never writes code itself.

The pattern is the same everywhere. Ticket in, specialised agents on the line, PR out. Igor Ostrovsky's state-of-the-field essay puts it neatly: a factory starts work from events, not prompts, and coordinates agents through structured workflows while humans approve the key decisions.

Mitchell Hashimoto said it back in April: "The factory of today is agentic. You can argue that 99% of the stuff coming out of these factories is total crap, but you can't argue the sheer quantity of stuff coming out."

So the factory is real. The question is what it's for.

The bottleneck moved, and it didn't move to review

Every factory post ends up at the same problem. Generation scales with your token budget. Review capacity doesn't. Vercel: "No maintainer, however good, can close that gap by working harder, and because generating code is cheap, it will only grow." Faros AI's telemetry across 22,000 developers shows high-AI teams merge far more PRs, but bugs per developer rose 54% and incidents per PR more than tripled.

The engineering answer is more gates. Deterministic checks first, model judges second, humans last. That's necessary. But I don't think it's the real bottleneck.

Noah Breyer wrote the sharpest thing I've read on this: "the most insidious failure mode in agentic engineering isn't buggy code. It's agents building fundamentally misaligned features, products, and systems." His metaphor: this is closer to Andy Warhol's Factory than Ford's. Both are about throughput, but Warhol was obsessed with every piece aligning with one creative vision.

PostHog found the same thing from the inside. Their factory experiments kept failing because the designs separated planning from implementation, which starved the agents of exactly the product and production context a human engineer carries in their head.

That's why "software factory" is the wrong name. Software is the output. The thing you're actually manufacturing is product decisions, at a rate no product team has ever had to make them.

What a product factory actually is

I'm a product manager with no dev background. I've built things with agents for a year now, and I've evaluated agent orchestration setups for clients. From that seat, a product factory has four parts, and only one of them is about code.

1. Intent and spec are the interface. Anthropic's AI-native SDLC playbook has product owners approve an intent.md and a spec.md before any agent touches a plan. Their line: "Code is no longer the bottleneck. The human-speed steps around it are." That's a product artifact, not an engineering one. If you can't write down what you want and why, the factory will build something else, fast.

2. Every mistake becomes a rule. Joel Hooks stopped reading code in May 2025 and runs a 4,000-customer support inbox on autopilot. His whole talk fits in three phrases: own your tools, every mistake becomes a rule, protect your attention. The rule shouldn't live in a prompt. It should be a test, a lint, a hook that fails loudly. shadcn shipped an agent-first linter this week where a broken rule explains what's wrong and how to fix it. That's the factory learning.

3. Humans own the outer loop. Peter Steinberger's slide at the AI Engineer World's Fair said it: "the future isn't 20 terminals, it's better loops." The agent runs the inner loop, executing. You run the outer loop, setting direction, judging output, improving the rules. For a PM that outer loop is literally the job description. Deciding what matters. Making trade-offs. Saying no.

4. Measure product outcomes, not agent activity. PR counts are vanity. Matt Pocock has the cheapest factory metric I know: instead of running one agent on a task, run two, let a human or an agent pick the better one, and tally the results at the end of the week. Faros puts it more formally: a factory's performance is how well it "converts AI activity into reliable, verified software outcomes." Outcomes. Not tokens.

Earlier this year I researched an orchestrator that pulls tickets from Linear and spawns a coding agent per ticket, for a public-sector client. The tech was impressive. The advice I ended up giving was: use Linear as context, not as orchestrator, and don't let any agent run unattended yet. Not because the agents couldn't code. Because nobody had written down what "done" meant well enough for a machine to check it. That's not an engineering gap. That's a product gap.

The honest part

The dark factory, where nothing is written or reviewed by a human, mostly doesn't work yet. Armin Ronacher let GPT-6 Astra run its own factory for 35 hours and $1,200 to add virtual threads to CPython. It produced 79 commits and 75,000 lines of unreadable, token-golfed code, and nothing usable. Dex Horthy ran a lights-off factory for four months last year and watched the codebase degrade by month three. LaunchDarkly's engineers, after rewriting their scariest 66,000-line frontend with agents, concluded: "The dark factory is a trap."

And the 70% numbers deserve a squint. "Attributed to agents" usually means a human still steered, reviewed, and merged. Uber's own post says agents escalate to humans "only when needed," which is doing a lot of work in that sentence.

So no, you can't fire the humans. But you can change which humans.

Why this is a PM story

Boris Cherny, who leads Claude Code, has said the software engineer title will probably dissolve into "builder or product manager." LaunchDarkly's CTO describes his engineers as strategic product managers directing agents. Greg Isenberg's version of the new org chart is a thin layer of humans doing strategy and judgment, with a wide layer of agents underneath.

Read those again. Every one of them describes the product owner's job, pointed at agents instead of a scrum team.

A software factory is an engineering project. A product factory is a way of working, and the scarce input is judgment about what to build, written down clearly enough that a machine can act on it and a rule can check it. If your company is standing up a factory right now, the most valuable person in the room might not be the one who knows the harness best. It might be the one who can say, precisely, what a good product looks like.

Call it what it is. Build a product factory.