Published 19 Sept 2026
In 2019 I wrote that coders are creatives, not factory workers. The argument was simple: writing software means working through a problem and designing a solution to it, and organisations that treat developers as operatives on a production line get worse software and lose their best people. Seven years later the factory is back, and this time the workers on the line are AI agents.
The language has spread very quickly. In June 2026 Factory published "Factory 2.0: From coding agents to software factories", describing a system that "starts with signals from the outside world: bug reports, internal conversations, customer feedback, business requirements" and flows them through autonomous agents. "This system is the software factory." The same week Warp's CEO Zach Lloyd published a piece titled We are now factory engineers, not product engineers, describing a loop of triage, specification, implementation, review, verification, CI/CD and monitoring, with agents doing the work at each stage. BCG Platinion describes the Agentic Software Factory as a new operating model in which "autonomous AI agents build, test, and ship software solutions around the clock, while humans define business intent and review outcomes."
The technology underneath all of this is genuinely new, and some of what these teams are doing is impressive. What strikes me is how old the mental model used to explain it is. I think the agentic software factory is the wrong metaphor, and it matters, because software engineering is a discipline of design engineering. Coding agents make that more true, not less, and the organisations that get the most from them will be the ones that use them to design better rather than to manufacture more.
It is tempting to dismiss this as a quibble about words. Every industry borrows metaphors, and nobody thinks a software "architect" pours concrete. The problem is that "factory" is not an innocent label. It carries an implicit theory of what the work is: inputs become outputs through a repeatable production process, and improvement means increasing throughput, reducing variation and automating the line.
Metaphors shape management behaviour. If leaders believe they have a factory, certain moves become natural: optimise utilisation, standardise the inputs, count the outputs, increase throughput, eliminate variability and treat specifications as raw material flowing down a pipeline. Each of those moves is sensible in a factory. If what you actually have is a highly accelerated system for design and discovery, several of them are actively harmful.
So the question worth asking is which theory of the work is right. Here the industry has a surprisingly long answer.
In 1992 Jack Reeves wrote an essay for the C++ Journal called What Is Software Design? His argument was that we had misidentified which part of software development corresponds to manufacturing. In physical engineering, a design is produced and then built, and the building is expensive. Reeves pointed out that the design of a piece of software is its source code, and the build is performed by tools:
If source code is a software design, then actually building software is done by compilers and linkers.
From that he drew the conclusion that programming is a design activity, and that testing and debugging are design activities too, the software equivalent of validating and refining a design. Software, he noted, is so cheap to build that it is almost free.
Martin Fowler picked this up in The New Methodology, one of the essays that articulated the thinking behind agile. If construction is so cheap as to be free, then all the effort in software is design, and design needs creative and talented people. Creative processes are not easily planned, so the predictability that traditional engineering methodologies promise may be an impossible target. That was the organisational consequence: stop trying to run software like a construction project.
Dave Farley makes the same argument in Modern Software Engineering, and puts it more bluntly than anyone:
Software development, unlike all physical production processes, is wholly an exercise in discovery, learning, and design.
Farley's point is that physical engineering has two distinct problems. If you want a new kind of bridge, you first have to work out what bridge will work, and then you have to undertake the expensive, slow and risky business of building it. Software has only the first problem. Once the design exists as source, production is a matter of triggering the build. Software engineering is therefore purely a discipline of design engineering.
Follow that through and something interesting happens to the factory metaphor. If Reeves is right, we already have a software factory. It runs from source code to compiler, to package, to deployment. We have spent the last two decades automating it with build systems, continuous integration, infrastructure as code and deployment pipelines, and in a well-run organisation it is exactly as boring, repeatable and standardised as a factory should be.
What coding agents automate sits on the other side of that boundary. They produce and revise the source, which is to say they produce and revise the design. An agent is not another robot on the assembly line. It is much closer to another designer, working inside an extraordinarily fast loop of hypothesis, implementation, test and revision. BCG Platinion's model is revealing here: the phase where agents generate code and tests is labelled "Construction". Reeves spent an essay arguing that this is the one thing writing code is not.
Once you see code generation as design work, the factory framing starts to break in specific and predictable places.
The first is that a factory assumes the design problem has already been solved. Manufacturing starts after someone knows what should be made, and the engineering drawing specifies it precisely. In software, working out what should exist, what behaviour is correct, how the system should be structured and how competing constraints should be traded off is the work. A ticket is not an engineering drawing. Treating it as one moves the design work out of sight rather than removing it.
The second is that requirements behave like hypotheses rather than raw materials. Anyone who has built software for long enough knows that requirements contain ambiguity, wrong assumptions and gaps, and that the act of building something generates information that changes our understanding of what was wanted. That is the point I was making in Development Is Complex, Not Complicated: the code may be complicated, but the people and problem domains it is built for are complex, and you cannot process your way through complexity. A factory model encourages "spec in, software out". Design engineering expects the specification to evolve as we learn.
The third is that variation means something different. Manufacturing works hard to eliminate variation because identical outputs are the goal. Design depends on variation. If ten agents produce ten different approaches to a problem, that can be enormously useful precisely because they differ. The valuable work is in comparing, testing and selecting the better design, not in forcing every agent through an identical production station so that the outputs converge.
The fourth is the most insidious. To keep a factory busy you need a steady queue of well-defined work orders. That creates organisational pressure to turn uncertainty into apparently precise tickets earlier than the knowledge supports. The ambiguity has not gone anywhere. It has been hidden in the input to the agent, which will cheerfully resolve it with a plausible guess and produce a confident, well-tested implementation of the wrong thing.
We now have some data on what happens when AI accelerates code production. The 2025 DORA report, State of AI-assisted Software Development, describes AI's primary role as "an amplifier, magnifying an organisation's existing strengths and weaknesses". Reversing the previous year's finding, AI adoption was associated with higher delivery throughput, but software delivery instability continued to rise. DORA's interpretation is that teams have adapted for speed while the systems around them have not caught up, and that the returns come from the underlying organisational system rather than from the tools. Organisations with mature value stream management practices were better at turning individual gains into organisational ones.
I read this as evidence against the factory framing, although DORA doesn't put it that way. If code were the product, more code faster would be straightforwardly good. What the data suggests is that code is an intermediate artefact whose value depends on everything around it: the quality of the design decisions, the fast feedback that tells you whether a change was right, the architecture that contains the blast radius when it wasn't. When code generation becomes cheap, generating more code is not the optimisation problem.
This also explains why output becomes a more dangerous proxy for productivity as agents improve. Warp's piece is admirably direct about its metric:
Success is measured not by how many features an engineer ships; that's a failure metric. It's measured by the percentage of all changes that are shipped automatically, and at what cost.
I agree that features shipped is a poor measure. But the proposed replacement measures the degree of automation of the line, which is the factory's measure of success rather than the customer's. If agents can generate ten times as many changes, counting pull requests, story points, features or the share of them that were automated tells you less and less. The economically relevant questions are the ones they always were: is the product performing better, are customers getting more value, has risk gone down, and is the organisation learning faster?
None of this means everything being called a software factory is misguided. There are genuinely production-like parts of software engineering, and standardisation and automation are exactly what we want for them. The build pipeline is one. So are provisioning environments, running test suites, dependency upgrades, routine migrations, formatting, static analysis and some classes of remediation. Much of the most convincing evidence for agentic automation comes from exactly this kind of work: BCG Platinion cites Spotify's reported time savings on migration workflows, and those are tasks where the design question has largely been answered and the remaining effort really is repetitive.
The Software Engineering Institute draws the distinction well in its work on value stream mapping for DevSecOps. Manufacturing value streams are almost entirely production-oriented, executing to a finalised specification. Software development value streams interleave discovery-oriented activities, such as requirements refinement, architecture, technical spikes and exploratory testing, with production-oriented ones such as builds, configuration management, regression testing and coding to well-established patterns.
So the sharper version of my argument is this: we should build factories for the parts of software engineering that are actually production, and we should not mistake the factory for software engineering itself. It is also worth noticing that the more thoughtful factory advocates are not far from this position. Warp's piece says that throughput is now bounded by the rate at which the team can define intent, review traces and approve releases. Defining intent and judging whether the result is right is design work. The bottleneck they describe is the design loop.
If agents are designers rather than assembly line workers, the most valuable thing they offer is cheap experimentation. An agent can form a hypothesis about how to solve a problem, implement it, run the tests, inspect the behaviour, revise the design and go round again, at a speed no human team can match. Reeves pointed out in 1992 that software's economics were unusual because the build was nearly free, which made it rational to design by writing code and testing it. Agents push those economics further: now the cost of producing a candidate design is collapsing too.
That changes where the scarce resource sits. As implementation gets cheaper, the things that remain expensive become proportionally more important: understanding the domain, being clear about intent, choosing the architecture, making trade-offs, verifying behaviour, and deciding whether something actually solves the customer's problem. Those are exactly the capabilities a factory model tends to push out to the edges, framed as the "input" and the "quality gate", when they are the core of the work.
It also changes how we should use the agents themselves. A capable agent can investigate an unfamiliar codebase, challenge an assumption in a requirement, prototype two alternative designs and report back on how each behaves. Treating it as an infinitely scalable implementation worker that turns tickets into pull requests leaves most of that capability on the table. Agents do not eliminate discovery. Used well, they participate in it.
I understand why "factory" appeals, particularly to the people who fund software. Factories promise predictability: specified work goes through a repeatable process and produces measurable output, which supports capacity planning and economies of scale. After decades of software projects that overran and underdelivered, a model that promises to make the whole thing governable is very attractive.
But autonomous agents do not remove the uncertainty from product development. What they do is dramatically increase the rate at which we can interrogate it. That points to a different management challenge. The factory question is how to keep the agents supplied with enough well-specified tickets. The design engineering questions are more useful. How quickly can we turn an assumption into evidence? How cheaply can we explore alternative designs? How quickly do we find out that we were wrong? How much do we learn about our customers from each iteration? And how reliably can our agents operate within the architectural and safety constraints we have set?
The industry spent roughly thirty years learning, from Reeves through agile to Farley, that building software is design work and that managing it like manufacturing makes it worse. Coding agents are a profound change to that work, and they strengthen the lesson rather than overturning it. We should use them for what they are: a way to do design engineering at machine speed.