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

“People are really interested in software factories, and that is a area that I've been focusing on, that Warp has been focusing on.”

Claim: Zach Lloyd says software factories are attracting substantial interest, and that he and Warp have focused on the area.

“I think we have some, you know, strong, kinda interesting takes on what a software factory actually is and what it means for being a software developer. So yeah, that's-- and that's...”

Claim: Zach Lloyd believes that he and Warp have strong, interesting perspectives on the definition of a software factory and its implications for software developers.

“When I talk to companies or developers, most of the world is trying to build some sort of internal software factory or set of software factories. What, what I think it means, or maybe I'll just define what it means to me, is like a agentic system in the cloud where you're defining what are the roles of various agents across building software for your team or for your product, and there's a certain amount of autonomy in that system.”

Claim: Zach Lloyd defines a software factory as a cloud-based agentic system that assigns agents roles in building software for a team or product and gives the system some autonomy.

“When I talk to companies or developers, most of the world is trying to build some sort of internal software factory or set of software factories. What, what I think it means, or maybe I'll just define what it means to me, is like a agentic system in the cloud where you're defining what are the roles of various agents across building software for your team or for your product, and there's a certain amount of autonomy in that system.”

Claim: Zach Lloyd says that most companies and developers he encounters are trying to build an internal software factory or multiple internal software factories.

“So it's like the agents can do things on their own. And that system, to me, should be something that's very measurable, very closed loop, which over time, you as a team can like tune, measure, benchmark, and just ultimately get confidence that as people switch to this way of doing agentic development, that they're doing it in the most scalable and efficient way.”

Claim: Zach Lloyd says agents in a software factory can perform actions autonomously.

“So it's like the agents can do things on their own. And that system, to me, should be something that's very measurable, very closed loop, which over time, you as a team can like tune, measure, benchmark, and just ultimately get confidence that as people switch to this way of doing agentic development, that they're doing it in the most scalable and efficient way.”

Claim: Zach Lloyd argues that a software factory should be measurable and closed-loop, enabling a team to tune and benchmark it over time and build confidence that agentic development is as scalable and efficient as possible.

“Yeah. So, so when people come to us and they're trying to build their own software factory, like often they'll be like stringing together different automations.”

Claim: Zach Lloyd says people building their own software factories often assemble them by connecting different automations.

“Sometimes people are conceiving of software factories as just like, just like a, not a, not a specific thing, but it's just like we're using agents a lot to ship software, and we're calling that our internal software factory.”

Claim: Zach Lloyd says some people use “software factory” to mean broadly using agents to ship software within their organization.

“And what we try to, to do to make that more concrete is be like, "No, no, no. You should actually think of a software factory as a very specific thing. Like, you should define your factory in code.”

Claim: Zach Lloyd argues that a software factory should be a concrete system defined in code.

“You should make sure that the factory has all the workflows, skills, MCPs." Everything is like, it's like a concrete thing that you should be able to run at some point in time and measure how it's doing.”

Claim: Zach Lloyd argues that a software factory should explicitly include its workflows, skills, and MCPs, and be runnable and measurable.

“'Cause people have all sorts of kinda random ideas around what these factories are, and so for, for Warp Factories, which is our platform, it's like, well, we say, "No, no, no, it's actually, it's a real thing. You can orchestrate it. You can measure it. You have one factory per product surface." And we try to like take it out of the realm of just being like this nebulous, uh, it's a collection of like arbitrary automations and interactive agents into a, a thing that's an actual w- The way to th-think about a software factory, or the way that we think about it, and what you're looking at here is, is Warp's software factory platform, is a factory operates on some product surface.”

Claim: Zach Lloyd says Warp Factories support orchestration and measurement, and that the intended setup is one factory per product surface.

“So imagine you're building like your mobile app or you're building, you know, your server app or whatever, and the factory itself is operating on a set of repos, and it has a set of skills it needs, it has a set of MCPs, and then it has like a, a workflow associated with it.”

Claim: Zach Lloyd describes a software factory as operating on a product surface and using its associated repositories, skills, MCPs, and workflow.

“And this workflow, you know, roughly matches what, you know, your team is probably already doing to make changes to that code base. So there could be a step where you're doing triage, it could be where you're doing speccing, implementation.”

Claim: Zach Lloyd says a software factory's workflow roughly follows the team's existing code-change process, which may include triage, specification, and implementation.

“The important thing is like there's some kinda defined workflow, and that that workflow itself is defined in code.”

Claim: Zach Lloyd argues that a software factory needs a defined workflow encoded in code.

“So for us, we basically have a YAML file which says, "Okay, these are all the repos that you can be using. These are all of the MCPs, all of the integrations that are hooked up."”

Claim: Zach Lloyd says Warp configures a factory in a YAML file that lists its available repositories, MCPs, and integrations.

“So you basically have this whole thing defined someplace. The way to think about using the factory is that there's actually sort of two personas.”

Claim: Zach Lloyd says software factories have two user personas.

