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

Watch the full show on YouTube: https://www.youtube.com/watch?v=LL0YmIyBKSU

• 0:00Speaker 00

  Hey, it's me again. I have heard a lot of positive feedback about our episode intros, so I'm gonna keep trying to do them as far as time allows. Today, we're gonna dive into Warp with Zach Lloyd. Zach has been working on Warp for a while, and it's pivoted into what it is today, which is basically the definitive software factory that is also open source. And he has this whole definition, I think, which has done really well. His talk at AIE has been going viral as one of the top talks of all time. And I think effectively, everyone is trying to set this up for themselves. They have a solution for you, but it's also kind of an open spec that is becoming table stakes for what you're gonna want.

• 0:43Speaker 00

  And I think you aren't gonna want a cloud, you're gonna want a control plane, you're gonna want all these basic security features and team features that you take for granted. So releasing this episode as part of a preview for AIE Code. AIE Code is the last AIE flagship of the year. It's gonna be in San Francisco, where we're gathering all the top agentic engineers and talking about software factories, among other things. System one models, Diogo is coming back and raising your ambitions. So Tariq and Jason and Brandon from ArtCraft is doing his first conference talk ever. So if you're interested, Zach will also be giving a great keynote

• 1:24Speaker 00

  on software factories and sort of recapping the year and previewing what's next. Join us, and it'll be lots of fun. See ya.

• 1:35Speaker 00

  We're in the remote studio, catching up with Zach Lloyd from Warp. Welcome.

• 1:38Speaker 01

  Good to be here. Thanks for having me.

• 1:40Speaker 00

  Zach, you've been going viral on AIE. What's up? What's the... You've hit a nerve. You've hit a nerve.

• 1:45Speaker 01

  People are really interested in software factories. And that is an area that I've been focusing on, that Warp has been focusing on. I think we have some strong, kind of 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... People have been into it.

• 2:06Speaker 00

  Your H1 on the landing page says, "Open infrastructure for cloud software factories." I think maybe if, since you spend more time than I do talking about, telling people about factories, what do people think is a software factory? And what do they actually need?

• 2:23Speaker 01

  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 I think it means, or maybe I'll just define what it means to me, is like an 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. 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.

• 3:08Speaker 00

  And what do people come to you with that perhaps is a common misconception, right? Like, they're like, "Okay, if I do whatever, if I buy whatever, I'm gonna come out the other end with like this amazing money machine."

• 3:21Speaker 01

  Yeah, 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. Sometimes people are conceiving of software factories as just like, just like 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." And what we try 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. 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.

• 4:06Speaker 01

  Because people have all sorts of kind of random ideas around what these factories are. And so for Warp Factories, which is our platform, it's like, well, we say, "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, it's a collection of like arbitrary automations and interactive agents into a thing that's an actual... The way to think about a software factory, or the way that we think about it, what you're looking at here is Warp's software factory platform, is a factory operates on some 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,

• 4:51Speaker 01

  and has a set of skills it needs, a set of MCPs. And then it has like a workflow associated with it. And this workflow, you know, roughly matches what, you know, your team is probably already doing to make changes to that codebase. So there could be a step where you're doing triage. It could be where you're doing specking, implementation. The important thing is like, there's some kind of defined workflow, and that that workflow itself is defined 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 the MCPs, all of the integrations that are hooked up." So you basically have this whole thing defined someplace.

• 5:35Speaker 01

  The way to think about using the factory is that there's actually sort of two personas. So there's someone who is building the product. They're doing product engineering. They're shipping features through a factory. And for those people, the way they use the factory are 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. 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. Does that make sense so far?

• 6:20Speaker 00

  I love defining things in code.

• 6:22Speaker 01

  Yes. So, okay, so you have this whole thing set up in code. And then, once you have that in place, and so the, again, metaphor is like someone starts a task in Slack, or in Linear, or through an automation, like, you know, there's a server error. It all goes through one system is the kind of key thing. And once you have that working, you basically get a whole bunch of benefits that flow out of it. 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.

• 7:04Speaker 01

  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 in all of the work that is being done by coding agents across your 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. And so, for instance, just to look at one of these agent traces, Sofic is working on our mobile app here. Sofic was doing this in Slack, so I could pull this up in Slack if I wanted to. But like, the thing is actually generating, it has a full record of the conversation,

