What is a software factory?

A software factory is a system that takes a piece of work, such as a bug report, a feature request, or a migration, and carries it to a verified change in production with AI agents doing most of the execution. Many agents work at once, getting fed new work from a queue. Each change passes through checks it can't skip, and whatever happens in production feeds back into what the factory works on next. Engineers stay in the picture where they are needed. They move to the decisions that still need judgment, like what to build, how much risk to accept, and whether the result is right.

A software factory isn't a product you install, and it isn't one coding agent with access to CI. It's an architecture, and most of the work effort goes into the pipes between agents, not the agents themselves. The term spread quickly through 2026 as one engineering organization after another described its own version, and the definitions haven't quite settled yet. This page covers what the published versions share, where they differ, and where they break.

One agent is not a factory

The clearest way to see the difference is to build up from the smallest unit. Addy Osmani's July 2026 essay Software Factories, Light and Dark uses three levels. A loop is one agent doing one job: plan, act, observe, repeat until done. An agent harness wraps that loop in the walls it needs: a sandbox, tools, memory that survives between runs, and gates that decide what done means. A factory is many harnessed loops running at once, fed by a queue of work and drained through a review gate into production, with people owning the whole thing from above.

Each level fixes a problem the one below can't. A bare loop ends when its task ends, and the next run starts cold. An agent harness makes one loop safe and repeatable, which is roughly what a background agent running in an ephemeral environment gives you. But a harness only improves itself. Chaining a second agent onto the first, an implementation agent handing off to a review agent, doesn't make the two learn from each other.

How many stages are in a software factory? Nobody agrees yet

There's no standard number. Published versions run from four stages to nine, and most of the difference comes from how finely each one slices the same flow. Four stages show up in nearly every version:

1. Intake. Work arrives from an issue, an alert, a schedule, or a spec, and gets triaged.
2. Build. An agent implements the change in an isolated environment.
3. Verify. Tests, review agents, and people check the change.
4. Ship. The change merges and deploys.

Most versions add a fifth, feedback, where production monitoring and review outcomes flow back into intake. That stage is what separates a factory from a pipeline that happens to use agents.

If that list looks familiar, it should. It's the software development lifecycle: plan, build, test, release, and operate, the same stages teams have drawn on whiteboards for decades. A factory doesn't invent new stages. It changes who works each one and how fast work moves between them. Agents take over building and much of verifying, people concentrate on intake and the final call, and handoffs that used to wait on a sprint planning meeting or a review queue happen in minutes. That speed is why the feedback stage matters so much: a loop that turns in hours repeats its mistakes in hours too.

Past that core, each setup adds stages around the part it trusts least:

• Nine stages, when verification is the worry. One published version splits checking into separate steps for code review, automated verification, human review, and CI. It also adds an optional specification step after triage and a monitoring step that opens new issues.
• Five stages, when learning is the point. Plan, build, review, ship, and learn, with bug reports, customer feedback, and production alerts feeding the first stage.
• Four stages, when the specification is the point. Requirements become blueprints, blueprints become work orders that agents execute, and feedback flows back into the requirements. Everything after the work order counts as one step, because the hard thinking happened before any agent started.

None of these counts is wrong. A more useful number than the total is how many stages can stop a change, because those are the ones doing the factory's real work.

Who presses start?

Intake, the first stage in every version, is really a decision about what gets to start a new agent session. Much of a factory's autonomy lives there, more than in the work any single session does.

Without a factory, every session starts because a person opens it and points it at a task. That holds even when everything afterward runs unattended. A factory removes that one step. Sessions start on their own, set off by a trigger:

• An issue is opened or labelled. A ticket tagged ready-for-agent gets a session that opens a pull request without anyone assigning it.
• A schedule fires. Recurring maintenance nobody remembers to run, such as one lint rule fixed a night, gets done instead of piling up.
• CI fails or a monitor alerts. A broken build gets a session that bisects to the bad commit and proposes a fix the moment it breaks, not whenever someone next checks a dashboard.
• Another session finishes. A pull request one agent opens triggers a review session, and the review's comments trigger a session to address them.

Triage itself can be an agent. A common setup sorts every incoming issue into one of a few states: ready to implement, needs a spec first, needs more information from the reporter, or should wait. Only the first state starts an implementation session automatically.

