EPISODE 1941


[INTRODUCTION]


[0:00:00] ANNOUNCER: The terminal has been a constant in software development for decades. It has remained largely unchanged, while everything around it transformed. However, as AI agents have become central to the developer workflow, the terminal is emerging as a natural home for agentic development, and a new category of tooling is forming around it. Warp is a popular, Rust-based terminal and agentic development environment. The company recently open-sourced its codebase and launched Oz, its cloud agent infrastructure product, aimed at helping enterprises automate software development at scale. Zach Lloyd is the Co-Founder and CEO of Warp, and a former Principal Engineer at Google where he led engineering on the Google Doc Suite. In this episode, Zach joins Gregor Vand to discuss how Warp has evolved over the years, why the terminal is better suited than the IDE for agentic development, how Oz approaches the governance and auditability challenges enterprises face with AI agents and more.

Gregor Vand is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance, and general software engineering companies. He is based in Singapore and can be found via his profile at van.hk, or on LinkedIn.

[INTERVIEW]


[0:01:32] GV: Hello, and welcome to Software Engineering Daily. My guest today is Zach Lloyd, who's returning after four years. We've already had Zach on in 2022. Yeah, welcome, Zach.

[0:01:43] ZL: It's good to be here. Thanks for having me back.


[0:01:45] GV: Yeah. We're going to be talking all about Warp, which some of our listeners base will be quite familiar with, I think. Before we get into Warp itself, we normally go through a story of our guest. I suggest our listeners go back to the 2022 episode if you want to get the full version, but what's the TLDR how you ended building Warp?

[0:02:06] ZL: Yeah, so my background, I've been a software engineer for most of my career. I was at Google for a really long time. I helped build a lot of Google Sheets, and then I led engineering on the whole Google Doc Suite. I was a principal engineer there. I've been out of Google though for a while as well. I've been founding companies. Warp's my second venture- backed startup that I've done. First one, totally, totally different space. Pretty interesting learning experience. Fundamentally, I would say, I'm someone who I really, really like building stuff. It's really fun for me. My goal has been to build useful software, sometimes for knowledge workers, like with Google Docs. With Warp, I'm really trying to build something that's very useful for developers. Honestly, increasingly, since anyone can be a developer, it's really useful for a lot of knowledge workers as well. It's a crazy changing space to be in, but that's me in a nutshell.

[0:03:03] GV: Yeah, nice. I think, thinking about what you might have been talking about in the episode back in 2022, but I guess, back then the pitch was Warp was this of like, beautiful, fast, Rust-based terminal trying to bring command line into the 21st century, because command line hadn't really changed in many ways. Since then, a lot of things have happened, including your ARR has grown a ton and you've got open source, which we're going to get to and all sorts of things. Walk us through maybe the last four years, if you can, like a quick history.

[0:03:43] ZL: It's more than the Warp. It's not just the Warp has changed. I'd say, obviously, the world has changed. The world of what it is to be a software developer is just fundamentally different. I would say, the Warp journey is right, the way you described it. For folks who may be aren't familiar with Warp, we started off focused on just reimagining the experience of using the terminal. The concept was like, terminal is a really important app. It's where developers spend a lot of their time. The terminal and the code editor, I've always said, are the two most important developer apps. The terminal just hadn't had a lot of innovation, and so we tried to reimagine from first principles, what should a great command line experience be like?

I'm very proud of what we've built. A lot of people really love the command line. Like you said, it's Rust-based, has some very distinct features compared to a normal terminal. Our hero feature at the beginning was just the mouse worked to edit your terminal commands, which is way harder than it seems. You'll notice there are not a lot of terminals out there that have that. Even still, we have this feature where we separate the terminal outputs into blocks. It makes it

more readable. You can take actions on them. Those are the sorts of things that we started off focusing on.

We started adding features around AI into Warp pretty early on as well. I don't know if we had them when I spoke when I was on the pod last. But even before ChatGPT came out, we were using, it was called the Codex API at the time. It was through OpenAI. What we were using it for was we would translate English into terminal commands. It was really translation, not like a agentic capability. You would be like, give me the command for finding all Python files that are greater than a hundred lines in this directory, or something like that. You'd say that in English and we would translate it for you.

Then when ChatGPT came out, we realized very quickly like, oh, this is going to be very applicable to the command line. Because one of the big challenges of using the command line has always been that you just have to remember all these arcane commands. LLMs are great at helping people construct those commands. We brought in a chat panel in 2023 into Warp, but we realized that was actually a stupid implementation. The terminal itself is almost like a chat interface in a lot of ways. And so, we then changed the interface to be honestly, something that's very much like Claude code, or Codex, or how all these terminal apps work, these coding agents in 2024, I don't know, nine months to a year before those tools came out. What we were aiming for was helping people do terminal tasks. We didn't do the better thing, which was coding, until Claude code had come out. But we had basically, that same way of interacting with Warp where you could either type a terminal command, or you could ask in English. If you ask in English, we had this thing called agent mode, which is a term that we actually coined, which has been adopted. It would basically do whatever you ask it to do, but do with terminal commands.