“So there's someone who is building the product, they're doing product engineering, they're shipping features through a factory.”

Claim: Zach Lloyd identifies product engineers who build products and ship features through a software factory as one user persona.

“And for those people, the way they use the factory or the way that-- is through their existing tools. So they could be Slacking the factory to put work into it. They could be using a task tracker like Linear or Jira. They could be interacting with the factory through GitHub. They could be Calling it via API or MCP.”

Claim: Zach Lloyd says product engineers can submit work to a software factory through existing tools such as Slack, Linear, Jira, GitHub, an API, or MCP.

“And the metaphor is like you're putting a work item into the factory. And when it goes into the factory, that starts like a predefined workflow, and that workflow is defined in code.”

Claim: Zach Lloyd says submitting a work item to a software factory triggers a predefined workflow encoded in code.

“And so one of the big benefits is that wherever these agents are running, and you're sort of seeing a real-time view across Warp's internal team, how are we using our own factories, you get a full trace of what everyone is doing with coding agents across any product that has a factory for it.”

Claim: A centralized coding-agent system can provide a team with a full trace of agent activity across products using that system.

“And this is cool, not just for like, oh, I wanna see what people are doing, like, I wanna see what Sofic is doing, which is cool, but it also starts centralizing all of the agent conversations and agent artifacts and all of the work that are, is being done by coding agents across your team.”

Claim: Centralizing coding-agent conversations and artifacts consolidates the work performed by coding agents across a team.

“And so when I talk about like having a closed loop system, these agent conversations, these agent traces are like the key aspect of how this system improves.”

Claim: Agent conversations and traces are key inputs to improvement in a closed-loop coding-agent system.

“But like, the thing is actually generating, it has a full record of the conversation, it has a full record of all of the, these are computer use screenshots that are coming out of building this thing.”

Claim: A centralized coding-agent system can retain complete conversation records and computer-use screenshots produced during development work.

“You can see a full record of exactly what the different pieces of the orchestration agent were doing. And so you have this, but you have it not just for one thing, you have it for every single thing.”

Claim: The system can record the activity of each orchestration-agent component across all tasks, not merely a single task.

“So on your team today, what we-- when I talk to companies, for the most part, they don't have something like this because most of their engineers are like individually using Claude Code in their terminal or Codex, the Codex app or something like that in their own local setups.”

Claim: Most companies the speaker talks to lack centralized coding-agent visibility because their engineers typically use Claude Code or Codex individually in local environments.

“But they wanna get to a world where they have this centralization. When you have the centralization, you can basically get all this interesting data on how your agentic coding is working across your company.”

Claim: Centralizing coding-agent activity enables a company to gather organization-wide data on how agentic coding is performing.

“And so that's things like, you know, traditional DORA metrics. How long does it take to ship something? It's things like how automated are you? And so we have a sort of metric around like for every PR that gets merged, how many times did a human have to do something with it?”

Claim: One measure of coding-agent automation is the number of human interventions required per merged pull request.

“And so that's things like, you know, traditional DORA metrics. How long does it take to ship something? It's things like how automated are you? And so we have a sort of metric around like for every PR that gets merged, how many times did a human have to do something with it?”

Claim: Teams can assess coding-agent output using traditional DORA metrics, including time to ship.

“What's your throughput? It's metrics around cost. And so we're using this like constantly. And when we talk to companies, this cost thing is very, very important, where you wanna be able to tune your factory with the right models, the right skills to basically bring this cost per PR down by time.”

Claim: Teams should tune their coding-agent factory’s models and skills to lower cost per pull request over time.

“You wanna be able to slice the cost by person. You wanna be able to slice it by automation, by s- by where in the SDLC are you spending money.”

Claim: Coding-agent costs should be measurable by person, automation level, and software-development lifecycle stage.

“The final thing that's, that's really cool, once you have this sort of closed loop system going, is that you can actually look underneath the hood at how well your coding agents are doing along different dimensions.”

Claim: A closed-loop coding-agent system enables evaluation of agent performance across multiple dimensions.

“And so you can think of this as like online evals, or we call it scorers. And these can go from very general things, so like, are your agents being too verbose?”

Claim: Online evaluations, which the speaker calls scorers, can assess whether coding agents are excessively verbose.

“Are they being efficient? Is the code quality good? We have work to do on this.”

Claim: Coding-agent scorers can evaluate agent efficiency and code quality.

“Yeah, so both. So we provide out of the box a set of ones that we think are like generically useful. But then, you know, as we work with companies, you know, they may have specific failure modes for their agents that they're interested in tracking.”

Claim: Warp provides a default set of coding-agent scorers that it considers broadly useful.

“Yeah, so both. So we provide out of the box a set of ones that we think are like generically useful. But then, you know, as we work with companies, you know, they may have specific failure modes for their agents that they're interested in tracking. They may be like, "Hey, is the agent making a specific type of thing that is like change that is like breaking our build?" They may want something, you know, very specific to their workflow.”

