The factory analogy has been floating around software engineering long enough that most people have stopped hearing it. Agile borrowed the assembly line. DevOps borrowed lean manufacturing. Every consulting firm has a slide with arrows and boxes showing how your pipeline resembles Toyota's. The problem with all of those comparisons is that the analogy always broke down at the same place: a human being had to write the code. The factory produced deliverables, but the craftsman still made the parts.

That constraint is dissolving, and the dissolving is happening fast enough that the architecture of what replaces it is worth understanding before you stumble into building it wrong.

The Loop, Laid Out

Zach Lloyd, founder of Warp and former Google principal engineer, describes a software factory not as an aspiration but as a closed loop with identifiable stages. The stages, in order, are: idea intake, agent-driven triage, spec generation (both product and technical), agent implementation, human and agent code review, automated verification, CI/CD, and production monitoring that feeds back into intake. Run it around again. That is the loop.

What makes this different from a standard engineering workflow diagram is that most of those stages are automated in the factory model, and the human appears at defined checkpoints rather than continuously throughout. Triage happens without a human deciding which issues deserve attention. Specs get written by an agent working from the triaged input. Implementation follows from the spec. Review is split: an agent does a first pass, a human reviews what the agent flags. Verification runs against the actual UI, not just the unit tests. The whole thing cycles back when production signals something worth addressing.

The human is not gone. The human is placed deliberately, at the points where judgment cannot be automated, and that placement is itself a design decision rather than a default.

What Warp Actually Built

Lloyd is not describing a future possibility. He is describing infrastructure Warp built to manage its own open-source project, and the use case is instructive because open-source repositories are, in practice, a stress test for exactly this kind of pipeline. The PR volume is high, the signal-to-noise ratio is low, contributors range from first-timers to longtime maintainers, and the maintainers are almost always busy with the product work that keeps the company alive. The traditional answer to open-source maintenance burden is either to hire dedicated developer relations staff or to let the queue grow until contributors notice that their PRs sit for weeks and stop submitting them.

Warp's answer was to automate the triage and initial response layers. An agent reads incoming issues and PRs, classifies them, drafts responses, and flags the cases that require a human opinion. The humans who remain in the loop are looking at a pre-sorted, pre-annotated queue rather than raw volume, which means their time goes toward decisions rather than sorting. The open-source case is close to ideal for a factory pattern because the accept/reject signals are relatively clear, the volume creates enough data to improve on, and the cost of a slow response is visible and real.

The Warp repo is public at github.com/warpdotdev/warp, and the infrastructure Lloyd describes managing it is built on top of it.

The Stage Most Implementations Skip

Here is where most early attempts at this pattern stall: they automate the stages and stop there, which produces a system that is faster than a human workflow but does not get better. The factory is automated but not self-improving, and those are not the same thing.

Lloyd identifies the data layer as the component that makes the difference. Beneath the pipeline, a memory substrate accumulates the record of what the agents did, what decisions humans made at the checkpoints, what got accepted and what got rejected. That record is what allows an agent running triage in month six to perform differently than the same agent running triage in month one, because it has a history of what the humans in this particular shop have consistently overruled, what classes of issues consistently get resolved in a certain way, and what the production feedback loop has surfaced as worth caring about.

Without that layer, every run through the factory is effectively the first run. The agents apply their base models, the humans correct the same errors again, and the gap between what the automation produces and what the team actually wants stays roughly constant. That gap, in a standard automated pipeline, is a cost center. In a factory with a functioning data layer, it is a training signal, and the distinction matters enormously as the loop accumulates volume.

Human Judgment as Architecture, Not Fallback

The factory model is easy to misread as a story about reducing human involvement. It is more precisely a story about locating human involvement correctly. The checkpoint function is not a concession to the limits of current AI; it is a design decision about which inputs require the kind of judgment that, at this point in time and perhaps for some time to come, an agent cannot reliably supply.

Lloyd is explicit about this in a way that is worth taking seriously: a factory producing things nobody wants has no value. Product taste, the ability to look at what the agents generated and recognize that it is technically correct but strategically wrong, is the judgment that the checkpoint exists to apply. The human at the review stage is not there to catch bugs, because the automated verification layer handles bugs. The human is there because the question of whether to ship this feature to these users in this form is not a question that reduces to code correctness.

What this means structurally is that the skill of knowing where to place the checkpoints is itself a form of systems thinking that most engineering teams have not had to develop explicitly. In the old model, humans were everywhere in the pipeline by default, so the question of where judgment was actually needed never had to be answered. The factory model forces the answer.

Where the Moat Goes

The competitive logic that follows from this architecture is uncomfortable for anyone whose product strategy rests on code complexity as a barrier. Lloyd's argument is that when building software gets cheap enough that cloning a product is a matter of weeks rather than years, the product itself cannot be the moat. The code is not the differentiator; the distribution, the ecosystem, the brand, and the data that the factory accumulates are the differentiators. This is not a new idea in strategy terms, but the factory model makes it newly urgent by compressing the timeline on which a competitor can reproduce what you built.

The data layer argument and the moat argument turn out to be the same argument from different angles. The factory that accumulates a rich record of decisions, outcomes, and corrections in a specific domain is building something that cannot be cloned cheaply, because the data is proprietary and the improvement it enables compounds over time. The factory that does not build that layer is producing software that is fast to generate and equally fast for a well-resourced competitor to replicate.

The Skill Shift

Lloyd closes with an observation about what this means for engineers, and it is worth sitting with rather than scanning past. Engineers will write less code, he argues, and ship more products. The volume inversion is real: the factory handles implementation, which means the engineer's time goes toward the stages that still require human input, which are the stages closest to the question of what to build and why.

Systems thinking and product judgment are not soft skills in this framing. They are the technical competencies that the factory model surfaces as the ones that matter, because they are the inputs that determine what the factory produces. An engineer who can design a good triage loop, write a spec that an agent can actually implement faithfully, and recognize at the review checkpoint when the output is wrong in a way that the automated tests cannot catch is, in the factory model, doing the highest-leverage work in the pipeline.

Adaptability matters for a different reason: the tooling is moving fast enough that the specific agents and integrations that make a factory work today will look dated inside two years. What transfers is the structural understanding of what the loop is supposed to do and where the human belongs in it.

The architecture Lloyd describes at Warp is worth examining directly rather than through a summary. The talk runs through the pipeline stages with enough specificity to map your own workflow onto them. The Warp repo is the artifact the infrastructure manages, public and examinable. If you are building or inheriting something that looks like a pipeline with humans scattered through it by habit rather than design, the question worth asking is not whether to automate more. The question is whether you know where the checkpoints should be, and whether you have built the data layer that lets the factory learn what your shop actually needs.