Then we've just evolved Warp more and more over the past year into something that doesn't just do terminal stuff. It does everything in the software lifecycle. It does coding. It's a really, really good coding agent. The distinct thing about Warp's coding agent versus Claude code, or Codex is that it's built into the terminal. You get a very, very rich experience using it. Then increasingly, and we could talk about this in a bit, we're moving these coding features into the cloud. We've moved beyond just being a local desktop app. We have a second product that's called Oz that's cloud agent infrastructure.

The mission of the company is to help developers ship better software more quickly, and we're just leaning into that and building off of our initial terminal routes to try to do that. That's the evolution.

[0:07:37] GV: Yeah, nice. At least back then, the vision, I guess, was things like multiplayer. Has that survived vision-wise?

[0:07:46] ZL: It has. It's like, the whole world has moved in our favor through luck. Yeah, the original business model for Warp was around multiplayer feature. Think of things like, I ran a terminal command and I want to share a link to the commands output across my team. We have that feature. It's actually super useful. You could have multiple people real time in the terminal. That is actually not that useful across teams of people, but it's extremely useful for joining agent sessions. That piece of technology has actually proven to be very useful for us.

Then we have a built-in knowledge store. It's called Warp Drive, and it basically lets you store notebooks, environment variables, shared commands, all that type of stuff. I would say, that stuff has had mixed success across teams, but is more useful for an agent world. What's really useful for an agent world that we've had forever, just having a team concept in the app and being team native. Because what you find as you try to scale agents and build automations off of them, you want agents that are not purely interactive. You want things that are owned by your team. Just having that collaborative infrastructure has actually proven to be very valuable in ways that we did not exactly foresee. That's often how it goes with startups.

[0:09:04] GV: Yeah, for sure. While we're still "in 2022," was there anything that you deeply felt was true then, and now you're like, "No"?

[0:09:16] ZL: It's really interesting. I've actually changed the way that I think about building products for developers a lot over the last four years. I came out of the Google Docs basically and we built, I would say, fairly opinionated, somewhat inflexible products, where we were like, the best product experience is X. This is how it's going to work, and use it or lose it. I brought a little bit of that mentality into the initial building of Warp. I would say, it was initially a pretty highly opinionated product on what the terminal should work like. It was not at all hackable. It wasn't programmably customizable. Our settings were limited. We were like, this is how it should work.

[0:10:02] GV: I feel like, there were a lot of products around that time that were that kind of.


[0:10:06] ZL: Yeah. I would say, a linear -


[0:10:08] GV: Ultra opinionated. Yeah. Yeah. Yeah. Yeah.


[0:10:12] ZL: Notion. This is the school of product development. I was like, we're just building a better thing. If you don't like the thing tough. That might work for some kinds of products, but I've actually totally revised the way that I think about this. I'm writing a blog post on this, where I think when you're building for developers specifically, you really want to be super-duper flexible and acknowledge, and basically build for people who like to hack on their stuff. This is one of the main reasons that we went open source, actually, is because I thought we were doing the product too opinionated and doing it wrong.

At this point, I think it's fine to have a good opinionated set of defaults. But the way that I think about developer product is much more like, developers themselves have strong opinions and varied workflows. We want to let them hack on Warp and customize it. Some people like their tabs looking like one thing. Some people like it totally different. They're running in totally different environments on. I feel like the most powerful and successful developer products are ones that are more of that ethos in school of product thinking than my initial product thinking. It's really evolved. It's pretty interesting.

[0:11:23] GV: Yeah. I mean, because developers are, as we know, very opinionated and where someone just would love to use VIM, and I'm not in a camper, for example.

[0:11:33] ZL: Exactly.


[0:11:34] GV: Then others would love to use the most visual IDE possible. But both the developers are very opinionated on what they want to use.

[0:11:43] ZL: Yeah. Now we're way more in the mode of trying to build for that, rather than build an assistant opinionated workflow. There's pros and cons, to be clear, but my thinking on has totally changed.

[0:11:55] GV: Yeah, super interesting. I guess, looking at where things have gone, we've got, obviously, Claude code, Codex, Gemini CLI. Do you think you saw that coming? At least, I definitely didn't. Maybe in the sense that I still - I was just at a conference, I think, a couple weeks back in SF and I'm still amazed at people that would never have described themselves as developers, and now saying, "Well, I do this all in the terminal," and I just think that's incredible.