Claim: Companies may want to track coding-agent failure modes that are specific to their agents or workflows.

“So again, this is all defined in code and all customizable. And what you do is like when you set up one of these, what's actually happening behind the scenes is that there's some set of runs that you, you...”

Claim: Coding-agent scorers are defined in code and can be customized.

“When I say runs, I mean like historical agent conversations that have been stored that an agent then goes and like retroactively grades.”

Claim: Coding-agent evaluations can retroactively grade stored historical agent conversations.

“And so this is a good example of one where it's grading for redundant tests, which is like a, this is a common failure mode for using coding agents.”

Claim: Coding agents commonly produce redundant tests as a failure mode.

“Like sometimes they write a bunch of tests that you don't need. They write it in the course of like figuring out how to like implement something, and then they leave it in the code. And so this like bloats your code base, it wastes tokens.”

Claim: Coding agents sometimes create unnecessary tests during implementation and leave them in the codebase.

“Like sometimes they write a bunch of tests that you don't need. They write it in the course of like figuring out how to like implement something, and then they leave it in the code. And so this like bloats your code base, it wastes tokens.”

Claim: Unnecessary tests left in a codebase increase its size and consume tokens.

“The eval is, again, think of it as LLM as a judge. So you're picking a, a judge model. You're, you're then seeing, okay, like where do these run? What's the prompt for judging it?”

Claim: The evaluation uses an LLM-as-a-judge design, with a selected judge model, execution location, and judging prompt.

“And then a sampling rate, because you might not, like these are agents that are running. You might, you gotta be wary of the cost of them. But when you have this set up, think of it then as like you have all these smart agents that are looking across your team as h- at how all your, your coding sessions are going, and they're saying, "Okay, sometimes there are agents that are writing too many tests," right?”

Claim: Coding-agent evaluators can identify cases where agents produce excessive tests.

“And then a sampling rate, because you might not, like these are agents that are running. You might, you gotta be wary of the cost of them. But when you have this set up, think of it then as like you have all these smart agents that are looking across your team as h- at how all your, your coding sessions are going, and they're saying, "Okay, sometimes there are agents that are writing too many tests," right?”

Claim: Coding-agent evaluations can use a sampling rate to manage the cost of running evaluator agents.

“And so you get this record and this understanding of where you should look to sort of improve the way that your team is using coding agents.”

Claim: Evaluation records can help a team identify where to improve its use of coding agents.

“This is like the, the people who use this, it's partly the engineering manager or the CTO, but it's also like very commonly like the platform team, but it's not your like day-to-day engineer typically.”

Claim: Warp's tool set is used by engineering managers or CTOs and commonly by platform teams, but typically not by day-to-day engineers.

“But like when we work with companies, you know, they'll often have an internal team that's been trying to like, it's like the DevX team or the platform team, and they're trying to figure out how to optimize coding agents.”

Claim: Companies often have an internal developer-experience or platform team that works on optimizing coding agents.

“So what I'm showing you here, yeah, is like the tool set that they are using to be like, how do we get the most out of Cloud Code at our company or Codex or something like that.”

Claim: The tool set being shown helps internal teams determine how to get the most out of coding agents such as Claude Code or Codex within their company.

“Yep. Cool. Yeah, and so like a, a couple other things that I would just wanna emphasize, not to make this just like completely about Warp Factories, but like the general principle here for anyone who's trying to build their internal factory, whether it's on Warp Factories or not, is like you wanna get to a spot where everything is sort of stored, everything is observable, everything is measurable, because that's when you can actually start to like apply engineering rigor to how you make coding agents better. You know, you probably, you see this on Twitter all the time. Everyone is always tweeting about like, "You should check out this new model.”

Claim: Companies building internal coding-agent factories should store, observe, and measure their operations to enable rigorous engineering of coding-agent improvements.

“You should use this new harness. What's better? Is it Pi or Cloud Code or, you know, Cursor or whatever." And so what our opinion on this is and what the, the world sort of needs is like out of the, the realm of vibes for understanding these coding agents and actually into the world of measurement.”

Claim: Coding-agent performance should be evaluated through measurement rather than informal impressions.

“And so we think that this is the direction that companies are gonna wanna go. They're, they're gonna wanna like put in place a system that's like Warp Factories, whether they actually use Warp Factories or they build their own, which collects all this information and provides all this way to see how your coding agents are doing.”

Claim: The speaker expects companies to adopt systems, either Warp Factories or in-house alternatives, that collect data and make coding-agent performance observable.

“I guess one of the things I like kinda take for granted that's part of this system is like you can create all these different automations around it. So like I, I mentioned people work in Slack, but people are also setting up, uh, different trigger-based ways of putting work into the factory.”

Claim: Companies can use trigger-based automations to route work into a coding-agent factory.

“Once you have this view that I showed earlier of, uh, like scoring how your factory is doing, you can also set up another kinda loop of agents, and everything is kinda loops these days, where those agents are looking over. They're looking for failures in your scores. Like they're looking for things that aren't going well and trying to suggest changes to your system to make it go better.”

