⚡️ The 2026 Software Factory Standard — Zach Lloyd, Warp.dev

The host introduces Zach Lloyd and Warp as an open-source-oriented “software factory” platform, noting that Lloyd’s AIE talk about factories has gone viral. Lloyd says companies are already trying to build internal factories, which he defines as cloud-based agentic systems that assign roles to agents across software development. A factory should have meaningful autonomy, but also be measurable and closed-loop: teams should be able to tune, benchmark, and gain confidence that agentic development is becoming more scalable and efficient.

Lloyd says companies often misunderstand factories as loose collections of automations or simply “using agents a lot.” Warp instead treats a factory as a concrete, runnable system defined in code, with its workflows, skills, MCP integrations, repositories, and orchestration specified explicitly. Each factory operates on a product surface such as a mobile or server application and has a workflow resembling the team’s existing process: triage, specification, implementation, and other stages. The factory definition can therefore be versioned, run, and measured rather than remaining a nebulous concept.

Lloyd describes two personas: product engineers who submit work and platform or engineering teams that operate the factory. Engineers can start work in Slack, Linear, Jira, GitHub, an API, or MCP; the system treats each request as a work item that launches a predefined workflow. Centralizing this work creates a full trace of agent conversations, screenshots, artifacts, and orchestration steps. Instead of engineers separately running Claude Code or Codex in local environments, a company can see how coding agents are working across every product with a factory.

Warp’s closed loop measures output through deployment-style metrics, automation rates, throughput, and cost. Lloyd says teams may track how long work takes, how often humans intervene before a pull request merges, and the cost per pull request, sliced by person, automation, or software-development stage. The platform also supports online evaluations, called scorers, for issues such as verbosity, efficiency, code quality, or workflow-specific failures. Warp provides generic scorers, while customers can define their own in code.

Lloyd gives redundant tests as an example of a scorer. Coding agents may create unnecessary tests while figuring out an implementation, leaving bloated code and consuming extra tokens. A customer chooses a judge model, supplies a judging prompt, selects which historical agent runs to evaluate, and sets a sampling rate to control cost. The resulting evaluations identify recurring failure modes across the team rather than merely judging one session. Those findings can then guide changes to prompts, skills, models, or workflow design.

Once the factory and its traces are stored as code and data, agents can inspect the evaluation results and propose improvements. Lloyd says Warp found 54 cases where its triage step would have worked better by spawning a sub-agent for investigation. A self-improvement agent can open a pull request against the factory definition to add that behavior. Warp does not yet replay every affected run automatically, but Lloyd says the next step is to test each proposed change against historical tasks to verify that it actually improves outcomes.

Warp lets teams curate historical coding-agent runs into benchmark suites, such as front-end tasks, and replay them across different models and harnesses. Lloyd argues that teams should vary both, comparing Warp’s harness with Claude Code, Codex, or Pi rather than treating the model as the only variable. Results resemble public benchmarks such as SWE-bench or Terminal-Bench but use the company’s own tasks, showing cost-versus-correctness tradeoffs. Those results can drive model or harness routing strategies written specifically for a company’s workflows and codebase.

Lloyd lays out a stack: declarative factory code; centralized agent conversations and artifacts; MCP and access-control layers; pluggable compute sandboxes such as Namespace, Daytona, Modal, or E2B; flexible inference providers and harnesses; an improvement layer; an orchestrator; and entry points through Slack, task trackers, terminals, APIs, and MCP. He says this is mainly for teams with scale, roughly five to ten engineers or more, not tiny groups that should use a subscription to Claude Code or Codex. Larger or highly bespoke organizations such as Uber or Ramp may need substantial implementation work.

Lloyd says small companies often rotate many coding-agent subscriptions because subscription plans can be five to fifty times cheaper than paying directly by API, though that approach is not scalable and sacrifices centralization. Warp instead focuses on optimizing agent productivity rather than reselling tokens. Internally, Warp reduced cost per pull request from about $80 to roughly $20 or $15 by changing models and agent structure; PR throughput rose 40% without an increase in revert rate. Lloyd’s upcoming talk will distinguish product engineering from factory engineering: building the system that builds software.