[0:12:24] ZL: Did I see it coming? I was arguing that the terminal was going to be the most important to do agentic work over the IDE for a while, before these tools really became prominent. Now, it was a self-serving argument, because I run a terminal company, just to be clear. It makes a lot of sense to me that the terminal is the place and not the IDE. The reason is like the IDE is, it's like Microsoft Word for your code. It's all about hand editing code. That's just not what people do. And the better these agents get, the less that you have to do that at all. I feel like we were pitching that code editing was going to be a secondary thing that developers do pretty early on. By pretty early on, I mean mid-2025. Not talking three years ago or something, but early in the world of agents.

The reason I think that terminal makes a lot of sense is because the whole interface is oriented around telling your computer what to do. That's what you're doing with agents. It's just before agents, you would be telling the computer what to do through terminal commands. With agents, you're telling it what to do in English. It makes sense to me. It's set up for multitasking. It's also at the right level of a stack, where these agents have all the tools they need. It makes complete sense. It's been a really good break for Warp, obviously. It is wild to see people who have no development experience popping open a terminal, or popping open Warp and building stuff, but it does make sense to me.

[0:14:02] GV: Yeah. Warp does explicitly support Claude code, Codex, Gemini CLI, open code. Clearly, you've decided to be very, I guess, agent agnostic. What is like supporting these? What does it actually entail from a - let's go a bit technical for a second. What does it actually entail when you have to think, "Well, we're going to explicitly support these and give a first-class experience"?

[0:14:25] ZL: Yeah. That's a great point. Our strategy is, again, just to reiterate what I said earlier, it's like, we're trying to meet developers where they are and be very flexible. I also think that the best model, the best harness, all that stuff is changing every single week, and where one place Warp can add value is by not making you change your entire tool set as these things change. We have features in Warp. We invested a bunch in this, where whatever agentic CLI you use, whether it's ours, which is built in, or just one of these TUI apps, we try to give you things like integration with our code review features, integration with our file tree, notifications. All these things that make working with these agents nice; vertical tab support.

To do that, it's relatively similar to how we integrate with different shells. Warp works with batch efficient ZSH. The way that we integrate with those is we essentially provide those shells instructions to provide metadata to Warp as they're doing things. For instance, if we want to render the Warp blocks in ZSH, ZSH needs to tell us when a command is starting, when a command is ending. We configure ZSH to do that. Similar for these coding agents, they're all configurable enough via their hooks, or via agent skills, or via plugin system. They all have some version of this, where you can instruct them to provide enough metadata back to Warp, so that we are able to do things like, render in app notifications for them.

We do this literally by letting people run the CLI and configuring the CLI. There are other approaches you could do with this. You could use the SDK for some of these things. We think that people actually, or you could use ACP, which I don't know if listeners are familiar with that, agent-client protocol. We think actually users of these tools actually generally really like the text- based TUI experience. We're not trying to totally take that over. It's more like, we're trying to make that feel more natural and more powerful.

[0:16:36] GV: Yeah. I guess, when I look at, I mean, I am not a daily Warp user. That's not for any particular reason. I don't do a ton of coding, etc., these days. But when I do look at it, it is starting to, for me, look - a case, we had IDEs and then you've got, say, within them, you've got diff use and all this stuff, which was quite helpful. Then you would have a terminal bit of the IDE. Now it feels like we're going the other way, which is like, you start with the terminal bit, but now we're bolting on other views and windows into the terminal. That's what it looks like to me, but what does that sound like to you?

[0:17:11] ZL: That's not totally wrong. The way that we describe it is as an agentic development environment. An ADE, which is another term we've coined. I'm very proud of these terms we've coined and other people have adopted that as well.

[0:17:24] GV: Great.


[0:17:25] ZL: For us, I would say, the primary interface is the terminal still. Then we have added back features related to code editing that we think are useful for agentic workflows. It is useful to be able to see a diff of what the agent has done. As long as you're reviewing agentic stuff by hand, and it's useful to see that in the inner loop of development, so while you're actually working with the agent, I think it's way more useful to see it then and just have to push it to GitHub and do it. We're like, that's useful in this new workflow. It's useful to be able to see a file tree and be able to drag files in this context and know what files the agent is creating.

Our guiding principle here has been like, well, there's new technology. There's a whole new workflow for building software. Let's try to build the product that supports that workflow the best. It's not like we're going to be super-duper rigid around what that product looks like. That's not our ethos. Our ethos has always been like, build the product that makes people using it the most productive. Yeah, we've brought in some features that are more traditionally IDE-like. I'm cool with that.

Now, some users don't like it, just to be clear, and they can turn it off. It's like, we're really trying to let people control this and control how they do it. I think that is actually a sensible default these days is these are useful things if you're building with agents.