Most of the background agents covered on this site still start from a person. Ramp's Inspect, Shopify's River, and Uber's Minion all begin when someone types a request into Slack, a CLI, or a ticket. Stripe has crossed the line in one narrow place: CI starts a Minion run on its own when it detects a flaky test. That's the right way to start. One scheduled job or one CI trigger, opening one kind of reviewable pull request, already qualifies. Watching how those small, similar changes get reviewed shows how far the trigger can be trusted before you wire up a second one.

Each trigger raises the stakes downstream. A session a person starts gets at least a moment of judgment about whether now is the right time. A triggered session gets none, so the gates and spend limits on the other end have to catch a bad run entirely on their own. People don't disappear here; they move earlier. They write and label the issues, set the schedules, and decide which alerts deserve an agent. Deciding which checkpoints stay human is the real design question behind any factory.

What holds a software factory together? Six layers

The maturity scale tracks the lifecycle as five activities, code generation, testing, review, documentation, and deployment, because companies hand them to agents at different speeds. The parts that connect them are less visible and take most of the engineering.

Context. An agent is only as good as what it can find out about the codebase and the task. OpenAI keeps documentation inside the source tree so agents can find it without a separate lookup, and context kept next to the code stays current in a way a wiki doesn't. The shared agent context pattern covers how companies version it.

Isolated execution. Every run needs its own environment, so a bad attempt doesn't touch anything real before a human looks at it. Every company covered here that runs agents at volume treats this as the minimum. See ephemeral environments.

Access. Once agents need ticketing, feature flags, and the deploy pipeline, wiring each connection by hand stops scaling. An MCP gateway lets every internal system register once and every agent connect once, and it becomes the one place to enforce what each agent may call. The identity layer decides whose permissions an agent acts with.

Gates that route by risk. A gate that treats every change the same either blocks too much or catches too little. OpenAI sorts changes by risk and gives low-risk ones an easier path. Shopify's security scanner throws out any finding that doesn't come with a generated test that actually exploits the issue. GitHub's rule is plainer: no agent approves its own pull request. The quality gate and guardrail layer pages go further.

Cost. A factory multiplies token spend along with everything else. StrongDM's three-person AI team, profiled by Simon Willison, suggested a benchmark of at least $1,000 in tokens per engineer per day. Spend control caps what any run can burn, and a model router sends routine steps to cheaper models.

Evidence. A factory that can't show its work can't be trusted at volume. OpenAI's agents build a monitoring dashboard for each change they ship. Zalando mines its own incident postmortems for the rules its review pipeline enforces.

What 1,300 pull requests a week looks like

The best evidence for what a factory does comes from companies that describe their own.

OpenAI is the most complete public account. Gergely Orosz's Inside OpenAI's agentic software factory (September 2026) traces work from a person stating an outcome, through Codex gathering context and implementing, to specialist agents reviewing from different angles, and an agent deploying and watching the result. Separate agents run alongside: Perf Factory finds and fixes performance regressions, and Sevbot handles incidents. Use of Codex by non-engineering teams went from near zero to 90% in four months, and load on some internal systems rose about 10x in six. Engineers, in one leader's words, are becoming more like product managers than systems engineers.

Stripe's Minions passed 1,300 merged pull requests a week in February 2026, up from 1,000 shortly before. None of those changes contain human-written code, and every one is reviewed by a human.

Spotify's background agent, Honk, built its early record on code migrations, with time savings of 60 to 90% against writing the changes by hand. By March 2026 it was merging about 1,000 pull requests every ten days.

Amplitude built a factory that doesn't start with code at all. Its system, Wave, runs a sense, decide, act, and learn loop over product analytics, session replays, and experiment results to decide what to build, then routes each spec to a coding agent, a person, or an automated experiment depending on how confident it is. Its ship rate sits around 11%, against a 50% "would ship this" rate from its own judging step. That gap between what the factory proposes and what it's trusted to ship is the most honest number on this page.

Lights on or lights off

Every factory sits somewhere on a spectrum Osmani calls light and dark. A light factory keeps people at the design and architecture decisions and at final review. A dark factory, the term borrowed from manufacturing plants that run without lights because nobody works in them, ships on automated checks alone.

StrongDM runs close to fully dark. Its team's rules are that humans don't write the code and don't review it either. To make that safe, they keep test scenarios stored apart from the code, like a holdout set in machine learning, so the agent can't tune itself to pass them. And they run agents against behavioral clones of Okta, Jira, Slack, and Google Docs instead of the real services.

The objection is that agents writing both the code and the tests share the same blind spots. Willison asks how you prove the software works at all. Eran Kahana at Stanford Law asks who's accountable when nobody has read the code that failed. Osmani adds a slower cost he calls comprehension debt: after months of fully automated work, nobody on the team understands the system well enough to debug it.

