What software factory engineering is, and what it isn't

The phrase “software factory” is older than any of the models people now attach it to. In the 1980s NEC, Hitachi and Fujitsu ran literal software factories: standardised processes, quality checkpoints, software treated as something you manufacture rather than something you craft. Microsoft formalised the idea in 2004 around domain-specific languages and reusable assets. Neither version caught on in the West, where programmers thought of coding as craft, and the term went quiet for twenty years.

It came back in 2026 because the thing on the line changed. The workers are now coding agents, and the question is no longer whether they can write code. It is what has to be built around them so that what they write can be trusted and shipped.

The 2026 meaning

A software factory, in this year’s sense, is a delivery system in which agents carry a piece of work from intent to production: triage, plan, implement, test, review, ship, monitor. Humans design that system, set the intent, and sign off at the gates. Gartner called it the north star for agentic engineering in September. Addy Osmani put it more plainly: you are building the factory that builds your software.

Zach Lloyd at Warp drew the line I find most useful. Agentic engineering, he argues, is now two disciplines. Product engineering is making sure the product is good. Factory engineering is deploying agents to build that product and improving how well the system does it. His version: you’ll be building the thing that builds the product.

That second discipline is what I mean by software factory engineering. It is the work of designing, running and retuning the factory. Not the product, and not the model.

Steered or lights-off

Two factories are being sold under the same name, and they are opposites.

At one pole, StrongDM published rules for its own factory under which code is neither written nor reviewed by humans. Dan Shapiro called this the dark factory. The argument is that if the tests are good and they pass, nobody needs to read the code, because agents will maintain it anyway.

At the other pole, Stripe’s internal agents write a large share of the code and humans review all of it. Vercel reportedly merges nothing without a human maintainer’s approval.

← no human touchesa human reads every line →

$ dark

Dark factory

Nobody writes the code and nobody reviews it. StrongDM’s rules.

$ steered

Steered factory

Agents write. Humans own the spec, the design and the merge. Where I build.

$ lights-on

Lights-on factory

Agents write, and a human reviews every line. Stripe’s model.

I build the steered kind, and the reason is not caution for its own sake. Dex Horthy’s talk Why Software Factories Fail names the problem precisely: the model was trained to make tests pass, not to keep code easy to change. The cost of bad design shows up months later, when nobody has read the code in a long time and debugging means relearning it. A harness can raise the floor, but it cannot fix an objective that was set at training time. The practitioners who ran lights-off on their own codebases are the ones now arguing for human design review.

So humans stay at the gates. That is not the absence of humans. BCG’s phrase for it is the relocation of human effort: away from keystrokes, toward intent, architecture and sign-off.

What the work consists of

Three parts, in the order I build them.

Loops. An agent working toward explicit done-criteria: plan, act, check, repeat, and stop and ask when it cannot tell whether it is done. Hand-rolled, no framework. When a loop keeps failing, the cause is usually missing tooling, not the agent: the app cannot be run with one command, or the tests do not exercise what matters.

Harnesses. An agent is a model plus a harness. The harness has guides, which steer the agent before it acts (rules, context, constraints, the spec), and sensors, which check it after (tests it cannot edit, a reviewer that is not the author, behavioural checks against the running product). The harness, not the model, decides what can be trusted. Generation is cheap now and verification is the bottleneck, so most of the engineering lives here.

Human gates. Named points where a named person signs off: the spec, the design, the merge, the release. Each gate has one accountable human. Warp tracks human touches per PR and tries to lower it. I think that is the right metric, provided the number is lowered deliberately and never reaches zero on the gates that matter.

The product of all this is not code. It is proof that the code does what the intent said, produced reliably enough that a merge is a decision rather than a leap.

What mine looks like

For the sake of receipts, here is the factory I run today, in five pieces. First, the team: each agent has a written role and a set of responsibilities, the way you would write them for a hire. Second, intake: a working session with Claude turns the sprint into Linear tickets, each naming the agent responsible and carrying acceptance criteria written so the harness can check them, rather than a human reading a diff. Third, the loop: a scheduled routine picks the highest-priority ticket and works it to those criteria, and an n8n workflow watching Linear calls the routine again when a ticket completes, so the line runs one ticket at a time. Fourth, the gate: a ticket that needs a decision gets a blocked tag, a human unblocks it and hands it back, and the queue of blocked work is visible in Linear rather than buried in a log. Fifth, memory: what the agents learn accumulates across runs, and a periodic “dreaming” pass synthesises and prunes it so the knowledge stays current. It is working, not finished. A later post will walk through it piece by piece, including what it counts and what it has got wrong.

$ ticket

Linear ticket

Names the agent responsible. Acceptance criteria the harness can check.

→

$ pick

Routine picks it up

Highest priority first. One ticket at a time.

→

$ work

Agent works it

Loops until the criteria pass, or stops when it needs a decision.

→

$ done

Done

n8n sees the close and calls the routine for the next ticket.

↻ done triggers the next pickup

$ blocked · the side exit from work

Blocked tag

A human unblocks it and hands it back to the line. The queue of blocked work is visible in Linear, not buried in a log.

$ memory · under every step

Agent memory

Accumulates across runs. A dreaming pass synthesises and prunes it so the knowledge stays current.

What it isn’t

It isn’t a tool you buy. Several platforms will sell you one. Buying an orchestrator gives you a place to run agents. It does not give you the done-criteria, the sensors or the ownership. Those are specific to your codebase and your team, and they are the factory.

It isn’t a speed multiplier. You will see 3x, 5x, 10x. Almost none of those figures are measured against anything. The numbers worth trusting are counts with a window and a source: PRs merged, PRs reverted, cost per PR that stayed merged. If someone quotes a multiplier, ask what the denominator was.

It isn’t the absence of humans. Covered above, but it bears repeating because it is the fear that stops most teams. A steered factory has more deliberate human involvement than ad hoc agent use, not less. It is in different places.

It isn’t new. The Japanese factories lost in the West because the craft argument won. It is worth asking why this round is different, and I think the honest answer is that the worker is now the thing being standardised, not the engineer. That is a real change. It is also a reason to be careful about which parts of the craft you give up.

Where to start

If your team is already using agents ad hoc and the output is uneven, you do not need a platform decision. You need one loop with a clear stop condition, one sensor the agent cannot game, and one person who owns the merge. Build those, measure them for a month, and you will know what the next piece is.

If you would like a second pair of eyes on where that first loop should go, book a call. I will tell you honestly whether a factory helps.