• 7:48Speaker 01

  has a full record of all of the, these are computer use screenshots that are coming out of building this thing. 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. So, on your team today, 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. But they wanna get to a world where they have this centralization. When you have the centralization,

• 8:30Speaker 01

  you can basically get all this interesting data on how your agentic coding is working across your company. And you could think of this data along different dimensions. So you could think of this data as like, "Okay, what's our team's output in the world of using coding agents?" 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? 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,

• 9:14Speaker 01

  the right skills, to basically bring this cost per PR down by time. You wanna be able to slice the cost by person. You wanna be able to slice it by automation, by where in the SDLC are you spending money? The final thing 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. And so, you can think of this as like online evals, or we call it scores. And these can go from very general things. So like, are your agents being too verbose? Are they being efficient? Is the code quality good? We have work to do on this.

• 9:54Speaker 00

  Do I as a user define this or do you provide this as a platform?

• 9:58Speaker 01

  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 changed? It is like breaking our build. They may want something, you know, very specific to their workflow. 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,

• 10:39Speaker 01

  you know, when I say runs, I mean like historical agent conversations that have been stored that an agent then goes and like retroactively grades. And so this is a good example of one where it's grading for redundant tests, which is like, this is a common failure mode for using coding agents. 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. And so, you know, say you wanted to check for that, you, you know, you basically create one of these evals. And just to show you like a little more about what the eval looks like, the eval is again, think of it as LLM as a judge. So you're picking a judge model. You're, you're then seeing, okay, like where do these run?

• 11:24Speaker 01

  What's the prompt for judging it? 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 of these smart agents that are looking across your team as how, 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? 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. So far, so good. Cause I want to show a couple of other things just to like, make it more specific, what you can do with this.

• 12:05Speaker 00

  Overall, good. I'm, I'm a little bit wondering if this, if basically there's different levels of, of Warp, where there is like, this is the CTO level, what you're showing us, right? This, you're, you're running the company, you've got a bunch of coders.

• 12:20Speaker 01

  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. 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. So what I'm showing you here, yeah, is like the toolset that they are using to be like, how do we get the most out of Claude code at our company or Codex or something like that?

• 12:51Speaker 00

  That, that part is clear.

• 12:53Speaker 01

  Yep, cool. Yeah. And so like a couple of other things that I would just want to 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 want to 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. You should use this new harness. What's better? Is it Pi or Claude code or, you know, Cursor or whatever?

• 13:38Speaker 01

  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. And so we think that this is the direction that companies are going to want to go. They're, they're going to want to 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. I guess one other thing I like to kind of 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 a different trigger-based ways of putting work into the factory.

• 14:23Speaker 01

  Once you have this view that I showed earlier of, uh, like scoring, how your factory is doing, you can also set up another kind of loop of agents, and everything is kind of 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. 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 54 failure cases of this particular

• 15:08Speaker 01

  form where it would have been better if our triager had been able to spawn a sub-agent to do its investigation. And so what they're able to do, and like, you could go look at like Wyatt 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. And so this is like, 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,

• 15:51Speaker 01

  replay the runs and make sure that this actually would have improved them. So the possibilities of like how you can engineer this stuff get pretty cool. Once you have the right primitives in place. And I'll show one last thing, and then we could sort of maybe talk more generally about the whole approach here. 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. 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.

• 16:37Speaker 01

  And then once you have that, you have the ability to sort of replay those same tasks against a matrix of different 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, Warp, we have our own harness, but we actually will let you benchmark against Claude code or Codex or Pi. 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 Sweetbench or Terminalbench, but on your company's own real runs.

• 17:18Speaker 01

  For instance, we're looking at like a sort of cost versus correctness trade-off for a certain set of things here. And like, you want to be in the upper left-hand corner, so you want like lowest cost, 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-5.6 Sol here was like 95% correct on this task set, but it costs six bucks on average. And GLM-5.3 Flash was 93% and cost two bucks. 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 codebase.

• 18:02Speaker 01

  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 to do this. 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. So that's like a quick tour of like, what do I mean when, when I talk about factory?

• 18:46Speaker 01

  I can, I can sort of stop talking for a sec.

• 18:49Speaker 00

  I do think that, you know, the, the power move, I guess, is to sort of thought lead so hard that everyone ends up trying to build Warp, even if they don't use Warp.