[0:18:46] GV: Yeah. I really like that distinction, where just thinking of it as the main pane that, when I say pane, window pane, that a user would be looking at now is the terminal. Whereas, previously, a lot of what a developer would look at is a window off of code. I think that's where that distinction is.

[0:19:03] ZL: Totally. By having the main view be the terminal - in the typical IDE, you'll have N files open, like 10 files open in one terminal. In the typical agent development setup, you might have 10 terminal windows open and just one diff view that's focused on whatever your current

changes. I think we've converted it. It's interesting. You'll notice everyone's converging to that design, because it makes sense. If you open cursor today, or whatever their new cursor glass, or whatever, it looks like that. People are building the form factor that makes the most sense for this new development.

[0:19:40] GV: Yeah. Then just looking at Claude code, for example, it does run in Warp equally, quite can easily be seen as a competitor, I guess, as well. How do you look at the rest of the landscape? Like you've mentioned, Cursor there. I'm just curious, things like Cursor, did you see it as rising tide raises all boats, kind of thing? How do you look at that?

[0:20:04] ZL: It's a really, really interesting landscape. The way we've looked at it has changed over time. We do have a built-in coding agent to Warp. That does generate a bunch of revenue for us. It's an awesome coding agent. We at various times have been at the top of the different benchmarks, terminal bench, we were top three on SWE-bench. Developers just want to try different stuff. Our overall strategy right now is not to try to push our own thing above what some developer might want to use. There are advantages to ours, like you get a richer UI. But a lot of people want to use Claude code. Companies want to use Claude code. If they want to use Codex, they have contracts with Codex.

I think from a strategic business perspective, it is more in our interests to try to be complementary and not purely competitive and be a great place to run any coding agent. Warp will cross a million active developers this month, which is really exciting. We want to be part of the chain of building with AI. We think there's a lot of strategic value in that. Our business bet is less on the interactive coding agent within Warp, than it is on helping companies that want to build software factories internally and automate software development. That's, I think, where our business will have last CMO. With the developer facing side, we want to just have as many developers using it and liking it and helping that as be part of our funnel and do a more of an enterprise business. That's what I'm thinking about the strategy currently.

[0:21:44] GV: Yeah, very interesting. We'll get to how Warp is built later, actually, because I think it'll be an interesting to touch on, when we touch on the fact that Warp is now open source. We'll come back to that. I want to just move on to Oz. Oz is something that was launched, I believe, in February this year. Talk to us about Oz. What is Oz?

[0:22:04] ZL: Yeah. Oz is cloud agent infrastructure. The way to think of it is if you were trying to automate certain development tasks, and it could be automated code review, or it could be automated debt code cleanup, code migrations. It could be issue triage. It could literally just be implementing features and fixing bugs. The way that's going to happen in the future, I strongly believe, is not on individual developers' laptops, or at least not entirely on their laptops, but it's going to happen. The only way you're going to scale it is if you move it to the cloud.

We're trying to help companies. Oz is primarily a enterprise product. We're trying to help companies set up this infrastructure, so that they can automate a lot of these development tasks. The other big pieces of it are increasingly, we hear that companies want cost controls on these agents. As part of that, I think they want to be able to use different models and different harnesses for different tasks. They want auditability. If an agent does something that causes a problem, you want to be able to go see what it did. They want handoff from cloud to local.

There's actually a really rich suite of features for automating software development that come with Oz, where we think every company is going to want something like this. Some companies will build it, but most companies will buy something like this. That's actually driving most of our enterprise business, which is growing really fast right now. I think there's a huge market here.

[0:23:43] GV: Yeah. I mean, maybe just talk to us a bit more about the auditability side. I mean, I think that's something, certainly, I would say, maybe last year when I was going to a few conferences here in Singapore. Conferences here tend to be very enterprise-focused.
Singapore is a sales hub for technology and it was all about agentic, but it was all about, but how do we know what's going on and all that kind of stuff. That's what we're talking about here, like how do you know -

[0:24:08] ZL: Yeah, totally.


[0:24:09] GV: Yeah. Yeah. What does that look like, I guess, in all these?


[0:24:14] ZL: Just to paint the picture, companies are going through different phases of agentic development. I would say, there is a period maybe towards the end of last year, early this year for a lot of companies where they're just like, give everyone everything. Let them spend as

much as they can and code stuff with all of these local coding agents. I'd say, Claude code is the most popular. I think that's fair to say.

[0:24:39] GV: Yeah. At least we're recording in May 12th. So, yes.


[0:24:43] ZL: Yeah. May 12th. Yeah, exactly. On this particular day, I don't know that that will be true indefinitely. What has happened is you will see, I think it was the head of engineering at Uber was where we burned through all of our AI credits that we allocated for the year in the first three months. There's cost. You'll see Amazon had some production outage, or whatever that was caused by Vibe coding some config thing. You'll see Vercel, at some big security thing, I don't know if that's traced back to Vibe coding or not. You'll see cloud accidentally open source their whole code base. I think that people are waking up to the flip side of this huge, powerful chainsaw tool that you're giving everyone is that there's a real need to control it.

