Stripe merges more than 1,300 pull requests every week that contain zero lines of human-written code. A three-person startup called StrongDM ships production software that no engineer writes or reviews. At Uber, an internal system called Minion now generates over 11% of all merged 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 spec or an issue in one end and produces a merged, verified pull request out the other, with fleets of AI coding agents doing the work inside a validation 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.
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.
That is deliberately broad. What's new with AI is who works the line.
An AI (or agentic) software factory is a system where autonomous coding agents do the production work. You give it a specification, sometimes as small as a labeled issue, and a fleet of agents plans the change, writes the code, generates the tests, runs them in an isolated environment, and opens a pull request, with a validation loop catching failures and feeding them back until the change converges. Humans set the direction, define what "correct" means, and review at the edges. They are not in the keystrokes.
The clearest one-line version comes from Zacharias Malguitou, who built one in public: you move "from in the loop to on the loop." Instead of producing each change yourself, you steer the system that produces them.
Software factory vs. AI factory vs. platform engineering
Three terms get tangled here. Untangling them is worth a table, because Google currently returns all three for overlapping queries and 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.
The core loop: seed, validation harness, feedback
The cleanest formulation I've seen comes from StrongDM, whose engineering team reduced their whole 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. They argue 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.
What the data actually shows
The real numbers are scattered across conference talks and blog posts. Here they are in one place, with attribution, so you can judge how far along this actually is.
| Team | What they report | Source |
|---|---|---|
| Stripe ("Minions") | 1,300+ PRs merged per week with zero human-written code (still human-reviewed) | Alistair Gray, Stripe |
| Cursor | ~35% of internally merged PRs authored by agents; agent usage up 15x in a year | Michael Truell, Cursor |
| Ramp ("Inspect") | ~30% of merged frontend/backend PRs | Ramp Engineering |
| Uber ("Minion" / "Shepherd") | 11%+ of all merged PRs; agents complete 50-70% of a task before human validation | Uber Engineering |
| Harvey ("Spectre") | ~30-50% of a run's PRs are production-valid, so they run multiple attempts and pick | Joey Wang, Harvey |
| StrongDM | 3-person team; ~$1,000/day per engineer in token spend; a full "digital twin" of external dependencies for testing | via Simon Willison |
| Ona (public "software factory" build) | 375 PRs merged in 10 days; ~68k lines; 2,000+ tests; 87% of PRs merged autonomously; median issue-to-close 38 minutes | Zacharias Malguitou, Ona |
| Factory.ai (vendor's own figures) | 36 deploys/day; 98.7% PR pass rate; MTTR under 22 minutes | factory.ai |
A few honest caveats. The Factory.ai row is a vendor's self-reported marketing numbers, so treat it accordingly. The Stripe, Uber, Ramp, and Harvey figures come from engineers describing their own internal systems in talks, which is about as good as external data gets but is still self-reported. None of these teams claim their agents ship unsupervised into critical paths, either. Stripe's own line is blunt: "Stripe is not moving money without human review." The factory runs the line; humans still own the risk.
Two reality-check statistics belong next to the impressive ones. In a talk on "dark factories," Shardul Vaidya cited a 53% decline in accuracy when an agent is run with no feedback loop (the "trust all tools, walk away" configuration), a direct measurement of what happens when you skip the validation harness. And he pointed at the gap that should make every leader cautious: 91% of engineering leaders say AI has improved velocity, but only 25% have the data to prove it. The factory metaphor is seductive precisely because it feels productive, and feeling productive is not the same as being productive.
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, in Malguitou's words: "it all boils down to how good is your spec." 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. And you tier your review policy by risk: Stripe's model runs from "one human plus one agent approves this low-risk PR" all the way down to "agent eyes only" for the lowest-risk tier, with human review non-negotiable for anything touching money. 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 and flatly will not move money without a human. OpenAI's engineers still own the final review and merge. Ryan Carson's "PR control plane" pattern makes an automated code-review agent a required merge gate. These are not laggards; they're among the most advanced operators in the world, and they have all kept a reviewer (human or agent) 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. Harvey reports only 30-50% of a given run's PRs are production-valid, which is why they run multiple attempts and select. If you trust a single run, you ship the other half.
- 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 ongoing analysis of millions of commits has reported rising code churn and duplication as AI-generated code lands. 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. Back to the 91%/25% gap: 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.
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.
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.