Warp Just Turned Coding Agents Into an Assembly Line. The Job Shifts From Writing Code to Running the Factory.

On 18 August, Warp opened a closed beta of Factories, cloud infrastructure for what it calls a software factory: a repeatable pipeline where coding agents take a ticket and carry it through triage, a written spec, implementation, review, verification and monitoring. Work enters from Slack, Teams, Linear, Jira, GitHub, GitLab, a terminal or a schedule, and the result flows back to wherever it came from. Warp's CEO, Zach Lloyd, says factories already handle 30 to 35 percent of the company's own internal engineering tasks, and qualified organisations that join the closed beta start with 10,000 dollars of factory use for free.

What is actually new here

Individual coding agents are old news by 2026. A developer asking an agent to write a function, fix a bug or refactor a file has been ordinary for more than a year. What Factories adds is the assembly line around them. Each factory is defined in version-controlled configuration files, which means the pipeline itself, the stages, the checkpoints, the rules for what may pass and what must stop, is reviewed, diffed and changed exactly like code. The process is no longer tribal knowledge in a senior engineer's head; it is an artefact in the repository, with a history and an owner.

It is also model-agnostic in a way that matters. A single pipeline can run Claude Code at one stage, Codex at another, Cursor or an open-weight model at a third, and each stage picks the model that fits the task in front of it. The unit of work stops being a prompt and becomes a governed process that a fleet of agents moves through, with humans stationed at the checkpoints rather than typing at the keyboard. That is a genuine change in the shape of the work, not just its speed.

The economics hiding in each stage picking its own model

The per-stage model choice is easy to skim past, and it is where a lot of the value sits. Triaging a ticket, drafting a spec, writing the code, reviewing a diff and verifying a result are not equally hard, so they do not need equally expensive models. A cheap, fast model can triage and route; a stronger, pricier one can be reserved for the review and verification stages where a mistake is expensive. Run at volume, that difference is the gap between a bill that scales sanely and one that runs away, the same discipline we described in picking the cheapest model that clears the bar. A factory that lets every stage make that call independently is quietly a cost-control tool as much as a productivity one.

The human's job moves up a level

Here is the shift worth naming. When one engineer used one agent, the human still did the work, only faster. When a factory runs many agents through a defined pipeline, the human stops doing the tasks and starts running the line: designing the stages, setting the checkpoints, deciding what gets verified and what gets auto-merged, and reviewing the exceptions the pipeline flags. That is a promotion, and it is a different skill from writing code well. The bottleneck is no longer how fast a person can type. It is how clearly they can specify a task, how well they can gate it, and how reliably they can verify work that machines carried out, the same lesson we saw when building software from a prompt got cheap: the scarce skill moves from doing to directing.

Why the checkpoints matter more than the speed

It is tempting to read this as pure acceleration, a way to ship more, sooner. The more important detail is the verification stage and the human checkpoints around it. A fleet of agents moving quickly through a pipeline is only an asset if the pipeline can reliably catch what they get wrong, and getting things confidently wrong is precisely what capable agents do, as became very real this month when agents broke out of their test environments and acted on systems they should never have touched. Warp's answer, gates that you define and control, versioned and reviewable like the rest of the code, is the right shape for the problem. The value is not the agents going fast. It is the line staying trustworthy while they do, so that throughput does not quietly become a pile of plausible-looking mistakes.

What it does to a team

Put the 30 to 35 percent figure next to the structure and the implication is uncomfortable and interesting. If a third of routine engineering work moves onto a pipeline, a team does not simply get faster; it gets reshaped. Fewer hours go to writing the obvious code, and more go to designing pipelines, curating specs and reviewing exceptions. The most valuable person on the team stops being the fastest typist and becomes the one who can decompose a problem into stages a fleet can execute and checks a machine can be trusted to pass. It also introduces a new failure mode: a factory that produces more than its humans can meaningfully review is not leverage, it is risk at scale. The constraint shifts from how much can be produced to how much can be responsibly accepted.

What to actually do with it

For anyone tempted to stand up a factory, the useful moves are unglamorous. Start with a low-stakes pipeline where a wrong answer is cheap, dependency bumps, test scaffolding, documentation, not the payments code. Spend most of your effort on the two stages nobody demos: the spec, because a fleet is only as good as the instruction it is given, and the verification, because that is the stage that decides whether speed is safe. Treat the pipeline as a product with an owner, not a script someone set up once. And measure the thing that matters, which is not tasks completed but tasks completed and correctly verified, because the first number without the second is how automation quietly creates work instead of removing it.

The same shift is coming to the rest of the business

What Factories does for software, the enterprise stack is starting to do for operations. Microsoft, for instance, just gave Dynamics 365 an adaptive home for managing and monitoring fleets of ERP agents, the same idea aimed at finance and supply chain instead of pull requests. The pattern is consistent everywhere the work is being handed to agents: the person's job becomes designing the process, watching the fleet, and owning the exceptions. The factory runs the tasks. Running the factory well, deciding what it should build and proving it was built right, is the new craft, and it is a more durable one than the typing it replaces.