Claim: Agents can analyze factory performance scores, find failures, and recommend system changes intended to improve performance.

“And so like a really simple example here, we call this self-improvement, is like, okay, our self-improvement agents were looking at how well our triage step was doing. So we have a triage step, and they're saying, "Okay, we have fifty-four failure cases of this particular form where it would have been better if our triager had been able to spawn a sub-agent to do its investigation."”

Claim: Warp's self-improvement agents identified 54 triage failure cases where enabling the triager to spawn an investigative sub-agent would have been preferable.

“And so what they're able to do, and like you could go look at like why it thinks this if you want, but the cool thing is like because you have your whole factory defined as code, and these are coding agents, they can essentially make a pull request against the factory definition to try to improve the factory itself.”

Claim: When a coding-agent factory is defined as code, coding agents can propose improvements to it by submitting pull requests against its definition.

“And so this is like a, like a full learning loop that's built into the system to try to actually self-optimize. And like we don't have this yet, but the next thing that we want to do with this is like, actually for any suggested change like this, you could go back, replay the runs, and make sure that this actually would have improved them.”

Claim: Warp's factory system has a learning loop intended for self-optimization, and the team wants to add replay-based validation of suggested changes, a capability they do not yet have.

“But the other thing that is, um, you know, I think companies should strive for that we find very useful internally is like the ability to actually do what we call benchmarking.”

Claim: Companies should aim to benchmark coding-agent systems; the speaker's company finds benchmarking useful internally.

“And so benchmarking in this context, in the factory context, means essentially the ability to like take any coding agent that's running your system, you can sort of add it to a benchmark suite, which means like, you know, you might curate a set of coding agent runs that were related to like doing front-end coding or something like that.”

Claim: Factory benchmarking can involve curating coding-agent runs for a task category, such as front-end coding, into a benchmark suite.

“And then once you have that, you have the ability to sort of replay those same tasks against a matrix of different configurations.”

Claim: A company can use a benchmark suite to replay identical tasks across multiple configurations.

“And so, you know, I'm a big believer in not just allowing you to vary the model, but also to vary the harness. And so, you know, in Warp we have our own harness, but we actually will let you benchmark against Cloud Code or Codex or Pi.”

Claim: The speaker favors benchmarking both models and agent harnesses, and says Warp supports comparisons with Cloud Code, Codex, and Pi in addition to its own harness.

“You can pick the model, and when you do something like this, what you end up getting is a result that looks very similar to like the published results for SWE-bench or Terminal-bench, but on your company's own real runs.”

Claim: A company can benchmark its coding agents on its own real runs and obtain results comparable in format to published SWE-bench or Terminal-bench results.

“For instance, we're looking at like a sort of cost versus, uh, correctness trade-off for a certain set of things here. And like you wanna be in the upper left-hand corner, so you want like lowest cost, highest correctness.”

Claim: In a cost-versus-correctness comparison, the preferred configuration has the lowest cost and highest correctness.

“These are, these models are now slightly older because the world's changing so fast. But the idea is basically, you know, we could see, okay, GPT five six Sol here was like ninety-five percent correct on this task set, but it costs six bucks on average, and GLM five three Flash was ninety-three percent and cost two bucks.”

Claim: In the speaker's example benchmark, GPT 5.6 Sol achieved 95% correctness at an average cost of $6, while GLM 5.3 Flash achieved 93% correctness at $2; the speaker cautioned that the models were already slightly outdated because the field was changing quickly.

“And then the cool thing about this is you can take this information and feed it into a model routing strategy or harness routing strategy, honestly, that's defined specifically for your own workflows and code base.”

Claim: Companies can use benchmark results to build model- or harness-routing strategies tailored to their own workflows and codebases.

“And so the, you know, if I had again to zoom out, the really big picture thing that I think is so cool and powerful here is like you're getting out of the realm of guessing, and you're getting into what we call factory engineering, where it's like you are Taking a real engineering mindset, you're like: "How do I-- We have this amazing new primitive of, of coding agents. How do I know as a team, as a company, that we're actually deploying them in the right way?" And so, you know, we're trying to build this infrastructure and tools for companies, uh, to do this.”

Claim: Factory engineering applies an engineering mindset and measurement rather than guesswork to determine how an organization should deploy coding agents.

“And, like, this approach is really, really resonating with a lot of companies that have been trying to build, you know, their own, their own versions of this.”

Claim: The speaker reports that many companies attempting to build their own factory systems have responded positively to the factory-engineering approach.

“This is how I would think about it. Again, whether it's Warp or not, if it's-- But obviously, you know, Warp, Warp is this is what we're fully focused on. We have an awesome platform for it.”

Claim: Warp is fully focused on the software-factory space and has a platform for building in it.

“But just in general, what I would think about if you are trying to build something in this space is, A, I would view it as like a stack, so as infrastructure.”

