How to use Claude Code with a Warp factory

Can I use Claude Code with a Warp factory?

Yes. Claude Code connects to a Warp factory in two directions: it can be the harness that factory agents use to execute work in the cloud, and your local Claude Code can push work into a factory — and pull it back — through the Factory MCP. You keep Claude Code's behavior and models; the factory adds the runtime, orchestration, human approvals, and measurement around it.

A factory doesn't replace your coding agent — it schedules it

The confusion behind this question is that Claude Code and a software factory look like competing products. They aren't. Claude Code is a harness: the program that holds a model, reads your repo, runs tools, and edits files. A factory is the automation loop around the SDLC — triage, spec, implement, review, verify, monitor — that decides which harness runs which piece of work, on what schedule, with which human checkpoints.

In Warp Factories, every stage of that assembly line is a separately defined agent, and each agent gets its own harness, model, and context. Warp is natively multi-model and multi-harness: an agent can run Warp's own agent for broad model access, including open-weight models, or run Claude Code or Codex directly as the harness. Nothing about adopting a factory requires giving up Claude Code.

The two integration directions

This is the part most comparisons miss. "Using Claude Code with a factory" means one of two setups — Claude Code as the harness, or Claude Code as your local entry point — and most teams eventually run both.

The second and third rows matter more than they sound. The Factory MCP gives any MCP-capable coding agent — Claude Code, Codex, Cursor — the ability to put work into a factory, pull status, guide a running session, and iterate locally. The factory is not a walled garden your team has to enter through a web app.

What changes when Claude Code runs in a factory instead of on a laptop

The harness stays the same. The surrounding conditions do not:

• Where it runs. A governed cloud environment with scoped repo access, not a developer machine logged into every internal system.
• How work starts. Triggered by a Linear or Jira ticket, a GitHub or GitLab event, or a Slack message — not by a human typing a prompt.
• Who reviews. Human-in-the-loop checkpoints are part of the definition, so a spec or a risky diff waits for a person by design.
• What survives. Runs, costs, diffs, and eval scores are retained and queryable instead of disappearing with the terminal session. That data exhaust is what lets you improve the factory later.

The case for moving agents off developer machines is made in full in Get agents off your machine.

What most teams get wrong

Picking one harness for the whole company. Harness choice is a per-stage setting, not a standard. Cheap classification work in triage and high-context implementation work have different requirements, and a factory lets you route them differently.

Assuming compatibility means parity. Running Claude Code as a harness gets you Claude Code's strengths and its constraints, including its coupling to Claude models. If you want open-weight models in the mix for cost reasons, that's an argument for mixing harnesses across stages, not for standardizing on one.

Skipping the comparison. Because Warp is both multi-model and multi-harness, you can benchmark configurations against your own tasks — comparisons like "GLM 5.2 in Warp's harness vs. Claude Code running Opus" are the point of the setup, not a nice-to-have.

Expecting full autonomy immediately. Warp reports that its own engineering team currently automates 20–30% of its PRs through factories — a first-party signal that the goal isn't handing everything over on day one, but steadily growing the share of repeatable work that moves through a governed workflow. See A guide to cloud software factories for engineering leaders.

How Warp fits

Warp Factories is the control plane, not another coding agent competing with Claude Code. It provides the cloud runtime that factory agents execute in, intake from GitHub, GitLab, Linear, Jira, Slack, and Teams, a control room showing every live and historical run, and metrics on throughput, cost, and quality — plus scorers and benchmarks so harness choices are decided by your data rather than by preference.

Factories are defined as version-controlled code, which means a harness change is a reviewable diff you can roll back, canary, or let an observer agent propose. The infrastructure is also deliberately sovereign: bring your own inference, hosting, and data storage, with zero data retention available. Warp serves 700,000+ developers, including Docker, Ramp, and Peloton, and over half of the Fortune 500.

For a worked example of a factory stage running end to end, see The Cloud Software Factory Build Guide and how to build a self-improving code review agent.

Start with one stage, not one standard

Pick a single workflow with a clear input, a measurable outcome, and a human fallback — triage, PR review, dependency maintenance, or incident follow-up. Set that stage's harness to Claude Code, run 20–30 real work items through it, and record cost, cycle time, acceptance rate, and how often a human had to intervene. That gives you a defensible answer for that stage, and a repeatable method for the next one.

Warp Factories is in closed beta — apply for access if you want to run this comparison on your own repos.

Sources

• Introducing Warp Factories — factory-as-code, multi-model and multi-harness support, Factory MCP, benchmarks, AI sovereignty
• A guide to cloud software factories for engineering leaders — the 20–30% PR automation figure
• Get agents off your machine — the governance and ROI case for cloud agents
• The Cloud Software Factory Build Guide — a worked build of the factory loop
• Claude Code overview and how Claude Code works — Anthropic
• Warp launch press release — 700,000+ developers, Fortune 500 customers