Auditability is one piece of that. The simplest way of thinking about that is just like, what's the raw conversation trace of what your agent did? If you're using Oz, we store every conversation. It's like, you can see every tool call, every system that the agent accessed. If the agent did something wrong, or was prompt injected, you can go back and trace what happened. How did I have those tokens? What do we need to lock down? That's one piece of it. There's other things just on the governance side that you want in place. You want these things running in Sandboxes. You want them having lease privilege, so they don't have more code installed than they should. They don't have sensitive files that they have access to on the file system. They have limited network egress. They have the minimum number of MCP privileges and secrets to other internal tools. All this stuff. Now, we're going to go into a phase where the maturity of these tools becomes more important, so we're trying very hard to make it easy to deploy that type of system.

[0:26:45] GV: Yeah. I mean, on the deployment side, I guess, is it fair to say this is feels a bit like a CI/CD infrastructure, or do you see a totally new category, or how do you see that?

[0:26:58] ZL: It's in the CI/CD family. I would say, has slightly different characteristics than CI/ CD. At some level, it is like a DAG, like a director graph of tasks. Because there's intelligence, it tends to be more like the DAG is created on the fly. The more common pattern that we've built

towards is there's a orchestration agent, like one that that is controlling what other agents are being launched, what permissions they have, what their sub tasks are. You need more flexible permissioning. I think it's in the CI/CD realm, but it's not exactly that same execution pattern.

For us, we integrated into CI/CD, you can run it from within CI/CD, you can tag it in GitHub, you can tag it in all of your - actually, in any of your tools. You can tag it in linear, you can tag it in JIRA, you can tag it in Slack. I think it's a more flexible and more interactive thing than just a very rigid CI/CD pipeline. It's more like teammates, I think it's where it's going to end up, to be honest.

[0:28:11] GV: Okay. Yeah.


[0:28:12] ZL: It's going to be more like, you have these long-lived teammates that have skills that can do - they have skills, they have access to systems. I think that's a better mental model than CI/CD.

[0:28:24] GV: Yeah, that makes sense. I think an example is an issue triage app, for example, that tackles GitHub issues. That feels like a teammate to me.

[0:28:35] ZL: Yeah, exactly.


[0:28:37] GV: Let's move on to a quite interesting topic, which is the fact that Warp has gone open source. I think you did talk about this, I believe, the original Hacker News post in 22 did talk about wanting to go open source. I guess, here we are four years later. Talk to us about this, the why and how it's going to go from there.

[0:28:59] ZL: Yeah. Historically, we'd always talked about this, thought about this. We revisited it every single year. We're a developer tool. I think developer tools generally should be open source. We probably should have done it sooner. But I would say, the reason we actually did it now, the thing that got me to believe that this was a smart thing for us to do was the state of agentic development. We think we can move faster now. I think we had some concerns around like, how do we actually manage the repo, manage external contributions? The way that we have open-sourced Warp is with very, very tight Oz integration. It's actually the coolest way to

see how Oz works is to go to our open-source repo, or to go to build.warp.dev, where we have built this dashboard of what's going on in open source.

We realized we're writing most of our internal code using agents, using our own agent. We've invested a ton in the skills that this agent needs in the context to do good agent changes on Warp. We have a pretty rigid - or not rigid. We have a workflow that we like, that's around spectrive in development for building on Warp. Then we have really good verification that's also agent-driven, whether it's through our agent code review, or computer use on Warp's app, video-based integration testing. We think that we can actually move faster and build a better product if we do this with the community in the open and have our agents do a lot of the coding, verification, triage, all of the stuff that can be a lot of work around open source. Then have the community provide a bunch of ideas, guidance. We still are manually testing everything.

It's really cool, because the community is fixing issues that we dog food Warp extensively, but we're not using Warp in Chinese, for instance. We're not using it constantly with IMEs. We use it way less on Windows and Linux than we do on Mac. Again, developers have totally different workflows and awesome ideas for how to improve the product. We pay for the agent, the inference for doing this by and large, which is really cool model also. We worked with, OpenAI sponsors the repo and pays for the inference for Oz there. It's just a totally different way of building software.

Then, we do think having an open product here is something that developers should have. Most of our competitors are actually not open source. In fact, I don't know if there is another open- source thing that's quite in the category of Warp. They're open-source terminals, but Warp is much more than a terminal. There's obviously VS Code, but VS Code is still very much an IDE. We think that there's a real opportunity for people who want to build this agentic workbench to get to contribute to it. All of these things made it feel really right at this time. It's been very successful. We did it two weeks ago. I don't even know how long. Not long ago.

