What a software factory is

Ask someone to draw a software factory and you will nearly always get a row of boxes with arrows between them: request, plan, build, review, deploy. It is a reasonable picture of a pipeline and a misleading picture of a factory, because the arrows that make it work are the ones that go back the other way.

Two loops, not a line#

There are two circuits, and they do different jobs. The first decides what to build: it takes intent, an existing backlog and reported problems, and produces work items that are actually buildable. The second builds them: it takes one such item and produces an implemented, reviewed, verified, deployed change. A single hand-off joins them, and it carries exactly one thing — a work item somebody could hand to a competent stranger.

Then there is the arrow that closes the circuit. Something fails in production; that failure is turned back into a work item and re-enters the first loop. It is not a third loop and it does not need its own machinery. It is the return path, and a factory without it is a machine that produces changes and never finds out which ones were wrong.

Inside those loops sit smaller circuits of the same shape, and they are where most of the actual work happens: build, test fails, fix, test again. Deploy, verification fails, new work item, fix. And the one that matters more than either — an agent fails the same way three times, and a person changes the instructions so that whole class of failure gets less likely, rather than fixing the one change in front of them. That last loop is the difference between a factory and a fast code generator, and it is the one nobody demos.

What a narrow agent buys you#

Every agent in a factory has one job, one trigger and one defined output. Not because a model cannot do more than one thing, but because narrowness is what makes the other properties possible. An agent with one job can be given credentials for exactly that job. Its output can be validated against a schema before anything acts on it. Its failure rate can be measured, because there is one thing it was trying to do. And when it is wrong, you can change its instructions without changing anyone else’s.

The reverse is the tempting design and it does not survive contact: one capable agent with broad tools, guided by a long instruction file. It cannot be given narrow credentials because it needs all of them. Its failures cannot be attributed because you cannot tell which of its jobs went wrong. And the instruction file grows until it contradicts itself, which it will, and then nobody can say what the agent is supposed to do.

Narrowness also has a price, and it is the one people underestimate: every boundary between agents is a place where context is lost. The agent that plans a change knows things the agent that builds it does not, and the only way to carry that across is to write it down. Which is why what gets written between agents ends up being the real design work, rather than the prompts.

One change, all the way through#

Everything above is the shape. This is one change actually moving through it — fourteen steps, each one an agent or a person writing something down. Nothing runs until you press.

Watch for the two moves that go back up the lanes. Neither is a failure; both are the machine working.

The straight-line version of that walk — request, build, review, deploy — is four steps and it is the version most people carry in their heads. The real one is fourteen, two of which go backwards, and one of which is a person deciding. That gap is where the interesting engineering is, and the rest of this path is spent in it.

The numbers that do not transfer#

There is one thoroughly documented public software factory, and it is worth reading properly rather than quoting. Ona built a Notion-style note-taking application across ten streaming days in April 2026, published the whole pipeline, and reports 688 pull requests merged, 77,424 lines of code, 88% autonomous execution and 100% green CI. Every one of those numbers is real. All of them were produced on a brand-new small application, by the company that builds the agent platform, with the tooling shaped around the codebase from the first commit.

Production settings read differently. Spotify runs a background coding agent — Honk, built on the Claude Agent SDK inside their own harness, in Kubernetes pods — and reports more than 2.5 million automated maintenance pull requests merged and a 76% rise in pull request frequency. The finding buried in that write-up is the useful one: in their more fragmented codebases, agent performance is measurably worse. Consistency of the surrounding code is the strongest predictor they report, which means the first work of building a factory on an existing system is usually not building agents at all.

And across Jellyfish’s benchmark of 99 million pull requests from more than 1,300 companies, the top adopters see 48% of pull request throughput come from autonomous agents, while the median company merges 0.7% of its pull requests with no human review at all. Read together those two figures say something precise: agents are opening a great deal of work at the leading edge, and almost nobody is letting that work merge unread. A factory is a proposal engine with a person at the end of it.

There is one more result worth keeping in view before setting any target. METR ran a randomised controlled trial with sixteen experienced open-source developers across 246 tasks on repositories they already knew well. With AI tools allowed, they were 19% slower. Afterwards, they estimated they had been 20% faster. Whatever a factory is measured on, it cannot be how quick it felt — which is why the instructions the agents share have to be treated as something that gets tested rather than something that gets edited.