Claim: A software factory should be architected as a stack of infrastructure.

“At the bottom of the stack, I think it's really foundational and important that you define your factory declaratively as code. So again, the analogy is like Terraform here.”

Claim: A software factory's foundational layer should be defined declaratively as code, analogous to Terraform.

“You get the same benefits, but actually more. So the benefits you get if, from defining it as code is like you get a versioned view of like what was your week SDLC, AI, DLC, P-PDLC, whatever DLC you want.”

Claim: Defining a software factory as code provides a versioned view of its development lifecycle.

“You get a versioned view of that, and then you get the ability to create branches off it, which you can test. You get the ability, if you change it, to revert it, so all the obvious things about source control that are great.”

Claim: A versioned software-factory definition supports testable branches and reverting changes, providing source-control benefits.

“And then you get the added benefit that's extremely cool, where because it's in code, coding agents can suggest improvements to it. So to me, this is like the foundation of a self-improving software factory setup is define your factory declaratively.”

Claim: Declaratively defining the factory is the foundation of a self-improving software-factory system.

“And then you get the added benefit that's extremely cool, where because it's in code, coding agents can suggest improvements to it. So to me, this is like the foundation of a self-improving software factory setup is define your factory declaratively.”

Claim: Defining a software factory in code enables coding agents to suggest improvements to the factory.

“The next step up in this stack, as you think about architecting it, is someplace to gather all of the information that agents are producing.”

Claim: A software-factory stack should include a layer for collecting all information produced by agents.

“'Cause what, what you wanna be able to do is examine that information, look for failure modes, or replay those same past tasks with different variables to sort of, I don't know if scientifically is the right word, but from a measurement standpoint, really optimize your system.”

Claim: A software-factory system should use collected agent data to identify failure modes and replay past tasks with changed variables for measurement-based optimization.

“So that's the mindset. So you need the data to do that. You need the agent conversations, and you need the agent artifacts. You need a record of all of the interactions from all of the tools to get to a result.”

Claim: Optimizing a software-factory system requires data comprising agent conversations, agent artifacts, and records of all tool interactions leading to a result.

“So that's the mindset. So you need the data to do that. You need the agent conversations, and you need the agent artifacts. You need a record of all of the interactions from all of the tools to get to a result. And so what I mean by that is like you might have a, a factory conversation that starts in Slack and then continues into Linear and then continues into GitHub, and there's a code review comment, and that whole interaction is gonna result in some piece of m-merged code. In fact, it might even result in something that gets shipped and then has a server crash. And you want the ability to like retroactively go back with an agent most likely, but you could do it as a person and, and diagnose how could that have been better?”

Claim: When a software-factory workflow produces shipped software that later causes a server crash, the workflow should be retrospectively diagnosed—most likely with an agent—to identify how it could have been improved.

“And so what I mean by that is like you might have a, a factory conversation that starts in Slack and then continues into Linear and then continues into GitHub, and there's a code review comment, and that whole interaction is gonna result in some piece of m-merged code.”

Claim: A software-factory workflow may span Slack, Linear, and GitHub, include a code-review comment, and produce merged code.

“What was the failure in it? You also need, this part will seem fairly obvious, but you need a way of getting data into this system, so you need some way of plugging in MCPs.”

Claim: A software-factory system needs data-ingestion capabilities, including a way to connect MCPs.

“And then we find that as companies get bigger, they want different access for different parts of their organization. So they want things like what MCPs can the marketing team access versus the sales team versus the engineering team.”

Claim: Larger companies want MCP access differentiated by organizational group, such as marketing, sales, and engineering.

“And so like, again, you'll, you'll find there's a bunch of complexity if you're, depending on how big your organization is, if you're trying to roll something like this out. You really want a compute layer. You should think of that as a separate thing. And so there's, there's obviously a lot of agent sandbox providers at this point. So if you're gonna use a third-party one, I would make, just make that pluggable.”

Claim: A software-factory system should have a separate compute layer.

“And so like, again, you'll, you'll find there's a bunch of complexity if you're, depending on how big your organization is, if you're trying to roll something like this out. You really want a compute layer.”

Claim: Deploying a software-factory system can become complex depending on the size of the organization.

“You should think of that as a separate thing. And so there's, there's obviously a lot of agent sandbox providers at this point. So if you're gonna use a third-party one, I would make, just make that pluggable.”

Claim: Because many agent-sandbox providers exist, a software-factory compute layer should be pluggable when using a third-party provider.

“We use Namespace as our primary one. Um-”

Claim: Warp uses Namespace as its primary agent-sandbox provider.

“Namespace is awesome. But this should be pluggable. I think that's really important. So if you wanted to use Daytona or Modal or Eta B or whatever, like I would architect it, so this is a pluggable component of it.”

Claim: The speaker thinks Namespace should be architected as a pluggable component that supports different platform providers, including Daytona, Modal, and Eta B.