Osmani's rule for where to sit on the spectrum:

Back pressure is the rule that you can only hand a loop as much autonomy as you can cheaply and reliably verify, and not one inch more.

Addy Osmani, Software Factories, Light and Dark

That makes autonomy a property of each kind of change, not of the factory as a whole. A company can run a dark path for dependency bumps and keep a light one for anything touching payments. The maturity scale tracks exactly that unevenness.

The bottleneck moved everywhere else

Every factory running at real volume hits the same wall, and it isn't the quality of the agents. Writing code got cheap, so the constraint moved to every step around it that was built for human pace. Reviewers face more pull requests than they can read. CI queues and internal services absorb load they were never sized for: at OpenAI, some systems took about 10x more in six months. And some steps sit outside the company entirely. OpenAI's mobile teams can produce a change in minutes, then wait days for app store review.

PostHog published one of the more candid inside views in its August 2026 newsletter. Agents write about 70% of its pull requests, and humans still skim at least 80% of those. Fixes are now its largest commit type, at 40%. The newsletter cites Dex Horthy's point that passing tests carries no penalty for eroding a codebase's maintainability, so a factory keeps optimizing for the thing it can see.

The independent research is mixed. Google's 2025 DORA report found 90% of respondents using AI at work and described AI as an amplifier: it makes strong teams stronger and struggling teams worse. METR's 2025 randomized trial found experienced developers took 19% longer with AI while believing they were 20% faster. Its 2026 follow-up pointed toward a speedup, but METR called the data unreliable, partly because many developers refused to work without AI at all.

Nick Sawinyh's August 2026 critique, Your Software Factory Is Not a Factory, argues the metaphor itself misleads. A factory sounds like a throughput machine, so teams measure pull requests and tokens. What these systems really do is reject bad changes at several checkpoints, so the useful metric is what the gates correctly stopped.

How do you measure a software factory?

Most published numbers measure output, like Ramp's three in four merged pull requests or Stripe's 1,300 a week. They show a factory is running, not whether it's working.

The usual fallback, DORA's four keys, no longer fits. Lead time, deployment frequency, change failure rate, and time to restore were designed when writing code was the slow, expensive part, and they start the clock after a change already exists. In a factory, writing code is nearly free, and the number of changes depends on how many agents you run. What matters is how much of that output survives, and what it cost to get there. These measures capture that:

• Cost per accepted PR. Everything spent to get changes merged, including tokens, compute, and reviewer time, divided by the number of pull requests that merged. It rises when agents flood review with attempts that never land.
• Acceptance rate. Agent pull requests merged, divided by agent pull requests opened. Atlassian publishes 59%, which means it also publishes the 41% that didn't make it.
• Review minutes per accepted PR. Human time spent reviewing for each change that merges. If output doubles and this doesn't fall, review is becoming the factory's most expensive stage.
• Rework rate. The share of merged agent changes that get fixed or reverted within a set window, such as 30 days. At PostHog, fixes are already the largest commit type, at 40%.
• Touchless rate. The share of merged changes a person approved without editing. It's the closest thing to a direct measure of autonomy.
• Escape rate. The share of changes that passed every gate and still caused an incident or a rollback. It measures the gates themselves, which is where Sawinyh argues a factory's real work happens.

Track each one per trigger and per kind of change, not only overall. A factory can safely run dark on dependency bumps while still needing people on anything that touches payments, and a single blended number hides that.

A factory, or just a few agents?

Six questions, closer to what to ask than what to buy:

1. Does anything persist between agent runs, such as shared memory, an updated standard, or a triage rule, or does every run start cold?
2. Is there at least one checkpoint an agent cannot bypass, such as a merge gate or a required sign-off for a risk tier, rather than a policy that relies on the agent behaving?
3. Could you list every agent running in your organization today and exactly what each one is allowed to touch?
4. If agent-generated changes tripled next month, do you know which system breaks first?
5. Do you know your cost per accepted PR, and is it falling?
6. Are you measuring whether the pipeline is getting better over time, or only whether the last run looked fine?

A "no" to most of these means agents are in the loop, but the factory around them isn't built yet. That's a normal place to be. It's just a different problem from choosing a model.

Where to go next

• The maturity scale: the five activities a factory covers, and how a company moves up on each.
• The quality gate: how companies decide what an agent's change needs before it merges.
• The MCP gateway: the access layer most factories end up building.
• All company reports: companies at every stage of building one, sourced and cited.