• 18:59Speaker 01

  Yeah.

• 19:00Speaker 00

  So, you know, you have on your landing page, something I like, and in your talks, you've done a few of these as well. Something I really like also is any surface, right? It really has to be any surface. It has to be factories' code. You have to have the eval loop, like what is the whole, like people are calling this the ADLC. I don't know if you use that term. It looks like you use SDLC still, you know, all that stuff.

• 19:23Speaker 01

  This is how I would think about it. Again, whether it's Warp or not, if it's, I would obviously, you know, Warp, Warp is, this is what we're fully focused on. We have an awesome platform for it, but just in general, what I would think about if you are trying to build something in this space is, AI would view it as like a stack, so as 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, you get the same benefits, but actually more. So the benefits you get from defining it as code is like, you get a versioned view of like, what was your, we, SDLC AI.

• 20:07Speaker 01

  DLC, PDLC, whatever DLC you want, you get a version 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. 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 to find your factory declaratively. 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.

• 20:50Speaker 01

  Cause what, what you want to 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, scientifically is the right word, but from a measurement standpoint, really optimize your system. 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.

• 21:31Speaker 01

  And there's a code review comment and that whole interaction is going to result in some piece of merged code. In fact, it might even result in something 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? 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. 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.

• 22:15Speaker 01

  And so like, again, you'll, you'll find there's a bunch of complexity for, 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 going to use a third party one, I would make, just make that pluggable. We use namespace as our primary one.

• 22:37Speaker 00

  Ooh, the last day of AI Europe.

• 22:40Speaker 01

  NameSpace is awesome, but this should be pluggable. I think that's really important. So if you wanted to use Daytona or Modal or E to B or whatever, like I would architect it. So this is a pluggable component of it. 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 want to use like a Linux type sandbox. But for computer use, like the way that we test like iOS apps is you're going to want to have the ability to run a Mac VM and actually like have it run the simulator and click around. 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.

• 23:20Speaker 01

  So we find that a lot of companies right now will have pre-existing commits with Anthropic or OpenAI or Google that they want to burn down. 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. 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 Pi, like I mentioned earlier. Basically any ACP compatible harness. 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.

• 24:02Speaker 01

  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. 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. 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 20 bucks or 15 bucks, something like that. Well, we can measurably improve the throughput of our PRs. Over the last month, it's gone up by 40%.

• 24:44Speaker 01

  We measure like the revert rate and it hasn't gone up. And so I really feel like a lot of confidence in this general approach of like observe, measure, tune. Finally, you, you need some sort of like orchestrator. 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. 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.

• 25:27Speaker 01

  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 60% of our work is starting in Slack. But sometimes it makes sense to start in the task tracker. 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. And so, you know, our philosophy is to try to, to make this whole thing API driven and MCP driven. So that the factory itself is like a piece of kind of headless infrastructure where it has all these different entry points.

• 26:08Speaker 01

  So I think this, this stack based view of it, when I've shown it, or we talked 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. It kind of sits one level back from like where C I C D is. But I think most companies will have something like this for software development.

• 26:29Speaker 00

  Yeah, that's a lot of layers, actually. I've never actually seen it spelled out like, like you have. I wonder, because I think most, you know, advise cognition and I've, I, you know, cursor, what, all these words, they all try to do some bundle of like the, like from bottom to top. And there's a little bit of bundling unbundling with all software. And so there's a critical question of like, look, I'm trying to do my job here as CTO of a, you know, B to B SaaS. Like I'm, do I need like all these like six layers?

• 27:02Speaker 01

  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. Like this is, if you're like a few people, honestly, this is, this is overkill. Don't do this. Use the Claude code sub or the codec sub or whatever. And just you'll go faster. You probably don't need, you could use this. Yeah.

• 27:30Speaker 00

  Same for like any like larger team stack, right? Like you, at some point you switch from like fire Yolo, whatever to, we actually need a platform system here to accelerate everyone.

• 27:41Speaker 01

  Exactly. Yeah. So you have to be a certain scale. We start seeing that maybe around like five to 10 engineers would maybe be the floor where this makes sense. And then all the way up to, to very large companies, they want something like this. The bigger the company, the more that this requires, you know, implementation work. Like I'm sure if you're, you know, you're working with cognition or, or I don't know if comments cursor does, but you know, to get something stood up like this within a company's own infrastructure, it's not going to be purely plug and play. There's like, you know, the sort of complexity of a team's internal developer setup just grows with size.