“I would make sure, depending on your requirements, that you can do different platforms. So again, by default, you know, I think you'll probably wanna use like a Linux type sandbox.”

Claim: The speaker thinks a software factory should support different platforms according to user requirements, with a Linux-type sandbox probably serving as the default.

“But for computer use, like the way that we test like iOS apps is you're gonna wanna have the ability to run a Mac VM and actually like have it run the simulator and click around.”

Claim: The speaker says computer-use infrastructure for tasks such as iOS app testing should support running a Mac virtual machine, launching the simulator, and clicking through it.

“We have a very open approach to inference, and this is like, this is very much with our ethos of trying to be super-duper flexible. So we find that a lot of companies right now will have preexisting commits with Anthropic or OpenAI or Google that they wanna burn down.”

Claim: The speaker says many companies have preexisting commitments with Anthropic, OpenAI, or Google that they want to burn down.

“We have a very open approach to inference, and this is like, this is very much with our ethos of trying to be super-duper flexible. So we find that a lot of companies right now will have preexisting commits with Anthropic or OpenAI or Google that they wanna burn down.”

Claim: Warp describes its inference approach as open and designed to be highly flexible.

“And so we're-- we provide like a, a very big variety of like, you can plug in your own inference provider, or you can buy inference through us.”

Claim: Warp offers customers the choice of connecting their own inference provider or buying inference through Warp.

“You can even plug in your own harness, which I think is a pretty big deal. So, you know, you, you can orchestrate things like Py, like I mentioned earlier, basically any ACP compatible harness.”

Claim: The speaker says users can connect their own harness to the system, including any ACP-compatible harness, and use it to orchestrate tools such as Py.

“And then you want this improvement layer. And so this is some of the stuff that I showed in the demo where it's like, uh, the real power of this whole system is, is the ability to improve it.”

Claim: The speaker argues that a software factory needs an improvement layer and that the system's central strength is its capacity for improvement.

“And so just to give some stats at Warp, when we first started using the factory approach, it was costing us about $80 per PR because we were using like Opus where we shouldn't have.”

Claim: Warp's initial use of the software-factory approach cost about $80 per pull request, partly because the team used Opus in cases where it was not appropriate.

“Our triage agent was using like a really high-powered model. You know, we were doing a bunch of redundant work with our, the shape of agents. Like we were doing too many sub-agents relative to just having fewer agents.”

Claim: Warp's initial agent configuration performed redundant work by using too many sub-agents rather than fewer agents.

“Our triage agent was using like a really high-powered model. You know, we were doing a bunch of redundant work with our, the shape of agents. Like we were doing too many sub-agents relative to just having fewer agents.”

Claim: Warp's triage agent initially used a very high-powered model.

“And so we basically did a whole bunch of internal tuning and testing using these built-in features, and we were able to get the cost per PR down to like twenty bucks or fifteen bucks, something like that. And so just to give some stats at Warp, when we first started using the factory approach, it was costing us about $80 per PR because we were using like Opus where we shouldn't have.”

Claim: Warp's internal tuning and testing with built-in features reduced its cost per pull request from about $80 to approximately $15–$20.

“Well, we can measurably improve the throughput of our PRs. Over the last month, it's gone up by forty percent. We measure like the revert rate, and it hasn't gone up.”

Claim: Warp reports that its pull-request throughput increased by 40% over the last month without an increase in its measured revert rate.

“And so I really feel like a lot of confidence in this general approach of like observe, measure, tune. Finally, you need some sort of like orchestrator.”

Claim: The speaker expresses confidence in an iterative approach of observing system performance, measuring it, and tuning the system.

“Sometimes people talk about the orchestrator like it's the whole platform. I think it's a piece of it. What I mean by orchestrator is like you need some system that will take the factory definition code and then actually move work along the different stages, calling out to the right models, loading the right skills, et cetera.”

Claim: The speaker defines a software-factory orchestrator as a system that executes factory-definition code to move work through stages, call the right models, and load the right skills.

“Sometimes people talk about the orchestrator like it's the whole platform. I think it's a piece of it. What I mean by orchestrator is like you need some system that will take the factory definition code and then actually move work along the different stages, calling out to the right models, loading the right skills, et cetera.”

Claim: The speaker views an orchestrator as one component of a software-factory platform rather than the whole platform.

“You need something that will fire the right automations. And then finally, you need a bunch of access points. And again, our philosophy with this, which you can-- I could see people have different philosophies.”

Claim: The speaker says a software-factory system needs to trigger the appropriate automations.

“Our philosophy is to sort of bring the factory into a company's existing knowledge work tools. So think of like, you know, the most obvious one is Slack, and like we're doing like sixty percent of our work is starting in Slack, but sometimes it makes sense to start in the task tracker.”

Claim: Warp aims to integrate its software factory into the knowledge-work tools a company already uses.

“Our philosophy is to sort of bring the factory into a company's existing knowledge work tools. So think of like, you know, the most obvious one is Slack, and like we're doing like sixty percent of our work is starting in Slack, but sometimes it makes sense to start in the task tracker.”

