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

Summary

• Lloyd’s software factory is a distinct infrastructure layer for managing agentic development across a company. The unit is “one factory per product surface,” with repositories, skills, integrations, and workflows defined in code. Centralized traces make performance measurable, while pluggable compute, inference, and harnesses let companies change components without rebuilding the system.
• Warp reports cutting cost per PR from about $80 to roughly $15–$20 while increasing PR throughput 40% over the last month, without a higher revert rate. Lloyd attributes the savings to using a less expensive model for triage rather than Opus, and reducing redundant agent work and excess sub-agents. His operating rule is “observe, measure, tune.”
• Private benchmarks turn model selection into a measurable cost and correctness trade-off. Lloyd’s example puts GPT-5.6 Sol at 95% correctness and about $6 per task against GLM-5.3 Flash at 93% and $2; the displayed models were already slightly older. Testing harnesses alongside models supports routing specific to each company’s workflows, moving beyond “the realm of vibes.”
• Factories defined in code let agents propose improvements to the production system itself. Warp’s self-improvement agents identified 54 triage failures where investigative sub-agents would have helped and proposed a configuration change. Replaying historical runs to validate suggested improvements remains planned: “we don’t have this yet.”
• The clearest customer is a growing engineering organization with enough shared work to justify a platform. Lloyd tentatively places the floor around 5–10 engineers and describes potentially straightforward adoption for 10–100-engineer companies using common integrations. For a few people, his advice is “Don’t do this”; companies with bespoke infrastructure, such as Uber or Ramp, present a different obstacle because they build their own systems.
• Subscription subsidies make the pure coding-agent business difficult, in Lloyd’s view. Swyx describes API billing as 5–50× more expensive and cites $8,000 of API-equivalent usage for a $200 subscription. Lloyd says subscriptions can be cheapest “if you can do that,” but does not know whether rotating subscriptions is allowed; Warp’s commercial pitch centers on optimization and productivity rather than a “token reselling product.”

Deep dive

1. A software factory becomes concrete when its workflow is code

• Lloyd defines a software factory as a cloud agent system with explicit roles, some autonomy, and a process teams can “tune, measure, benchmark.” His objection to stringing arbitrary automations together is that nothing concrete can be evaluated. Warp’s unit is “one factory per product surface”: a mobile app or server application, its repositories, skills, MCP integrations, and workflow stages such as triage, speccing, and implementation.
• The Terraform analogy explains the foundation: declare the workflow in YAML and source control provides versions, branches to test, and changes to revert. Coding agents can then propose changes to the factory itself. The configuration becomes the object through which the production process can improve.
• The resulting division of labor separates product engineers shipping features through the factory from factory engineers improving how it works. Lloyd describes the latter as “engineering the system that builds the software.” The operational dashboard primarily serves platform or DevEx teams, engineering managers, and CTOs, rather than the typical engineer’s daily interface.

2. Shared traces make agent quality and economics measurable

• Centralization matters because a task can begin in Slack, continue in Linear, acquire a GitHub review, merge, and later cause a server crash. Keeping conversations, tool interactions, artifacts, and computer-use screenshots together lets an agent or person trace the failure backward. Individually running Claude Code or Codex locally generally leaves companies without that shared record, Lloyd says.
• The measurement layer combines DORA-style delivery metrics, throughput, cost, and human interventions per merged PR. Cost needs to be sliced by person, automation, and SDLC stage so teams can identify where different models or skills would lower cost per PR. Lloyd’s target is leaving “the realm of vibes” for measurement.
• Scorers combine default checks with company-defined failure modes, using an LLM judge, a grading prompt, and a sampling rate to manage evaluation cost. The concrete failure: agents write unnecessary tests while figuring out an implementation, then leave them behind, bloating the repository and wasting tokens. On the scoring capabilities, Lloyd acknowledges, “We have work to do on this.”
• Benchmarks replay curated company tasks across models and harnesses, including Warp’s, Claude Code, Codex, and Pi. In the demonstrated, already slightly older results, GPT-5.6 Sol achieved 95% correctness at roughly $6 per task; GLM-5.3 Flash achieved 93% at $2. Those trade-offs can inform model or harness routing specific to the company’s workflows and codebase.

3. Self-improvement produces proposals before it proves improvements

• Self-improvement agents inspect scoring failures and propose changes to the factory definition. One identified 54 triage failures where spawning an investigative sub-agent would have helped. Because the factory is code, the agent can submit a pull request against that configuration: the improvement proposal becomes a reviewable software change.
• The replay step remains unfinished. Lloyd wants to run historical tasks against each suggested change and check whether it actually would have improved them, but says, “we don’t have this yet.” Generating an improvement proposal and demonstrating that it improves past failures remain separate capabilities.
• Warp’s own tuning took cost per PR from about $80 to “twenty bucks or fifteen bucks, something like that.” Lloyd cites using Opus for triage when it was unnecessary, redundant work from the agents’ configuration, and using too many sub-agents instead of fewer as sources of waste. PR throughput rose 40% over the last month while the measured revert rate did not rise, reinforcing his confidence in “observe, measure, tune.”

4. The infrastructure stays modular and enters through existing tools

• The orchestrator is one layer, Lloyd argues, rather than the entire platform: it executes the declared stages, calls models, loads skills, and fires automations. The surrounding infrastructure also needs data access and organizational permissions, including different MCP access for marketing, sales, and engineering.
• Compute should be replaceable. Warp primarily uses Namespace, but Lloyd would make sandbox providers pluggable, naming Daytona, Modal, and E2B. Linux is the likely default; testing iOS apps needs a Mac VM running the simulator and clicking around. The platform must accommodate the environment the task requires.
• Inference and harnesses should also remain open. Companies may already have spending commitments with Anthropic, OpenAI, or Google to consume, so Warp lets them supply inference or buy it through Warp. It also supports external harnesses, including Pi and other ACP-compatible options.
• The access layer follows existing work habits: about 60% of Warp’s work starts in Slack, but tasks can enter through a tracker, GitHub, API, or MCP. An engineer can develop a spec in Claude Code locally, then submit it. Lloyd’s design is “headless infrastructure” that can receive crash alerts or customer feedback and loop in teammates who know the relevant code.

5. Team scale and inference subsidies determine the commercial fit

• Swyx’s pushback is practical: does a B2B SaaS CTO need all these layers? For a few people, Lloyd’s answer is “Don’t do this” and use Claude Code or Codex subscriptions. He puts the possible floor around 5–10 engineers, with 10–100-engineer growth companies potentially getting a fairly self-serve setup on the “happy stack” of Slack, Linear, or Jira.
• Scale also brings integration costs: larger organizations should not expect a purely plug-and-play deployment. Companies with very bespoke infrastructure and substantial internal developer teams, such as Uber or Ramp, are poor fits for Warp’s offering because they are building their own systems. Lloyd’s broader prediction is that most companies will have infrastructure like this, sitting one level behind CI/CD.
• Subscription subsidies complicate the economics. Swyx says API billing can be 5–50× more expensive and compares a $200 plan with $8,000 of API usage; he mentions people rotating 17 subscriptions. Lloyd calls subscriptions cheapest “if you can do that,” but says, “I can’t imagine that’s allowed,” and “I just don’t really know.” He also says the approach will not scale.
• Lloyd wants Warp outside the “pure coding agent business”: an independent agent cannot compete if its underlying inference costs much more. Of Cursor, he says, “I think that they had a perfect exit and became a model lab.” Warp’s commercial pitch is a coding-agent optimization and productivity platform, avoiding the economics of a “token reselling product.”