Factory engineering means improving the automated system that produces software (its AI agents, instructions, model choices, checks and metrics) instead of each piece of code. Recorded runs turn recurring failures into fixable defects, though misleading metrics and biased AI graders limit the approach. The APEX operating model describes such a factory for any output, and AION extends it to whole organizations. A dedicated owner pays off only where work repeats and changes are measured and approved.
Picture a team where AI agents write most of the code. One agent turns a bug report into a fix, another reviews it, automated tests check it, and it ships. When the fix is wrong, someone must decide what to repair: the code, or the setup that produced it.
That second job now has a name: factory engineering. The most common one today is a software factory - an automated system that turns a request into shipped code: the AI agents, the instructions they get, which model handles which step, the checks before code merges, and the metrics that measure it. Product engineers use the factory to build features; factory engineers improve the factory. It is manufacturing's oldest move: improve how things are made, not each faulty item. I think it pays off only where the same work repeats, each change is measured, and factory changes need approval.
An old idea, renamed
On 19 October, Warp published CEO Zach Lloyd's talk with a chapter on factory engineering. That week, Hacker News debated an essay calling personal software factories a waste of time, and Cortex titled a post "A software factory is just a durable workflow".
Cortex is right about the history. Hitachi ran a software factory from 1969, and two Microsoft architects proposed model-driven "software factories" in 2003. What is new: agents do the work, and their setup is versioned code, as Warp's "Factory Stack" post describes. I call this work Graph Engineering, because a factory's design is only a versioned hypothesis about how work should happen.
Every recorded run is evidence
Once runs are recorded, a failure that keeps coming back stops being one bad pull request and becomes a factory defect, the kind Toyota's kaizen (continuous improvement) removes. Warp replays earlier tasks under different setups and reports about 63% lower internal costs. That figure is self-reported. Proving an improvement needs comparable tasks, repeated trials and checks that nothing else got worse.
Factories optimise what they measure
Cost per pull request falls when pull requests shrink, with no extra value delivered. Studies have found AI models that grade AI output favouring longer answers and their own style, so their scores need checking against experts and test cases the agents cannot edit. Agents may propose factory changes, but someone else must approve them.
The factory's design can be wrong too. Anthropic reports teams improving quality, cost or speed by merging sub-agents into one agent, and a peer-reviewed study of 260 setups found multi-agent coordination helps less as single models get stronger. Sometimes the improvement is removing a step.
In Michael Crichton's 1973 film Westworld, Delos technicians sit in a control room while the resort's robots start to malfunction. They repair each broken robot and send it back into the park, and the failures keep spreading. Their consoles show whether each machine is running, but nobody is responsible for the pattern across all of them. I think that is the gap factory engineering fills: treating the failure log as evidence about the system that builds and runs the machines, fixing that system, and keeping a human outside it who decides what counts as working.
The factory does not have to make software
My operating model APEX (Agentic Production Execution) is really an instruction manual for setting up an agent factory. It names who owns each part of the system, from business context and specifications to agent design and quality. Every cycle runs the same way: people set strategy, agents execute and iterate, reflection asks what the runs revealed, and calibration turns that into an approved change. That change needs a protected test, a numeric threshold and a named approver, and the agent that proposed it can never be the approver.
I wrote APEX at an altitude where the output barely matters. In April I published a walkthrough of the same framework running a product team shipping software features, a content team running an editorial pipeline and a research team producing daily market analysis. The artifacts, agents and cadence differ; the ownership and the cycle stay the same.
Zoom out further and I think an organization's entire production could run as a network of agentic factories. Any outcome a company delivers repeatedly follows the same pattern: work arrives, gets done, gets checked and reaches someone who needs it. That is what I explore in depth in my e-book AION: Engineering the Organization for the Age of Agents. AION gives each group of related outcomes a named human owner, makes a standing operation of agents and people accountable for each outcome, and designs every workflow to leave evidence behind. The book's own summary: "Humans govern. Agents operate. Evidence decides."
When the job deserves a person
Peter Piekarczyk, the essay's author, rightly says a personal factory can steal time from real problems; he exempts workplace automation. I found no independent study of what factory engineering returns, so treat the numbers here as illustration.
Whether the factory makes code, articles or market analysis, the test is the same. Does the same work repeat? Are runs recorded? Is there a cost and quality baseline for each change? Do factory changes need approval? If yes, someone should own the machine. If not, build those first; no platform you buy will supply them.