[0:32:13] GV: Yeah. It was recent. Yeah. Yeah.


[0:32:16] ZL: And we more than doubled our GitHub stars. We're almost at 60,000 GitHub stars. We've been the top trending open-source repo on GitHub for most of the time we've been

open source. We've had over 500 people open contributions. It's just been awesome. It's a bunch for us to figure out exactly how to work with the community and make sure we're doing a good job there. We've shipped a ton of fixes and improvements and people seem generally really, really psyched. I'm very happy that we did it. It's so cool.

[0:32:45] GV: Yeah. I mean, being a developer tool, it's just a huge signal when you're open source versus not. For sure, it's the best way forward. I think that the how is - I'm always curious. We had Convex on a couple of years back at this point, and they had just gone open source when we had them on. The how was interesting, just like, how do you actually go from being a closed source repo to open. Just any interesting things there?

[0:33:12] ZL: Yeah. The way that we actually had to do this, we had to clean up the code base for one day.

[0:33:21] GV: No more comments with expletives, or that kind of thing. Yeah.


[0:33:24] ZL: You just have to work differently. If everyone's looking at your stuff. The types of things that we spent time doing from the moment we decided we were going to do this to when we launched it were - it was like, making sure there was no customer specific information in our code base, for instance. You could hack things in for particular customers before. You can't do that now. Making sure from a commit history standpoint, no secrets, nothing sensitive. We ended up just doing a fresh commit history was just like, there was too much over the period of five years of building Warp, it's too scary that there was going to be something sensitive from a security standpoint, or a customer, or PI standpoint in there. We did a fresh version of that.

We had to move all of our issue tracking. We have dual issue tracking before of public was GitHub issues and internal was linear, and everything's moved on to GitHub issues, the public version of it. We had to publish our roadmap. I say, had to, but this is actually great, because it's like, now all of a sudden, everyone can see our roadmap and tell us if we're working on stuff that's going to be useful for them, or not. We had to move all this stuff to be public.

We wanted to think also really hard about like, well, what were the forks we expected people to do, right, and try to see around the corner on those and see if we could build the functionality for

doing that. The forks that people want are not surprising to me. But now we have a bunch of signal, and so, it's like, we're trying to actually listen to the community. What people really want, just to make clear, they want to be able to bring their own inference and they want to be able to use local models in Warp. We could see someone built a fork of that. It's fairly popular. So, we're building that into Warp as quickly as we can.

It's been really awesome from a signal perspective on what's important to developers to work this way. Yeah, lots of stuff to clean up the code base, a lot of work making sure checking for security vulnerabilities, it's another thing. People immediately found more. Again, there's pros and cons to working in the open. I would say, it's a pro. These things were latent.

[0:35:27] GV: I would agree, it is a pro. It is a pro. Yeah.


[0:35:30] ZL: Yeah. These things were latent in our code base. All of a sudden, we have people running every security tool in the world on our code trying to harden it. It's not surprising they found that a couple of things, nothing too bad, but it helps us harden the security of it. Super interesting process.

[0:35:46] GV: Yeah. I guess, for those detail-oriented people, licensing, I believe, it's AGPL. i.e. not MIT, not Apache. Could you just talk to us about that?

[0:35:58] ZL: Yeah. The overall work code base license is AGPL. Parts of it, we also open- sourced our UI framework, for anyone who wants to build a UI app. It's a pure Rust UI app. That's MIT. That AGPL is what's called a copy left license. It's a real open-source license, but the biggest term that's different from MIT, or Apache is that if you fork it and you publish it, you need to maintain that same license. It's a little bit of competitive protection for us, just to be totally frank. It's the same license that Zed has. I don't know if you know Zed. We want people building on it. We're totally happy with people forking it. I would rather people contribute. I think that it'll become a better product when people contribute. If someone wants to build another business off of it, they're going to have to build an open-source business off of it, which is a little bit different than if we're MIT licensed, where someone could fork it and build up a closed source business off of it.

[0:36:55] GV: Yeah. Just hot take here. I think that's probably the right way forward. I mean, we've seen some interesting cases of let's say, VS Code becoming something -

[0:37:05] ZL: Exactly.


[0:37:06] GV: - that is definitely not -


[0:37:08] ZL: This weighed on us very, very, very clear. That was the thinking behind the license.

[0:37:13] GV: Yeah. It did always look a bit strange taking something that has, okay, VS Code came from Microsoft. It's not like that is financially a problem for them really. I think there clearly was a huge community around VS Code as well. I think for them to then see their work being taken and then repurposed and then basically sold almost as is on day one, I think that's a bit strange.

