All articles
What is a software factory?
We define what a software factory is: agents carry work from signal to release around the clock, while humans set intent and approve at checkpoints.
·
Max Körbächer
A software factory: software production that runs around the clock.
Software has always been made by hand, even with modern pipelines. Someone read the ticket, wrote the change, ran the tests, opened the pull request and asked a colleague to review it. Everything we automated came after that person was done. A software factory automates the work itself, not just what follows it.
A software factory changes the unit of production. Work enters the system as a signal, agents carry it through planning, implementation, verification and release, and people step in only where their judgment is needed. In other words, software production does not stop when the office empties.
The term, though, is used loosely. Therefore, let’s try to pin it down, with a focus on the part that changes everything: software is now produced continuously by agents, and the humans on that line now have a different job.
The software factory definition
A software factory is a codified, largely automated production system that carries work through the entire software lifecycle: from incoming signals such as requests, bugs and alerts, through planning, implementation, verification and release, to monitoring. Agents do most of the execution inside standardized workflows and quality gates. Humans set intent and approve at defined checkpoints. The system measures its own runs and feeds what it learns back into itself.
The definition deserves a closer look, because each clause rules something out:
Codified means the factory exists as code and configuration, as repositories, agent definitions, policies, skills and prompts, so it can be versioned, tested and improved like any other system.
Entire lifecycle means it is not a coding assistant; it starts before the code exists and continues after the release.
Agents execute means a human is no longer the default worker at each station.
Humans approve at checkpoints means the factory is supervised, not abandoned.
Measures itself means every run is data, and the factory gets better because of it.
From assistant to production system
I think it helps to see how we got here. The first wave of AI in software development was autocomplete: the engineer typed, the model suggested, and the engineer stayed in charge of every line. The second wave was the interactive agent: the engineer describes a task, an agent gathers context, edits files, runs tests and comes back, and the engineer steers it from the terminal or the editor. Almost every development team is in this second wave today.
The factory is the third wave, and it is a different kind of thing.
The agent is no longer waiting for an engineer to type. Work enters the system from wherever it originates, an agent picks it up, and the system carries it through to production with humans involved only where their judgment is needed. Factory's Tereza Tížková draws the line sharply: a software factory is not a coding agent and not even a swarm of coding agents, because writing code was always the easy part. The factory exists for everything around the code.
The loop
Every working factory has the same shape, and the shape is a loop rather than a pipeline. This is why the term “Loop Engineering” was briefly hyped, until people realized that it describes the same thing.
This cycle repeats like clockwork:
Work enters as a signal: a feature request in Slack, a bug report, a crash in an observability tool, customer feedback, a failing test.
Triage decides whether the signal is real, whether it already exists in the backlog, and whether it is small enough to implement directly or needs a specification first.
Planning turns it into scoped work that carries acceptance criteria, an owner and a target environment.
Implementation agents write the change, usually in isolated environments so several can work in parallel.
Verification runs tests and static checks and, increasingly, an agent that uses the product like a customer would and records what it sees.
Review combines an automated reviewer with a human whose involvement depends on the risk of the change.
Release ships it.
Monitoring watches what shipped and turns anomalies, incidents and usage into the next signals.
It is important that the inputs are standardized: every unit of work carries scope, acceptance criteria, an owner and a target environment. Additionally, the tooling must be standardized: agent-written and human-written changes pass through the same gateway, the same evaluations and the same release controls. A CI/CD pipeline automates what happens after a human has written the code. A factory standardizes the work itself. It is sort of the same thing, just applied to two different entities.
How agents work inside the factory
Inside a single “unit”, practitioners describe a structure that looks like a small team.
An orchestrator agent reads the task and writes down, before any code exists, what “done” will mean. This is often called a validation contract. Worker agents then execute, and here practitioners agree on something counterintuitive: they work in sequence, not in a swarm. Each worker does its part with fresh context and hands the result to the next, the way a colleague picks up a pull request with a clear head. Within its own step a worker may spawn parallel sub-agents for small jobs such as research or file generation, but the main line is sequential. Validators then judge code they did not write. One kind reads the codebase with the rigor of a strict reviewer: linters, types, tests, module boundaries, duplicated logic. The other kind does not look at the code at all; it opens the product in a virtual machine, clicks through it, and checks whether the thing actually works. If the contract is not met, the work goes back to the start.
Factory calls these long-running units missions. Missions already run for weeks, and the companies creating them expect runs that last months.
What “around the clock” actually means
This is the part customers underestimate. The factory has no shifts. Signals arrive at any hour, agents pick them up at any hour, and the only thing that stops a unit of work from reaching production overnight is a checkpoint where a human must look.
Warp, which runs its own factory in public, reports that an agent needs about thirty-five minutes from kickoff to a pull request, and that the pull request then waits about three and a half hours for its first human review. The factory produced more than two thousand pull requests in a month. But the queue formed at the humans.
That is why we have to redesign the human role. Humans define intent. Humans approve releases. Humans review what matters, and what matters is decided by risk: a change with a small blast radius, say a front-end tweak that touches no shared component, is merged by the factory, while a change to a database schema, a security boundary or a shared library waits for a person. The person who prompted the agent may also review its output, which used to be forbidden. And because an unattended agent will loop forever on a problem it cannot solve, every factory has to set hard limits: a maximum number of turns, a spend cap per task, and an escalation path to humans.
What it means for the end-user market
For an enterprise, a running factory changes more than velocity.
Throughput moves first. Teams running factories report ten to twenty pull requests per developer per day and thousands per month for a mid-sized company. In many cases this means that the backlog disappears. Not because there are no issues, but because issues become short-lived and are solved quickly. A bug raised at 03:23 am will be reproduced and tested five minutes later. And if a potential resolution is provided, it will be fixed before any engineer knew it ever existed.
We can also see that the bottleneck moves, and it moves to the customer's own people. Review becomes the limiting station, and with it the organization has to decide, explicitly, which changes still need a human and which do not. That is a governance decision, and a very hard one, as it has to be made before the factory runs, because an unreviewed queue of two thousand pull requests is not a factory, it is pure chaos.
What scares many is that cost becomes a first-class engineering metric. With personnel, costs are in some ways not transparent. Sure, in the end you know how much you spend on salaries per department, but once you know what every task costs, you gain a level of transparency that is often scary. A factory that runs every task on the largest model burns budget without improving outcomes. The companies that run factories route each task to the cheapest model predicted to clear its quality threshold, cache aggressively, replay past tasks against new model configurations before switching, and report cost per pull request next to lead time.
The organization changes shape. Work starts in public channels rather than on laptops, so anyone can see what the factory is doing and why. Product and engineering blur, because the person who can describe a feature well enough for an orchestrator to write its validation contract is doing product work. Team boundaries blur, because the factory needs context that used to live in silos.
And the engineers' job changes. They write less code and ship more. Their work becomes building, tuning and supervising the system that builds the product, which some call factory engineering or harness engineering. Digitally native companies are hiring more engineers than ever for exactly that. Customers who expect a factory to shrink the engineering team usually discover they need the same people doing different work.
One honest caveat belongs in every customer conversation. Nearly all of the headline figures come from the vendors and companies that benefit from them, and the independent measurements are sobering: review time per change up sharply, pipeline runs up, main-branch throughput down for the median team. A factory that is not designed as a whole produces more code and ships less of it.
What the customer needs to have
A factory does not run on an unprepared organization.
The codebase has to be legible to a machine. That means linters and formatters that encode the house style, build and test commands that are documented and reliable, tests that are fast and trustworthy enough to serve as the factory's quality gate, documentation that is current (including the agent-facing files that tell an agent how the repository works), module boundaries that are clear enough to limit the blast radius of a change, observability good enough to answer why something broke, and security scanning that runs inside the loop rather than after it. Factory treats these as pillars and makes the point that paving them helps human engineers exactly as much as agents. Stanford found that on an unstructured codebase, agents make things worse, and the mess grows faster than a human team can clean it up.
Environments have to be reproducible, on demand, by a machine. An agent that wants to validate a change needs a sandbox with the right data, services and credentials, and it needs it in minutes, not through a ticket. The development environment is the most underrated layer, and the organization has to own it.
Context has to be unified. Enterprises run hundreds of tools, and an agent that has to discover them one by one wastes tokens and picks the wrong ones. An MCP gateway can help as a single front door to every internal system, with descriptions of how the company organizes its information. It is the best first investment for anyone starting a factory.
Trust has to be built in steps. You are well advised to start with something narrow and verifiable, such as incident triage, where an agent reads an alert and proposes a diagnosis for a human to confirm, and to let correct diagnoses accumulate before the next pillar is automated. Nobody who runs a factory switched it on all at once.
And, finally, someone has to own it. A factory is a product with customers, a backlog and a service level. If nobody's job is to improve it, it stays at whatever quality it had on the day it was built.
What comes next?
A software factory alone is not enough. You need to own the right environments, infrastructure, competencies, and more.
But that is something we will cover in the coming weeks.
Share