Claim: The speaker says approximately 60% of Warp's work begins in Slack.

“Our philosophy is to sort of bring the factory into a company's existing knowledge work tools. So think of like, you know, the most obvious one is Slack, and like we're doing like sixty percent of our work is starting in Slack, but sometimes it makes sense to start in the task tracker.”

Claim: The speaker says that starting work in a task tracker can sometimes be appropriate for the software factory.

“Sometimes it makes sense for, for a developer who is more comfortable using like Claude Code in their terminal to do a bunch of work there and then submit a spec into the factory.”

Claim: The speaker says developers who prefer Claude Code in a terminal can do work there and submit a specification to the software factory.

“And so, you know, our philosophy is to try to s- to make this whole thing API driven and MCP driven so that the factory itself is like a piece of kinda headless infrastructure where it has all these different entry points.”

Claim: Warp's philosophy is to make its software factory API- and MCP-driven headless infrastructure that supports multiple entry points.

“So I think this, this stack-based view of it, when I've shown it, or when we talk to companies, seems to land very well. It's like, okay, yes, this, this makes sense. This is a new thing in the like developer infrastructure stack.”

Claim: The speaker reports that companies respond positively to the stack-based view of the software factory, which he sees as a new part of the developer-infrastructure stack.

“It kinda sits one level back from like where CI/CD is, but I think most companies will have something like this for software development.”

Claim: The speaker places the software factory one level behind CI/CD in the developer stack and predicts that most companies will adopt something similar for software development.

“I think it's like, who's this for? Maybe is, is the kind of the question. So when we talk to companies that where this resonates the most is it has to be a company that has some, some amount of scale.”

Claim: The speaker says the software-factory approach is most relevant to companies that have reached a certain scale.

“Like this is if you're like a few people, honestly, this is, this is- ... overkill.”

Claim: The speaker considers a software-factory platform overkill for a company with only a few people.

“Don't do this. Use the Claude Code sub or the Codex sub or whatever, and just you'll go faster. You probably don't need.”

Claim: The speaker advises very small teams not to build a software-factory platform, saying they will probably move faster with a Claude Code or Codex subscription.

“Exactly. Yeah. So you have to be at a certain scale. We start seeing that maybe around like f- five to ten engineers would maybe be the floor where this makes sense.”

Claim: The speaker estimates that a team of roughly five to ten engineers may be the minimum size at which a software-factory platform makes sense.

“And then all the way up to, to very large companies, they want something like this. The bigger the company, the more the, this requires, you know, implementation work.”

Claim: The speaker says very large companies want software-factory systems, and that implementing them requires more work as company size increases.

“Like I'm sure if you're, you know, you're working with cognition or, or I don't know how much Cursor does, but, you know, to get something stood up like this within a company's own infrastructure, it's not gonna be purely plug and play.”

Claim: The speaker says deploying a software-factory system inside a company's own infrastructure requires more than a purely plug-and-play setup.

“There's like, you know, the sort of complexity of a team's internal developer setup just grows with size. Within like-- But there's a bunch of companies where, you know, maybe like it's like a ten to hundred engineers, fast-growing, like growth stage startup where it is pretty self-serve actually, where it's like you just if they're using like the happy stack of like Slack, you know, Linear, Jira.”

Claim: The speaker says a software-factory system can be fairly self-serve for some fast-growing companies with about 10–100 engineers, particularly when they use tools such as Slack, Linear, and Jira.

“There's like, you know, the sort of complexity of a team's internal developer setup just grows with size. Within like-- But there's a bunch of companies where, you know, maybe like it's like a ten to hundred engineers, fast-growing, like growth stage startup where it is pretty self-serve actually, where it's like you just if they're using like the happy stack of like Slack, you know, Linear, Jira.”

Claim: The speaker says the complexity of a team's internal developer setup grows with team size.

“I called it like, yeah, I-- that's like our I don't know, uh, no, no shade to, to Teams or whatever, like sure. But like there's like, uh, you know, like a set of integrations that I find very common at startups where you can plug something like this in and get like immediate, immediate value without too much setup.”

Claim: A common set of integrations used by startups can be connected to Warp Factories to provide immediate value with little setup.

“I don't know if you-- how much you're working like this, but if you're working with like Devin or something, you can kinda get some of the same experience where when you're working in a, some, an environment that's natively multiplayer, so like Slack for instance or Linear, there's all these benefits that you might not realize just by having like this central system of record where you can have, you know, for like the Slack integration, for instance, it's like you can get some flow of information coming in through like a server crash channel and some through a user feedback channel. You can just feed that directly into the factory to have it do the work. The factory can loop in multiple people on your team, depending on who knows the right part of the code base.”

Claim: A central system of record in a natively multiplayer environment such as Slack or Linear can route information from channels such as server-crash and user-feedback channels into a software factory.