[0:37:36] ZL: Yeah. I think it's the right license for us. I also think, because this is for the product, it's a little bit different than if it were for a library. It's hard to build on AGPL libraries per se, because then, it's like, you got to open source your whole app to use some node library.
That's annoying. I think at the product level, it feels pretty different to me to have it as a AGPL license.

[0:38:03] GV: Yeah. in terms of contributing, I think you described a model of agents doing the actual heavy lifting on the implementation. Community members focused on ideas, direction, verification, and then the actual Warp team itself guiding the what gets built. Does that sound about right? Or how do you look at this?

[0:38:24] ZL: Yeah. Yeah. I walk through the process, actually. It's an interesting workflow. If you want to contribute to Warp, you basically start by opening an issue, which is how it works most places. We've made it easy. You can open an issue directly from within Warp agentically, by running like, we ship a skill with Warp. This is called /feedback, where you can either provide the bug report, or the future request directly from within Warp, and it will do a pretty good process of gathering the info opening the issue for you. Once the issue is opened, there is an agent that

runs on it, which does triage. It will dedupe it. It will do an initial complexity and feasibility analysis. It'll assign it to a part of the code base.

At that point, someone from Warp will look at it and be like, there's a few steps that could happen from there. One is like, we could just be like, this is ready to implement, and someone from the community or someone from our team can take it. In which case, anyone who wants to work on it is free to grab it. We could mark it as what we call ready to spec. That means it's a more complex issue that shouldn't be one shot by an agent. Instead, there should be, we want to see product and tech specs. The agent will generate those, but there needs to be this is how the feature is going to work. Or if it's a hard bug fix, this is how the technology, the architecture is going to work. That's a second thing we might do.

A third thing we might do is say like, not now. I think we need to reserve the ability to be like, not now for certain things. We really want the app to be cohesive and works super well. We view ourselves a bit as editors here in terms of what should be built and when. For, let's say, we're doing something where it's actually ready to be implemented, at that point, someone is free to ask us to implement it. They're also free to do the normal open-source thing and fork the repo, make a local change, send us a PR. The difference is if Oz does it, we'll pay for all the inference. I would suggest that people at least try to use Oz. We've also provided all of these skills that come with the repo for how to make effective changes.

It's not a simple repo. It's over a million lines of custom Rust code built from the ground up. We do suggest people use that context. Unlike other open-source repos, we really want people using agents. I have more confidence in an agent-driven workflow succeeding and getting merged than I do in just a purely human one. We're using agents internally for everything, and so it's not like we're holding the community to a different standard. This is just the way to build stuff on Warp right now. You will generate a PR with an agent. We will then have an agent. It's all Oz. Run code review on it and look for things that need to be fixed.

We will have an agent run different verification that could be computer use, make sure integration tests. We do want people checking out and building and running the code. I don't have complete confidence yet of merging it, until it hasn't been verified by someone. But if they do that, then we'll do a real code review. We're still doing human code review as well. I think it's

still important. It's got to be a good app, and so we do that, and then we merge it. I don't know the exact number, but we've had over 500 people have created contributions. I think we've merged over PRs from a hundred different people, or something. It's really, really cool. That's the contribution process and it's letting us ship things that we otherwise definitely would not have been able to ship.

[0:42:04] GV: I don't know if this is an obvious question, but it almost sounds like, those contributing now today don't necessarily need to know Rust.

[0:42:13] ZL: Definitely not.


[0:42:14] GV: No? Okay.


[0:42:16] ZL: Yeah. It's made the bar for contributing, I don't want to say lower. It's just made it wider. You could be any kind of developer.

[0:42:24] GV: Because that's what always strikes me the Rust is an amazing language in many ways. People, obviously, some great pro, some not so, but that's just languages generally. But it is still a bit of a niche language. If you're going to build something in Rust -

[0:42:36] ZL: It's hard.


[0:42:37] GV: - you better you better be ready to find some far off developer who wants lots of money to come work on your thing.

[0:42:42] ZL: We're just past that. It's so cool. Anyone who uses the product, I would say, even if they don't know how to code can try to make a change. I think most of the people who are making changes are developers, just because the nature of our product and open-source contributions. But it's really widened the funnel of who can contribute, which again is one of the reasons why I think open source makes so much sense in a time of agentic development. It gives everyone the chance to contribute to the apps that they use, no matter what your technical background, or capabilities. It's really cool.

[0:43:17] GV: Yeah. Then just wrapping up on this one, I guess, some people will be asking, what is the business model? I mean, you've mentioned inference, but that's sponsored at the moment. Is Oz, is that the paid product?

