AI-generated summary of The Agentic Software Factory is the Wrong Metaphor, Rob West. Not written or verified by the author.

Takeaways: The Agentic Software Factory is the Wrong Metaphor

2026-11-05 · Source: https://robwest.info/articles/the-agentic-software-factory-is-the-wrong-metaphor/ · Rob West, published 19 Sept 2026

Gist

West argues "software factory" names the wrong part of the work. Following Jack Reeves (1992), source code is the design, and compilers and pipelines do the building. Software already has a factory: build, CI, deploy. Coding agents work on the other side of that line. They write and revise the design, so they're closer to designers than to robots on a line.

The label matters because "factory" carries a theory of the work: standardize inputs, count outputs, cut variation, raise throughput. Those moves help production and hurt design.

Essay, no new data. He cites vendor posts (Factory, Warp, BCG Platinion), Reeves, Fowler, Farley, the 2025 DORA report, and a DX Q2 2026 report. None of those citations checked here.

Takeaways

• Context. A follow-up to his 2019 post that coders are creatives, not factory workers. The trigger: Factory's "Factory 2.0", Warp CEO Zach Lloyd's "We are now factory engineers, not product engineers", and BCG Platinion's Agentic Software Factory, all from around June 2026.
• Design vs. build. Physical engineering has two problems: work out the design, then build it at great cost. Software has only the first. Farley calls it "wholly an exercise in discovery, learning, and design."
• BCG's tell. Its model labels the phase where agents write code and tests "Construction." West says that's the one thing writing code isn't.

Four places the metaphor breaks

1. The design is assumed solved. Deciding what should exist is the work. A ticket isn't an engineering drawing. Treating it as one hides the design work instead of removing it.
2. Requirements are hypotheses. Building generates information that changes what you thought you wanted. Links his earlier post "Development Is Complex, Not Complicated."
3. Variation is the point. Ten agents giving ten different approaches is useful. The value is in comparing and picking, not in forcing outputs to converge.
4. Feeding the line. A factory needs a queue of well-defined work orders, which pushes teams to write precise-looking tickets before they know enough. The agent fills the gap with a plausible guess and ships "a confident, well-tested implementation of the wrong thing."

Evidence, as he cites it

• DORA 2025 calls AI "an amplifier" of an organization's existing strengths and weaknesses. Returns come from the surrounding system, not the tool.
• DX reports AI speeds output, not innovation.
• His read: if code were the product, more code faster would be good. It's an intermediate artifact whose value depends on design quality, feedback speed, and architecture.
• Metrics. Warp measures the share of changes shipped automatically. West calls that the factory's measure of success, not the customer's. Output counts get less useful as agents produce more. The real questions stay the same: is the product better, are customers getting more value, did risk drop, is the org learning faster.

Where factories do fit

• Builds, environment setup, test runs, dependency upgrades, routine migrations, formatting, static analysis, some remediation. Work where the design question is already answered.
• The SEI's DevSecOps value-stream work splits software into discovery-oriented and production-oriented activities. Build factories for the second kind and don't mistake that for the whole job.
• Warp itself says throughput is bounded by defining intent, reviewing traces, and approving releases. West: that bottleneck is the design loop.

Agents as design collaborators

• Agents make candidate designs cheap: hypothesize, implement, test, revise, repeat.
• What stays scarce: domain understanding, clear intent, architecture, trade-offs, verification, and whether it solves the customer's problem. A factory model pushes these to the edges as "input" and "quality gate."
• Use agents to explore a codebase, challenge a requirement, prototype two designs and compare. A ticket-to-PR worker leaves that unused.
• Better questions than "how do we keep agents fed": how fast can we turn an assumption into evidence, how cheaply can we try alternatives, how soon do we learn we were wrong.
• Closing line: use agents "to do design engineering at machine speed."

Patterns

• a label carries a theory of the work, which steers management moves ← "not an innocent label"
• check which step is truly expensive before importing another field's process ← "we had misidentified which part"
• treat requirements as hypotheses to test, not inputs to process ← "requirements behave like hypotheses rather than raw materials"
• in design work, variation between attempts is the value ← "Design depends on variation."
• keeping a queue fed forces precision before the knowledge exists ← "earlier than the knowledge supports"
• a tool amplifies the existing system, strengths and weaknesses alike ← "magnifying an organisation's existing strengths and weaknesses"
• an output count gets worse as a proxy as output gets cheap ← "a more dangerous proxy for productivity"
• automate the parts whose design question is already answered ← "the design question has largely been answered"