The software-factory pattern
How to measure a software factory, what teams running one report, and where to start reading, for engineering leaders weighing the model.
Written by
-
Benedikt Stemmildt Founder & Co-CEO
Updated:
Software Factories 5
Our position. We tell teams not to build the features but the factory that builds them: the human builds the factory, not the software (Dark factory or bullshit factory (opens in a new tab)). An agent that only builds is half a factory, and the other half is the validator (Autonomous agent verification (opens in a new tab)).
The factory model essay gives the shape: fleets of agents, each with a task, tools, context and a feedback loop, run in parallel while the human refines specs and reviews outputs (The Factory Model (opens in a new tab)). Taken seriously, the model puts the money into quality control, precise inputs and reliable environments.

Figure 1. Everything before the review gate is generation and the gate is verification, so the gate bounds what the factory ships. A dark factory takes the human off the gate; a lit one keeps a human there and adds one upstream. Diagram from Software Factories, Light and Dark (opens in a new tab), 22 July 2026.
How do you measure a software factory?
A factory is measured by the share of changes it ships on its own and what each one costs. One framing defines factory efficiency as shipped product over inference cost plus human time, and counts every fallback to an interactive agent as a failure to learn from (We Are Now Factory Engineers, Not Product Engineers (opens in a new tab)). Software production then appears as cost of goods sold rather than R&D, so every dollar of automation has to earn a return. The detail sits in Roles and economics.
What do running factories report?
Reported factories reach high autonomous throughput where specifications, tests and environments were strong before the agents arrived. OpenAI’s Codex team shipped an internal product with no manually written lines, and Ona’s Memo experiment merged 375 pull requests in ten days at an 87 percent autonomous rate (Harness Engineering (opens in a new tab); Ona: We Built a Software Factory in 10 Days (opens in a new tab)). Most of these numbers come from vendors or unusually mature teams. One practitioner’s lights-off run held until an issue required understanding code nobody had been reading (Harness engineering is not enough: Why software factories fail (opens in a new tab)). A long-horizon benchmark measures agent code growing more eroded as agents keep extending it (SlopCodeBench (opens in a new tab)). The cases and their limits sit in Production evidence.
Start here
- Roles and economics: How the factory model changes engineering roles, success measures, and the economics of software production.
- Work and orchestration: How factories represent work, coordinate agents, place deterministic gates, and improve their own harnesses.
- Production evidence: Reported factory deployments, their measured outcomes, their limits, and the vendor claims that require caution.
Related
- Roles and economics: how the factory changes the engineer’s job and the budget line.
- Production evidence: the reported deployments and where they failed.
- Creator and verifier roles: how to build the validator half of the factory.
- Software Factories and Harness Engineering: the harness the pattern runs inside.
- Inference economics and infrastructure: the inference cost that bounds factory output.
Resources
Articles
- Harness Engineering (opens in a new tab) - OpenAI article on its Codex team shipping an internal product with no manually written lines by investing in the agent harness.
- Ona: We Built a Software Factory in 10 Days (opens in a new tab) - Ona’s vendor account of its Memo experiment, which merged 375 pull requests in ten days at an 87 percent autonomous rate.
- Software Factories, Light and Dark (opens in a new tab) - Newsletter essay contrasting dark factories that take the human off the review gate with lit ones, and the source of this page’s diagram.
- The Factory Model (opens in a new tab) - Essay framing the engineer’s job as building the factory: parallel agent fleets, each with a task, tools, context and a feedback loop.
- We Are Now Factory Engineers, Not Product Engineers (opens in a new tab) - LinkedIn article defining factory efficiency as shipped product over inference plus human cost, and moving software production into cost of goods sold.
Papers and reports
- SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks (opens in a new tab) - arXiv benchmark measuring how agent-written code erodes as agents keep extending it across long iterative tasks.
Posts
- Autonomous agent verification (opens in a new tab) - LinkedIn post arguing that an agent which only builds is half a factory, and that the validator is the other half.
- Dark factory or bullshit factory (opens in a new tab) - LinkedIn post telling teams to build the factory that builds the features rather than the features themselves.
Talks and videos
- Why Software Factories Fail (opens in a new tab) - AI Engineer talk on a lights-off factory run that held until an issue required understanding code nobody had been reading.
In this section
- Production evidence
Reported software factories reach high autonomous throughput where specifications, tests and environments were strong before the agents arrived. Most numbers are self-reports from vendors or frontier labs, and cost, review capacity and long-term maintainability remain the binding limits.
- Roles and economics
In a software factory the engineer builds the system that builds the product, and success is the share of changes shipped automatically at a known cost. That moves software production from an R&D expense to cost of goods sold, where every dollar of tokens faces a return test.
- Work and orchestration
How factories represent work, coordinate agents, place deterministic gates, and improve their own harnesses.