[0:43:29] ZL: Yeah. We make we make money in two ways. One is if people use our coding harness, so we make money through that. Our harness is mostly on our server still. We charge for that. I should be clear, it's our client-side app that is open, not the server piece of Warp.
We've maintained some parts of Warp that are more closer to the business as closed source for now, at least. We may open them, too. I'm very into open source right now. Then the other thing is our cloud agent infrastructure is more like an infrastructure product. It's a little bit more like a Vercel model, or something like that, where we charge companies for orchestrating cloud agents and we're not making money there necessarily, even on reselling inference. It's like, we're selling infrastructure to companies that want to automate software development. That's Oz. That's more of our business.

[0:44:23] GV: Got it. Moving, I guess, on to just as we start cruise to the end of the episode, but the feature of developers, this is always a hot topic. Myself and Sean, one of our other hosts, we've debated this quite a bit on our SED News monthly installment, where we're sort of like, where are things going? How do junior developers get in the door? You're quite close to this, I think. What do you think? What do you see? Let's maybe start with this thing that keeps coming up about junior developers and A, should they even get a CS degree? B, how do they get a job additionally now, all this stuff?

[0:45:02] ZL: One data point here is we're hiring, and we're hiring at all levels of seniority and it's never been more competitive for us to hire extremely talented people. We have a really amazing team. What we're seeing it as is it's a force multiplier for productivity and there's infinite demand for software in the world. My expectation is that a junior developer at Warp is going to just ship way more than they were able to ship before, and same for a senior developer. The key skills for that junior developer to have are changing. I think that's actually really relevant.
What matters less is coding, which is a weird thing to say about a junior developer. But what matters is like, do you understand the system? Do you understand how the product should work? Can you use agents super effectively? Agents are your new tool set. Are you adaptable? Because the way that these agents are working is changing every month or so.

We've always hired smart generalists, and I've never hired language specialists. I would just triple down on that. Smart generalists who can use all these agentic tools is so valuable right now. CS degree, again, I would never view CS degree as a vocational degree. I would view it as a degree where you're learning problem solving skills, you're learning engineering skills. I would say, any STEM degree is probably really good for the future, to be honest. CS is still really good.

[0:46:43] GV: Yeah. Somebody asked me, there's actually a VC asked me the other day, how they could encourage some of their oil companies to do more agentic coding? Because they looked at what was going on and they looked in their portfolio and said, or talked, I guess, to some of their fellow companies and didn't feel that they were doing enough, shall we say. What would be the inroads that you would suggest they like - Does Warp and Oz, is that a really nice on-ramp to all of this? Or, yeah. I mean, that's obviously a biased question slightly, but yeah.

[0:47:15] ZL: I love it. Yes, that's perfect. That's the correct -


[0:47:17] GV: Yes, there we go. Just sales pitch right there, but yeah.


[0:47:21] ZL: When I've seen bottlenecks, so I guess, a couple of thoughts here. One is I feel like, that's actually less and less common. I feel like a year ago, I even did this LinkedIn post where I was like, I'm having a really hard time getting the senior developers on our team to embrace this new way of working. The reticence from the senior developers at the time, I think was pretty warranted in that the agents couldn't do as good of a job and, and it was - if you're a senior developer, you could write a better thing more quickly if you knew what you're doing, than using an agent. I think that has just flipped based on improvements in the models and the harnesses in the last six to nine months.

I would try to get your senior developers convinced, because the way that the influence tends to work in development works in my experience is like, it's the staff engineers, principal engineers embracing stuff, and the junior engineers will come along and do it. I would try to convince that cohort that there is a way to do engineering with these tools that produces a better-quality product more quickly. I would not call it vibe coding. I think that that's a horrible term. It diminishes the craft of engineering. I would call it agentic engineering. I would say, that there is a new standard of doing development that's actually really fun and empowering and it just

moves the abstraction layer for engineering up one level if you embrace doing it. Then I would model it. I would model the behavior. Like, I was doing all this agent stuff at Warp. I'm still our biggest user, I think, even before a lot of our senior engineers. Model it. Show what you can do.

Yeah, Warp is a great tool. I don't need to show Warp, but Warp is a great place if you want to get fully into agentic development, whether it's using our own agent harness, or using Claude code, or Codex. Oz is even more of the future. It's like letting you set up automations using these agents. I think they're great tools for getting into it for sure.

[0:49:23] GV: Nice. Well, I think that's a great place to leave it. Agentic engineering over vibe coding. Definitely is about that.

[0:49:28] ZL: Definitely.


[0:49:29] GV: Definitely. Yeah. Zach, thank you so much for coming on. I think this has been super interesting. Lots to cover. Who knows? I don't think we've ever had a guest on three times. Who knows? Maybe in another three to four years, we'll have you.

[0:49:40] ZL: Let's see.


[0:49:41] GV: Have you back and we'll hear about the Warp evolution round three.


[0:49:45] ZL: Cool. Well, it was a pleasure to come chat. Thanks for having me on.


[0:49:48] GV: Yeah, absolutely.


[END]