A software factory is a repeatable system for turning defined work into production software through standardized inputs, shared tooling, automated quality gates, and measurable output. In an AI software factory, coding agents perform much of the planning, implementation, testing, and review while humans define intent, risk, and acceptance criteria.
Stripe merges more than 1,300 pull requests every week that contain zero lines of human-written code. A three-person team at StrongDM builds software that no engineer writes or reviews. At Uber, an internal system called Minion now opens 11% of pull requests across the company. None of these are demos. They are running in production right now, and the people operating them have stopped calling what they do "coding."
They call it running a software factory.
That phrase now means something specific: a system that takes a signal, spec, or issue in one end and produces deployed, verified software out the other, with fleets of AI coding agents doing the work inside a feedback loop.
I build these systems for a living. I'm the creator of OpenInspect, an open-source background-agent platform, and I've deployed this pattern across client engineering teams. And the job itself is changing: from writing code to writing the systems that write code.
In this guide
- What is a software factory?
- The software factory model
- How a software factory works
- Software factory examples
- The operating model
- How to build a software factory
What is a software factory?
A software factory is an approach to software development that treats building software like a production process: standardized inputs, a defined assembly path, automated quality control, and repeatable output, rather than each feature being hand-crafted from scratch.
The term predates AI. Earlier software factories standardized templates, reusable components, development environments, and delivery pipelines while people still performed most of the work. What's new with AI is who works the line.
An AI (or agentic) software factory is a system where autonomous coding agents do much of the production work. You give it a specification, sometimes as small as a labeled issue, and agents plan the change, write the code, generate tests, run them in an isolated environment, open a pull request, and respond to validation feedback. Humans set the direction, define what "correct" means, and review according to risk. They are not in every keystroke.
The clearest one-line version comes from Zacharias Malguitou's public software-factory experiment: you move "from in the loop to on the loop." Instead of producing each change yourself, you steer the system that produces them.
The software factory model
A software factory is not defined by one model, vendor, or coding agent. It is defined by the operating model around the work:
| Property | What it requires |
|---|---|
| Standardized inputs | Every task has scope, context, acceptance criteria, an owner, and a target environment |
| Shared tooling | Humans and agents use the same repositories, environments, checks, and delivery controls |
| Automated quality gates | Tests, evals, security checks, and policy checks produce feedback before release |
| Measurable output | The team tracks cycle time, accepted-output yield, escaped defects, review load, and cost per accepted change |
| Replayability | A shipped change can be reconstructed from its inputs, model and prompt versions, tool calls, checks, and approvals |
The smallest useful model is "spec in, verified change out." A complete factory is a closed production loop:
Signal → intake → context → plan → build → test and review → deploy → monitor → learn
Production incidents, customer feedback, and failed runs become new inputs. That is the difference between a collection of coding agents and a factory that improves its own process.
Software factory vs. AI factory vs. platform engineering
Three terms get tangled here, but they are not the same thing.
| Term | What it means | Who owns the concept |
|---|---|---|
| Software factory (AI sense) | A system where AI agents produce software: spec in, merged PR out | Stripe, StrongDM, Factory.ai, Cursor, Ramp |
| AI factory | Physical GPU/data-center infrastructure that "manufactures intelligence" (produces tokens) | NVIDIA |
| Platform engineering | Internal developer platforms and paved roads that make humans more productive | The platform/DevOps community |
The short version: NVIDIA's AI factory is the power plant that makes the tokens; a software factory spends them to make software.
How a software factory actually works
Under the branding, the working factories converge on a small number of ideas. Here are the ones that matter.
StrongDM's AI software factory: seed, validation harness, feedback
The cleanest formulation I've seen comes from StrongDM's AI team, which reduced its philosophy to one pipeline: a seed feeds a validation harness, whose feedback loop runs until the output holds up. Tokens are the fuel.
StrongDM makes one claim here that many teams find hard to swallow. It argues AI-generated code should be treated as opaque, like the weights of an ML model: correctness is inferred from externally observable behavior rather than from reading the code. On that view, the validation harness is your only real correctness signal. Not everyone agrees, and that disagreement is a fault line I'll come back to.
The five levels of coding automation
The most useful map of the territory is Dan Shapiro's "five levels of AI coding automation", modeled deliberately on the levels of self-driving cars. Compressed:
Two things about this framework earn their keep. First, the plateau trap: every level from 2 on feels like the destination. The jump to Level 3 feels like a regression: you trade the dopamine of writing code for the grind of reviewing diffs, so most people won't pay the cost, and never reach the levels where the leverage actually lives.
Second, the endpoint has a name. Level 5 is the "dark factory," after Fanuc's lights-out plants where robots build robots with no humans on the floor: requirements in, product out, lights off. It's a vivid image, but today only a handful of sub-five-person teams operate there. The real value is at Levels 3 and 4.
The manufacturing analogy, done properly
The factory metaphor is worth taking further than "assembly line." The mapping is tight, and it tells you where to look when your factory underperforms.
| Manufacturing concept | Software factory equivalent |
|---|---|
| Raw material | Specs, issues, seeds |
| Machines / workers | Coding agents |
| Assembly line | The SDLC pipeline: plan, build, test, review, deploy |
| Quality control gate | The validation harness (tests, evals, scenario checks) |
| Defect / yield rate | PR pass rate; share of agent PRs that are production-valid |
| Work-in-progress limits | How many agent sessions you run concurrently |
| Throughput | Merged PRs per unit time |
| Bottleneck | Almost always verification, not generation |
| Lights-out automation | The "dark factory": no human in the loop |
The row that matters most is the bottleneck. In a physical factory, once your machines are fast, throughput is gated by the slowest station, usually inspection. In a software factory it's identical: generation is cheap and getting cheaper, so your ceiling is set by how fast and how trustworthily you can verify output. Teams that treat the agent as the constraint optimize the wrong station. The constraint is the quality gate.
Software factory examples in production
The real numbers are scattered across engineering posts, conference talks, and vendor case studies. Here they are with direct links and evidence labels so you can judge how far along this actually is.
| Team | What they report | Evidence |
|---|---|---|
| Stripe ("Minions") | 1,300+ PRs merged per week with zero human-written code; PRs remain human-reviewed | Stripe engineering, company-reported |
| Cursor | More than 40% of internal PRs now come from cloud agents | Cursor research, company-reported |
| Ramp ("Inspect") | More than half of merged frontend and backend PRs are started by Inspect | Modal case study, customer-reported |
| Uber ("Minion") | 11% of pull requests are opened by agents | Background Agents Summit recap, company presentation |
| Harvey ("Spectre") | Durable agent runs execute in isolated sandboxes and return reviewable branches and PRs | Harvey engineering, company-reported |
| StrongDM | 3-person AI team; a stated target of at least $1,000/day in tokens per engineer; digital twins for scenario testing | StrongDM AI, company-reported |
| Ona (public build) | 375 PRs in 10 days; 67,000+ lines; 1,067 tests; 87% of merged work without human involvement; median issue-to-close 38 minutes | Ona experiment, company-reported |
These figures are not directly comparable. Teams measure different denominators, task types, repositories, and levels of human intervention. Most are self-reported by the company operating the system, not independently audited. They are evidence that software factories exist in production, not proof that every agent-authored change is valuable.
StrongDM software factory example
StrongDM is the clearest public example of the "dark factory" position. Its three-person AI team says humans neither write nor review the generated code. Instead, agents converge against externally stored scenarios, including a Digital Twin Universe that reproduces services such as Okta, Jira, Slack, Google Drive, and Google Docs. The important lesson is not "remove review immediately." It is that autonomy depends on a validation environment rich enough to replace the signals review used to provide.
Ona software factory example
Ona built a Notion-like application in public over ten days with one constraint: no human-written production code. Its factory connected specialized agents across planning, implementation, pull-request review, deployment, post-merge verification, incident response, and iteration. The result—375 merged PRs—is less useful than the operational lesson: detailed specifications produced clean runs, while a five-line feature spec produced working software with predictable UX gaps. The factory amplified the quality of its input.
One counterweight belongs next to the throughput numbers. GitClear's analysis of 211 million changed lines reports increased duplicate blocks and short-term churn as AI-assisted code grows. The study is observational rather than proof that AI caused every change, but it is a reminder that a factory optimizing only for PR volume can manufacture downstream maintenance work.
The operating model: how to actually run one
The operating model is where most of the real work lives: the difference between a software factory that ships and a pile of agents generating plausible-looking noise.
Reproducible environments come first
The first thing a background-agent system does is expose every gap in your process. When standing up the app is a tribal-knowledge ritual, agents can't run it, and neither can anyone who isn't already an expert. Stripe's framing is that dev environments have to be "cattle, not pets": identical, disposable, spun up per session, never hand-tuned. This is where your choice of sandbox provider matters: every session needs its own isolated, fast-booting environment, and at fleet scale that economics is not trivial.
Keep the secrets out of the sandbox
The usual debate ("should the agent run inside our environment or outside it?") misses the more important question: where do the secrets go? An agent that can be prompt-injected is an agent that will eventually try to exfiltrate whatever credentials it can reach. In OpenInspect I keep tokens (the GitHub token, the Slack token) in the control plane, outside the sandbox the agent lives in; the agent calls a tool that uses the credential on its behalf, but never sees it. That single design choice turns a catastrophic prompt-injection into a contained one. (If you think this is theoretical: I once used an AI agent's own memory to achieve remote code execution. The attack surface is real.)
Give the agent back-pressure
Left alone, an agent will confidently produce code that doesn't meet your standards and hand it to you at the pull request, which is the most expensive possible place to catch it. The fix is back-pressure: build the environment so the agent sees and corrects its own failures before the PR. Concretely, that means linters, commit hooks, type checks, and custom static-analysis rules that fail fast inside the sandbox. One client of mine had a recurring problem with agents writing raw SQL; the fix was a Semgrep rule that fails the pre-commit hook the moment raw SQL appears, so the agent gets immediate, machine-generated feedback and rewrites it, with no human involved. Your evaluation harness is the factory's inspection station, and building it to be reliable is most of the actual engineering.
Spec quality is the multiplier
The lesson every practitioner repeats, captured in Ona's public experiment, is that spec quality is the control surface. The factory faithfully amplifies whatever you feed it. A sharp spec with clear acceptance criteria produces a clean PR; a vague one produces a confident, plausible, wrong PR very quickly. Most of the skill in operating a factory is front-loaded into specification and context, exactly the systems-design work that used to happen implicitly in an engineer's head and now has to be made explicit for a machine.
Progressive autonomy and a tiered review policy
You do not flip a factory to "fully autonomous" on day one. You climb a ladder: start with small, well-scoped bugs; use the results to build up skills and harden the environment; then delegate larger tasks; then run several in parallel. Tier the review policy by risk and evidence. Stripe's Minions remain human-reviewed even after producing more than 1,300 merged PRs per week. Match the level of autonomy to the blast radius of the change.
Let anyone contribute, but don't mandate it
The most durable systems open the factory to non-engineers (designers, PMs, support, sometimes the CEO), because once a session lives in a reproducible cloud sandbox, "set up the dev environment" is no longer the barrier to entry. But adoption can't be forced. My consistent experience, echoed by every team I've compared notes with: mandating AI usage doesn't work. Make the system clearly, obviously better than the alternative and let people choose it. The pull is more durable than the push.
If your team is already using Cursor or Claude Code and starting to ask how to scale beyond individual engineers, this operating model is exactly what I help teams install: the environments, the secrets design, the validation loop, and the review policy, not just "turn on an agent."
The unsolved problem: verification, not generation
Here's the fault line I said I'd come back to. It's still an open question.
StrongDM's position is that AI code is opaque and should be validated purely through observable behavior: no human reading the code, no human review in the merge path at all. Their dark-factory build takes this literally: code is neither written nor reviewed by humans, and quality is enforced entirely by a "digital twin universe" that clones the behavior of external dependencies and runs thousands of scenarios per hour against holdout sets.
And yet. Stripe, whose factory is one of the largest in production, still human-reviews Minion-generated PRs. Harvey designed Spectre to return reviewable artifacts, including summaries, diffs, branches, and pull requests. These are not laggards; they are advanced operators that have kept a reviewer in the loop.
So the field genuinely disagrees on a core design question: is code review outside the validation set, automated inside it, or still a human requirement? My own read, from the deployments I've run: the "no review" position is correct about the destination and dangerous as a starting point. Behavioral validation is where the durable correctness signal comes from, and teams that lean on human line-by-line review as their primary gate will not scale. But you earn your way out of review by building a validation harness you can actually trust, and almost nobody has one of those on day one. Until you do, review (increasingly by another agent) is a load-bearing safety net. The teams that ripped it out before earning that trust are the ones generating the failure stories in the next section.
Where it breaks
Every team running a software factory has hit these failure modes:
- Generation outruns verification. Cursor says it often runs multiple cloud agents on the same harder problem and selects the best result. A single run is not a reliable sample when the task or validation signal is ambiguous.
- The agent grades its own homework. Teams running self-reporting quality checks consistently find the agent is too lenient on itself, marking work "done" that isn't. Your quality signal cannot be the same model that did the work.
- Silent failure is the enemy. Malguitou's rule of thumb, "your friend is visible failure, not silent failure," exists because agents fail quietly by default: a capped conversation that stops mid-task, a test that was never really exercised, a check that passed for the wrong reason. Engineer your factory so failures are loud.
- Code quality erosion is measurable. GitClear's research reports rising code churn and duplication as AI-assisted code grows. The debt doesn't disappear; it moves downstream. A factory that optimizes throughput without watching quality is a factory for producing debt faster.
- Velocity theater. If you can't measure output quality and downstream cost, all you've built is a faster way to feel busy.
None of these are reasons to avoid building a factory. They're the reasons the operating model (the harness, the back-pressure, the tiered review) is what you're actually building.
How to build a software factory
If you want to actually stand one up, the shape of the work is consistent:
- Make your environment reproducible. Everything downstream depends on a machine being able to instantiate your app from scratch. Do this first even if you never deploy a single agent; it's worth it regardless.
- Put agent sessions in isolated cloud sandboxes. Get them off individual laptops. This is what unlocks parallelism and non-engineer access, and it's where the secrets-isolation design lives.
- Build the validation harness before you scale generation. Tests, evals, scenario checks: the inspection station. Generation without verification is a debt machine.
- Add back-pressure so agents self-correct pre-PR. Linters, hooks, static-analysis rules inside the sandbox.
- Start with small tasks; climb the autonomy ladder as trust compounds.
- Instrument everything. Observability keeps a fleet of agents debuggable and your velocity claims backed by data.
A factory-ready task packet
Before an agent starts, give it a contract that makes both execution and stopping conditions explicit:
- Objective and non-goals: what outcome is required and what must not change
- Context: relevant files, tests, documentation, prior decisions, and known failure modes
- Acceptance criteria: observable behavior, including edge cases
- Capabilities: allowed and denied tools, paths, commands, network access, and credentials
- Checks: the exact tests, linters, builds, migrations, security scans, and scenario evaluations to run
- Terminal states: complete, retry, no-op, or escalate to a human
- Evidence: changed artifacts plus every check that passed, failed, or was skipped
- Rollback: the smallest safe way to undo the change
This task packet is the standardized unit of work on the factory line. If it is vague, the rest of the system can only automate that ambiguity.
This is the exact pattern I open-sourced as OpenInspect (GitHub, ~2.1k stars, MIT-licensed). It's a background-agent system built on one idea: "one session, many surfaces, many people." A single agent session is reachable from Slack, Linear, GitHub, and a web app; it runs in its own Modal sandbox, keeps all state and secrets in a Cloudflare control plane outside that sandbox, reviews its own PRs, and can spawn parallel sub-sessions. It's deliberately modeled on Ramp's internal "Inspect" system, the same lineage the industry keeps citing alongside Stripe's Minions. If you want to see the factory pattern as working code rather than a diagram, start there.
Related implementation guides
- Building an AI agent's code-execution environment
- Choosing sandbox infrastructure for agent fleets
- Designing an LLM evaluation harness
- Making LLM systems reliable
- Observability for coding-agent sessions
The takeaway
A software factory is an operating model: reproducible environments, isolated sandboxes, a validation harness you trust, back-pressure that lets agents fail cheaply, and a review policy matched to risk. The teams furthest along got there by building a good factory around a good-enough model. Their ceiling was set by how well they could verify, not how fast they could generate.
For engineers, the shift is from "how do I write this code faster" to "how do I build the system that writes it." That's the Level-3 jump most people won't make, and it's where the leverage is going.
Work with me
I help B2B software teams install the internal software factory: OpenInspect or a system like it, sandboxed agents, production integrations, secrets and review design, and the operating model to run it safely. If your team is on Cursor or Claude Code and leadership is asking how to scale agents beyond individual developers, I run an OpenInspect Readiness Review that shows what would break first.
Book a call or see how I work with teams.
Cole Murray is the creator of OpenInspect, an open-source background-agent platform. Previously he built large-scale ML systems at Amazon, including the first machine-learning content-ranking model on the product detail page and the 1,000+ daily pipelines behind "Frequently Bought Together," and he researches AI security (the Cline supply-chain attack, multiple n8n CVEs). He's spoken on background-agent systems at the Background Agents Summit, on Modal's platform, and on the Latent Space podcast.