• 28:21Speaker 01

  Within like, but there's a bunch of companies where, you know, maybe like, it's like a 10 to 100 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.

• 28:39Speaker 00

  Hang on, did you call it the happy stack?

• 28:40Speaker 01

  I call 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 a, 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. I don't know if you, how much you're working like this, but if you're working with like Devon or something, you can kind of 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,

• 29:24Speaker 01

  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. 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 us, for a small team. And it really makes the most sense for a company that's like, I want to, I want to put in place the right infrastructure so that as models and agents continue to change, we have a system that we're building upon.

• 30:00Speaker 00

  There's a lot to go on here. The, the, one follow, one follow up question, and then I'm going to have you plug your AI talks and just generally where to, where to follow up with you. If you, what is the most steel man criticism of setting up all this? Like when you encounter criticism or pushback, what should people know as like, here, here is like what people are running into?

• 30:24Speaker 01

  I'll answer this in like, there's a certain class of customer where I don't think it makes sense to like, go on to this particular thing. And that's like,

• 30:32Speaker 00

  and beyond the size thing. Yeah.

• 30:34Speaker 01

  Where we have challenges right now are companies with very, very bespoke infrastructure or companies with, uh, like are, are kind of not a good fit customer for this. For instance, it would be like Uber or Ramp, 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, for some people they should, it's just going to be more economical to just use the subs. Like for small, very small teams, that comes back to the size thing.

• 31:06Speaker 00

  Actually, yeah, I don't want to actually omit the subs stuff because I think a lot of, a lot of people go straight to API, pay by API, and that is between five to 50 times more expensive than just getting a whole bunch of subs. Do people do that? Is, is that like so against terms of service that like just don't bother or like?

• 31:29Speaker 01

  Talk to like a lot of small companies we talked to where they're like, oh, this system seems amazing. We want this, but we're on these like collection of $200 subs that we're rotating through. I'm like, it's probably not.

• 31:43Speaker 00

  Like 17 different subs, right?

• 31:45Speaker 01

  And then you 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, 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 going to be allowed to do that, but it's like, it, it makes sense.

• 32:10Speaker 00

  Yeah, I'm just, you know, I'm just saying like it, it, that's the extent of subsidy. Like you get, uh, for like a $200 plan, you get 8,000 of API, right?

• 32:18Speaker 01

  Yeah, it's crazy.

• 32:19Speaker 00

  That's not, that's not money to sneeze at.

• 32:21Speaker 01

  No, I don't know. And it's like, it's one of the, I mean, just from like a business perspective, it's one of the reasons that, you know, I, I don't want to be in like the pure coding agent business because you, you just can't build.

• 32:34Speaker 00

  Good luck, good luck fighting.

• 32:35Speaker 01

  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. I mean, Cursor was brilliant. They did it. And then I think that they had a perfect exit and became a model app because I think they fully realized the economics of it. And so, yeah, the, the cool thing about Warp Factory is like, we're actually not, we're not trying to pitch like a token reselling product. We're trying to pitch basically in, uh, you know, a coding agent optimization platform and a coding agent like productivity platform. So we were, 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.

• 33:20Speaker 00

  It's basically cognition and open code. That's it. Oh, and, and factory, of course. Let's wrap up with like a little plug for your talk. People will come see you and we'll, we'll live stream it and all that. But do you give us a general arc of the, the sort of series that you've been developing and where, where you, where you're going to talk about next?

• 33:37Speaker 01

  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, 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 want to use the word of factory engineering? Actually look like, 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?

• 34:06Speaker 00

  That is a perfect recap and overview of if people want to talk to you, uh, where should they find you? If you're hiring, what are you hiring for? Anything that's a good call to action?

• 34:17Speaker 01

  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. If you're interested in like my, my musings on factories, I, I put out a lot of content on my Twitter now. So Zach Lloyd tweets, uh, so come, come follow that. And I'll keep sharing how I'm thinking about it.

• 34:39Speaker 00

  We'll do, we'll do. All right. Thanks so much for the talk.

• 34:42Speaker 01

  Cool. Thanks for having me.