“user feedback channel. You can just feed that directly into the factory to have it do the work. The factory can loop in multiple people on your team, depending on who knows the right part of the code base.”

Claim: A software factory can involve multiple team members based on who has knowledge of the relevant part of the codebase.

“And so, you know, I don't think you have to be that big for this, for this to make sense, but it definitely doesn't make sense for a s- for a small team, and it really makes the most sense for a company that's like, "I wanna, I wanna put in place the right infrastructure so that as models and agents continue to change, we have a system that we're building upon."”

Claim: Warp's factory approach is not suitable for small teams and is most suitable for companies seeking infrastructure that can support continued changes in models and agents.

“Where we have challenges right now are companies with very, very s-bespoke infrastructure or companies with, uh, like our, our kind of not a good fit customer for this, for instance, would be like Uber or Ramp.”

Claim: Companies with highly bespoke infrastructure, such as Uber or Ramp, are poor-fit customers for Warp's factory product.

“Like, they're building their own thing. They have very large internal developer teams. But apart from the size thing, I'm thinking like, I mean, there's definitely like the-- s- for some people, they should-- it's just gonna be more economical to just use the subs, like for small, very small teams.”

Claim: Uber and Ramp build their own systems and have very large internal developer teams.

“Like, they're building their own thing. They have very large internal developer teams. But apart from the size thing, I'm thinking like, I mean, there's definitely like the-- s- for some people, they should-- it's just gonna be more economical to just use the subs, like for small, very small teams.”

Claim: Using subscriptions may be more economical than the alternative for very small teams.

“I, I can't imagine that's allowed, but I, I don't-- the truth is I just don't really know. But like they, they are, and it's, it's like-- and it makes-- like honestly, it's like if you can do that, that's gonna be the cheapest way.”

Claim: The speaker is unsure whether rotating through many subscriptions is permitted, but says that if it is permitted, it is the cheapest way.

“But you, you, you do lose a whole bunch of other benefits if you do that, uh, and it's not a scalable thing, and if your company scales to a certain point, they're, you know-- you're definitely not gonna be allowed to do that.”

Claim: Rotating through many subscriptions sacrifices other benefits, does not scale, and will not be permitted once a company reaches a certain size.

“And it's like, it's one of the-- I, I mean, just from like a business perspective, it's one of the reasons that, you know, I, I don't wanna be in like the pure coding agent business because you, you just can't build a- You can't, you can't build a competitive coding agent on top of a thing that costs so much more money and like that's just the reality of it. I mean, Cursor was brilliant. They did it, and then I think that they had a perfect exit and became a model lab because I think they fully realized the economics of it.”

Claim: The speaker does not want to operate a pure coding-agent business because it is not possible to build a competitive coding agent on a substantially more expensive cost base than subscription-based alternatives.

“You can't, you can't build a competitive coding agent on top of a thing that costs so much more money and like that's just the reality of it. I mean, Cursor was brilliant. They did it, and then I think that they had a perfect exit and became a model lab because I think they fully realized the economics of it.”

Claim: The speaker believes Cursor executed brilliantly, achieved a perfect exit, and became a model lab after recognizing the economics of the coding-agent business.

“And so yeah, the, the cool thing about Warp Factories is like we're actually not, we're not trying to pitch like a token reselling product. We're trying to pitch basically an, uh, you know, a coding agent optimization platform and a coding agent like productivity platform.”

Claim: Warp Factories is a coding-agent optimization and productivity platform rather than a token-reselling product.

“So we we're, we're not in that game with this product, which is a strength. And like that game is-- I, I know there's still a few independent coding agents out there. I don't know how they're gonna, how they're gonna do it.”

Claim: The speaker is uncertain how the remaining independent coding-agent companies will succeed.

“What the talk's gonna focus on is what it looks like to be an engineer in this world of, uh, increasing factory engineering and like what i, what are, what are your roles? What's your job gonna be? What are the two types of engineering, product engineering, factory engineering? And then what is this new discipline, if you wanna use the word, of factory engineering actually look like?”

Claim: The speaker's talk will examine how engineering roles and jobs change as factory engineering increases, including the distinction between product engineering and factory engineering.

“What are the tools? How do you, as an engineer, build the right skills so that you're engineering the system that builds the software and not just building the software directly?”

Claim: The speaker's talk will discuss the tools and skills engineers need to develop systems that produce software instead of producing the software directly themselves.

“Yeah. So come check out warp.dev. So most stuff is there. Uh, we're hiring engineers. We're hiring on our go-to-market team. We're hiring on the data team. We're hiring a designer, so hiring up for a whole bunch of roles.”

Claim: Warp.dev is hiring for engineering, go-to-market, data, and design roles.

“If you're interested in like my, my musings on factories, I, I put out a lot of content on my Twitter now, so Zack Lloyd tweets. Uh, so come, come follow that, and I'll, I'll keep sharing how I'm thinking about it.”

Claim: Zach Lloyd shares content about his thinking on factories on Twitter.