The Terminal as an Agentic Interface

Speaker A: 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 code base 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 um, the Google Docs suite. In this episode, Zach joins Gregor Van to discuss how Warp has evolved over the years, why the Terminal is better suited than the IDE for agentic development, how 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, uh, cyber insurance and general software engineering companies. He is based in Singapore and can be found via his profile at Vand HK or on um, LinkedIn.

Speaker B: Hello and welcome to Software Engineering Daily. My guest today is Zach Lloyd who's returning after four years. So we've already had Zach on in 2022. Yeah, welcome Zach.

Speaker C: It's good to be here. Thanks for having me back.

Speaker B: Yeah, we're going to be talking all about Warp, which some of our listener base will be quite familiar with I think before we get into Warp itself we, we normally sort of 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 kind of TL doctor of how you ended up building Warp?

Speaker C: 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 Docs 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 like my second venture backed startup that I've done. First one totally, totally different space. Pretty interesting learning experience. But fundamentally I would say, uh, I'm someone who, I really, really like building stuff. It's really fun for me. My goal has been to build like 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. And honestly increasingly since anyone can be a developer, it's really Useful for a lot of knowledge workers as well. It's like a crazy changing space to be in, but that's like me in a nutshell.

Speaker B: Yeah, nice. So I think, sort of thinking about what you might have been talking about in the episode back in 2022, but I guess sort of back then the pitch was Warp was this beautiful, fast, rust based terminal trying to bring Command Line into. Call it like the 21st century, because command Line hadn't really changed in many ways. But since then a lot of things have happened, including your AR has grown a ton and you've got open source, which you're going to get to and all sorts of things. So walk us through maybe the last four years if you can. Uh,

Speaker C: it's not as 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. So I would say the warp journey is right the way you described it. So for folks who maybe aren't familiar with Warp, we started off focused on just sort of reimagining the experience of using the terminal. The concept was like Terminal's a really important app. It's where developers spend a lot of their time. It was the terminal and the code editor, I've always said, ah, are the two most important developer apps. And the terminal just hadn't had a lot of innovation. And so we tried to reimagine kind of from first principles. What should a great command line experience be like? I'm very proud of what we've built. Like 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. Like 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. But we have this feature where we separate the terminal outputs into blocks. It makes them more readable, you can take actions on them. So 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. So I don't know if uh, 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. And what we were using it for was we would translate English into terminal commands. So it's really like translation, not like a uh, agent capability. But you'd be like give me the command for finding all Python files that are greater than 100 lines in this directory or something like that. You'd say that in English and we would translate it for you. And 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. And LLMs are great at helping people construct those commands. So we brought in a chat panel in 2023 into Warp, but, uh, we realized that was actually a sort of 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, uh, in 2024, like, I don't know, nine months to a year before those tools came out. But what we were aiming for was helping people do terminal tasks. So we kind of didn't do the more 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. And if you asked in English, we had this thing called agent mode, which is a term that we actually coined, which has been adopted. And it would basically do whatever you asked to do, but do it with terminal commands. And 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. So it does coding. It's a really, really good coding agent. In the distinct thing about Warp's coding agent versus, like cloud code or Codex is that it's built into the terminal. So you get like a very, very rich experience using it. And then increasingly. And, uh, we could talk about this in a bit. We're moving these coding features into the cloud. So we've kind of moved beyond just being like a local desktop app. We have a second product that's called oz, that's cloud agent infrastructure. And so we're just kind of. The mission of the company is to help developers ship better software more quickly. And we're just sort of leaning into that and building off of our initial terminal routes to sort of try to do that. So that's the evolution.

Speaker B: Yeah. Nice. And at least back then the vision, I guess, was things like multiplayer has that kind of survived? Vision wise, it has.

Speaker C: So it's like the whole World has kind of moved in our favor kind of through luck. So yeah, the original business model for Warp was around multiplayer features. So think of things like I ran a terminal command and I want to share a uh, link to the command's output across my team. So 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. So that piece of like technology has actually proven to be very useful for us. And then we have like uh, 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 like mixed success across teams, but is more useful for an agent world. And what's really useful for an agent world that we've had forever is just having a team concept in the app and being sort of team native. Because what you find as like you try to scale agents and build automations off of them. You want agents that are not like purely interactive. You want things that are owned by your team. So just having that collaborative infrastructure has actually proven to be very valuable in ways that we did not exactly foresee. That's kind of often how it goes with startups.

Speaker B: Yeah, for sure. And while we're sort of still in 2022, was there anything that you deeply felt was true then and now you're like, no, that's just, it's really interesting.

Speaker C: I've actually changed the way that I think about building products for developers a lot over the last four years. You know, I came out of like the Google Docs basically and like 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. And I brought a little bit of that mentality into the initial building of Warp. Like I would say it was initially like 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 kind of limited. We were like, this is how it should work.

Speaker B: I feel like there were a lot of products around that sort of time that were that kind of. Yeah, I would say like linear, ultra opinionated. Yeah, yeah, yeah.

Speaker C: Notion. Like this is like the school of product development where I was like, we're just building a better thing and if you don't like the thing, tough and that might work for some kinds of products. But I've actually totally revised the way that I think about this and 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 build for, basically build for people who like to hack on their stuff. And this is one of the main reasons that we went open source actually is because I thought we were kind of doing the product too opinionated and doing it wrong. And 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 in varied workflows and we want to let them hack on warp and customize it. And some people like their tabs looking like one thing, some people like it uh, totally different, they're running in totally different environments and so on. And so I feel like the most powerful and successful developer products are ones that are more of that ethos and school of product thinking than my initial product thinking. So it's really evolved. It's pretty interesting.

Speaker B: Yeah. I mean because developers are uh, as we know, very opinionated and where someone just would love to use Vim and um, I'm not in that camp for example.

Speaker C: Exactly.

Speaker B: And then others would love to use the most kind of visual IDE possible. Yeah, but both are developers but like very opinionated on what they want to use.

Speaker C: Yeah. And that's. So we're just. Now we're way more in the mode of trying to build for that rather than building such an opinionated workflow. There's pros and cons to be clear but my thinking on uh, it has totally changed.

Speaker B: Yeah, that's super interesting. So I guess looking at where things have gone, you know, we've got obviously like Claude Code Codex, Gemini cli. Do you think you saw that coming at least? I definitely didn't in the sense that um, I was just at uh, a conference I think a couple of 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.

Speaker C: 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 kind of a self serving argument because I run a terminal company just to be clear. But uh, it makes a lot of sense to me that the terminal is the place and not the ide. And the reason is the IDE is it's like Microsoft Word for your code. It's all about hand editing code. And that's just not what people do. And the better these agents get, the less that you have to do that at all. And so I feel like we were pitching that code editing was going to be a secondary thing that developers do pretty early on. And by pretty early on I mean like mid-2025. We're not talking like three years ago or something, but early in the world of agents. And 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. And 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, uh, what to do in English. And so, you know, makes sense to me. It's set up for multitasking. It's also at the right level of the stack where these agents have all the tools they need. And so it makes complete sense. It's been a really good break for Warp. Obviously it is wild to see people who are not have no development experience popping open a terminal or popping open Warp and like building stuff, but it, it does make sense to me.

Speaker B: Yeah. And Warp does explicitly support cloud code, Codex Gemini, CLI open code. Clearly you've decided to be very, I guess, agent agnostic. What is 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 uh, give a first class experience?

Speaker C: Yeah, so that's a great point. So 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. And 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. So 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 like one of these TUI apps, we try to give you things like integration with our code review features, integration with our file tree notifications. So all these things that make working with these agents nice, vertical tab support. And so to do that it's relatively Similar to how we integrate with different shells. So Warp works with Bash, Phish and zsh. And the way that we integrate with those is we essentially provide those shells instructions to provide metadata to Warp as they're doing things. So 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. And so 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. Um, 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. And so we do this literally by letting people run the CLI and configuring the cli. There are other approaches you could do with this. Like you could use the SDK for some of these things, but we think that people actually. Or you could use acp, which, uh, I don't know if listeners are familiar with that agent client protocol, but we think actually users of these tools actually generally really like the text based TUI experience. And so 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.

Speaker D: Yeah, you're building agents that can write code, summarize documents and automate workflows, but. But they're missing one awareness of the world around them. Xweather combines enterprise grade weather intelligence with agent ready APIs, natural language capabilities and an MCP server built for tools like Claude Codex, Copilot and modern ides. So your agents can adapt workflows, automate responses and make better decisions based on real world conditions. Backed by Vaisola, whose instruments fly on NASA missions to Mars, Exweather delivers trusted data and unique insights that go beyond conditions to actual impact. From real time lightning strikes to road surface forecasts.

Speaker B: Science.

Speaker D: Start with 15,000 free API calls every month and pay only for what you use as you grow your full weather stack for developers by developers start building for free today@uh, xweather.com

Speaker A: Think about your mobile app's source code. Once it hits the app store, it's out in the wild and without the right protection. Decompiling is easy for malicious actors looking to steal your IP or tamper with your software. That's where Guard Square comes in you. Guardsquare provides the highest level of mobile app security for Android and iOS applications and SDKs. Their advanced tools integrate seamlessly into your CI CD pipeline. We're talking polymorphic multilayered code hardening techniques and automated runtime application self protection paired with mobile application security testing and real time threat monitoring to deliver the highest level of mobile app security without compromise. Don't leave your hard work exposed. Secure your mobile applications today. Go to guardsquare.com to learn more.

Speaker D: You're shipping faster than ever with AI coding agents. But those agents don't vet the packages they pull in and they don't have security context built in ORI by Endor Labs fixes that it plugs directly into your editor via mcp, catching vulnerabilities, blocking malicious packages and flagging exposed secrets in real time. No separate tool to switch to, no dashboard to babysit security that fits how you actually build teams using Ori. See 10 times fewer security tickets and 6 times faster fixes. Free for developers. Get started at www.endorlabs.com Auri I guess

Speaker B: when I look at. I mean I just uh. I am not a daily warp user. That's not for any particular reason. I don't do a ton of coding, et cetera these days. But when I do look at it, it kind of is starting to for me. Look. So we had ides, and then you've got say within them you've got diff views and all this stuff, which was quite helpful. And then you would have a terminal bit of the ide. And now we've kind of. It feels like we're kind of going the other way, which is like you start with the terminal bit, but now we're bolting on like other kind of views and windows into the terminal. That's what it looks like to me. But like what does that sound like to you?

Speaker C: That's not totally wrong. So the way that we describe it is as an agentic development environment. So 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.

Speaker B: Great.

Speaker C: So for us, I would say like the primary interface is the terminal still. And then we have added back features related to code editing that we think are useful for agentic workflows. And so it is useful to be able to see a diff of what the agent has done as long as you're reviewing Agentix 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 to just like have to push it to GitHub and do it. So 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 as context and know what files the agent is creating. And so our uh, like guiding principle here has been like, well there's new technology, there's a whole new workflow for, for building software. Let's try to build the product that supports that workflow the best. And 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. And so yeah, we've brought in some features that are more traditionally ide like I'm cool with that.

Speaker B: Yeah.

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

Speaker B: Yeah, I really like that distinction where just sort of thinking of it as the main pane that uh, when I say pain window pane that a user would be looking at now is the terminal. Whereas previously a lot of what uh, a developer would look at is a window of code. And I think that's sort of where that distinction is totally.

Speaker C: And 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. And in the typical agentic development setup you might have 10 terminal windows open and just one diff view that's focused on whatever your current change is. So I think we've converted it and it's interesting. You'll notice everyone's converging to that design because it makes sense if you open cursor today or whatever they're new cursor glass or whatever, it kind of looks like that. So I think that's, you know, people are building the form factor that makes the most sense for this new kind of development.

Speaker B: Yeah. And 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. Like how do you sort of look at the rest of landscape? And like you've mentioned cursor there and like I'm just curious like things like cursor. Did you see it as rising tide raises all boats kind of Thing, how do you look at that?

Speaker C: It's a really, really interesting landscape and the way we've looked at it has changed over time. So we do have a built in coding agent to Warp and that does generate a bunch of revenue for us. And it's an awesome coding agent. We at uh, various times have been at the top of the different benchmarks like terminalbench, we were top three on suitebench. But developers just want to try different stuff. And so our overall strategy right now is not to try to push our own thing above what a developer might want to use. There are advantages to ours. You get a richer ui. But a lot of people want to use cloud code. Companies want to use cloud code, they want to use codecs, they have contracts with codecs. And so I think from a strategic business perspective it is more in our interests to try to be complimentary and not purely competitive and be a great place to run any coding agent. And Warp will cross a million active developers this month, which is really exciting. And we want to be part of the chain of building with AI and we think there's a lot of strategic value in that. And 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. And that's I think where our business will have last emote. And 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 into a more of an enterprise business. So that's how I'm thinking about the strategy currently.

Speaker B: Yeah, very interesting. We'll get to kind of how Warp is built later actually because I think it'll be interesting to touch on when we touch on the fact that Warp is now open sour. So we'll come back to that. I want to just move on to oz. So OZ is something that was launched I believe in February this year. Talk to us about oz. What is oz?

Speaker C: Yeah, so OZ is cloud agent infrastructure. The way to think of it is if you are trying to automate certain development tasks and it could be like automated code review or it could be automated that code cleanup, code migrations, it could be issue triage. It could literally just be like 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 be able to scale it is if you move it to the cloud. And so we're trying to help companies. So OZ is primarily enterprise, uh, product. We're trying to help companies set up this infrastructure so that they can automate a lot of these development tasks. And 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. So 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. And so there's actually a really rich suite of, uh, 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. And so that's actually driving most of our enterprise business, which is growing really fast right now. So I think there's a huge market here.

Speaker B: Yeah, maybe just talk to us a bit more about the auditability side. I think that's something certainly, I would say maybe last year when I was going to a few conferences here in Singapore. And conferences here tend to be very enterprise focused. Singapore is a sort of sales hub for technology and it was all about agentic, but it was all about how do we know what's going on and all that kind of stuff. So that's kind of what we're talking about here. How do you know?

Speaker C: Yeah, totally.

Speaker B: What does that look like? I guess in os.

Speaker C: So 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. So I'd say Claude code is the most popular, I think that's fair to say.

Speaker B: Yeah. At least, uh, recording in May 12th, so. Yes, May 12th.

Speaker C: Yeah, exactly. So on this particular day, I don't know that that will be true indefinitely. And so what has happened is, you will see. I think it was like the head of engineering at Uber was like, well, we burned through all of our AI credits that we allocated for the year in the first three months. And so 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 had some big security thing. I don't know if that's traced back to Vibe coding or not. You'll see Claude accidentally open source their whole code base. And 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. And so 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? And so if you're using oz, we store every conversation. So it's like you can see every tool call every system that the agent accessed. And so if the agent did something wrong or was prompt injected, you, uh, can go back and trace what happened. How did it have those tokens? What do we need to lock down? So that's like one piece of it. And there's other things just on the governance side that you want in place. Like you want these things running in sandboxes, you want them having least 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. So all this stuff. Now we're going to go into a phase where the maturity of these tools becomes more important. And so we're trying very hard to make it easy to deploy that type of system.

Speaker B: Yeah, and I mean, on the deployment side, I guess, is it sort of fair to say this feels a bit like a sort of CICD infrastructure? Or do you see a totally new category? Or how do you see that it's

Speaker C: in the CI CD family, I would say, has slightly different characteristics than cicd. At some level it is like a dag, like a directed graph of tasks, but because there's intelligence, it tends to be more like the DAG is created on the fly. And like the more common pattern that we've built towards is there's a sort of orchestration agent, like one that is controlling what other agents are being launched, what other agents, what permissions they have, what their subtasks are. You need more flexible permissioning. So I think it's in the CI CD realm, but it's not exactly that same execution pattern. And so for Oz, we integrate it 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, uh, actually in any of your tools. You can tag it in linear, you can tag it in jira, you can Tag it in Slack. And so I think it's a more flexible, more interactive thing than just like a very rigid CICD pipeline. It's more like teammates I think is where it's going to end up to be honest. It's going to be more like you have these long lived teammates that have skills that can do that. They have skills, they have access to systems. I think that's a better mental model than CI cd.

Speaker B: Yeah, that makes sense because I think an example is an issue. Triage app for example, tackles GitHub issues. So that feels like a teammate to me.

Speaker C: Yeah, exactly.

Speaker B: So let's move on to kind of quite an interesting topic which is the fact that Warp has gone open source. So I think you did talk about this. Uh, 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. So talk to us about this of the why and the how. Uh, let's kind of go from there.

Speaker C: Yeah, so historically we'd always talked about this, thought about this, we revisited it every single year. You know, 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. And we think we can move faster now. I think we had some concerns around how do we actually manage the repo, manage external contributions. And so 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.uh warp.dev where we have like built this dashboard of what's going on in open source. And so we realize 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 agentic changes. On Warp we have a pretty rigid like or not rigid. We have a workflow that we like that's around like spec driven development for building on Warp and then we have really good verification that's also agent driven whether it's through our agent code review or computer use on Warps app, video based integration testing. And so we're just like, 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 and 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. And again, developers have totally different workflows and awesome ideas for how to improve the product. We pay for the agent like the inference for doing this by and large which is really cool model also. And we worked with OpenAI sponsors, the repo and pays for the inference for Oz there. And so it's just like a totally different way of building software. And then we do think having an open product here is something that developers should have. Like most of our competitors are actually not open source. In fact, I don't know if there is like another open source thing that's quite in the category of Warp. And there are 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. And so we think that there's a real opportunity for people who want to build this agentic workbench to get to contribute to it. So all these things made it feel really right at this time. And it's been very successful. We did it two weeks ago. I don't even know how long. Not long ago.

Speaker B: It was recent. Yeah.

Speaker C: 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. And so 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. But we've shipped a ton of fixes and improvements and people seem generally really, really psyched. So I'm very happy that we did it. It's so cool.

Speaker B: Yeah. I mean being a developer tool, it's just a huge signal when you're open source versus not so for sure it's the best way forward. I think that the how is. I'm always curious. We had uh, Convex on a couple of years back. Wow. At this point. And they had just gone open source when we had them on. And the how was Interesting. Just like how do you actually go from being a closed source repo to open like just any sort of interesting things there?

Speaker C: Yeah, so there's like the way that we actually had to do this. We had to like clean up the code base for one thing.

Speaker B: No more comments with expletives or that kind of thing.

Speaker C: You just have to work differently if everyone's looking at your stuff. So 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, like you could hack things in for particular customers before, you can't do that now. Making sure from a uh, commit history standpoint, no secrets, nothing sensitive. And so we ended up just doing a fresh commit history. It was just like there was too much over the period of five years of building Warp. It's too scary that there's going to be something sensitive from a security standpoint or a customer or PII standpoint in there. So we did a fresh version of that. We had to move all of our issue tracking. We had kind of dual issue tracking before of like public was GitHub issues and internal was linear and everything's moved on to GitHub uh, issues the public version of it. We had to publish our roadmap and 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. So we had to move all this stuff to be public. We wanted to think also really hard about, well, what were the forks we expected people to do 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 uh, 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. And so we could see someone built fork of that, it's fairly popular. And so we're building that into Warp as quickly as we can. And so it's been really awesome from a uh, signal perspective on what's important to developers to work this way. But yeah, lots of stuff to clean up the code base. A lot of work making sure, you know, checking for security vulnerabilities it's another thing, you know, people immediately found more. It's like again, there's pros and cons to working in the open. I would say it's a pro. These things were latent.

Speaker B: I would agree that it is a pro. It is a pro.

Speaker C: Yeah, yeah. These things were latent in our code base and all of a sudden we have people running every security tool in the world on our code trying to harden it. And so it's not surprising they found a couple things. Nothing too bad, but it helps us harden the security of it. So super interesting process.

Speaker B: Yeah. And I guess for those sort of detail oriented people, licensing, I believe it's agpl. So ie, not mit, not Apache. Could you just talk to us about that?

Speaker C: Yeah. So the overall Warp Code Base license is AGPL parts of it. We also open sourced our UI framework for anyone who wants to build a UI app. Uh, it's a pure Rust UI app, that's mit. But AGPL is what's called like a copy left license. So it's like 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. And so 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. People contribute. But 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 uh, we're MIT licensed, where someone could fork it and build a closed source business off of it.

Speaker B: Yeah, I think that's just sort of hot take here. I think that's probably the right way forward. We've seen some interesting cases of, let's say, VS code becoming something that is definitely not.

Speaker C: It has this weight on us very clearly. So that was the thinking behind the license.

Speaker B: Yeah. And it did always look a bit strange taking something that has, okay, VS code came from Microsoft. So it's not like that is financially a problem for them really. But I think there clearly was a huge community around VS code as well. And I think for them to then see their work kind of being taken and then repurposed and then basically sold almost as is on day one, I think that's That's a bit strange.

Speaker C: Yeah. So, uh, I think it's the right license for us. I also think because this is for like the product, it's a little bit different than if it were for like a library. Like, it's hard to build on a gpl, like libraries per se, because then, you know, it's like you got to open source your whole app to use some node library. That's like, annoying. I think at the product level, it feels pretty different to me to have it as an AGPL license.

Speaker B: Yeah. And in terms of contributing, I think you sort of described a model of agents doing the, uh, actual heavy lifting on the implementation. Community members focused on ideas, direction, verification, and then the actual Warp team itself kind of guiding the what gets built. Does that sound about right or how do you look at this?

Speaker C: Yeah, so I can walk through the process. Actually. It's kind of an interesting workflow. So 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. Uh, you can open an issue directly from within Warp, agentically by running like we ship a skill with Warp. This is called slash feedback, where you can either provide the bug report or the feature request directly from within Warp. And it will do a pretty good process of like, gathering the info, opening the issue for you. Once the issue is opened, there is an agent that runs on it which does triage. And so it will dedupe it. It will do an, um, initial complexity and feasibility analysis. It'll assign it to a part of the code base. And at that point someone from Warp will look at it and be like, there's a few steps that could happen from there. So one is 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 like what we call ready to spec. And that means it's like a more complex issue that shouldn't be one shot by an agent and instead there should be, we want to see product, uh, and tech specs, and the agent will generate those. But there needs to be like, this is how the feature is going to work, or if it's a hard bug fix, this is how the technology, like the architecture is going to work. And so that's a second thing we might do. And a third thing we might do is say like, not now. And I think we need to reserve the ability to be like, not now for Certain things because we really want the app to be cohesive and work super well. And so we view ourselves a bit as like editors here in terms of what should be built and when. But for let's say we're doing something where it's actually ready to be implemented, at that point someone is free to ask OZ 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. So I would suggest that people at least try to use OZ and like, we've also provided all of these skills that come with the repo for how to make effective changes. And it's not a simple repo. It's like over a million lines of custom Rust code built from the ground up. And so we do suggest people use that context. Unlike other open source repos, we really want people using agents. Like, I have more confidence in an agent driven workflow succeeding in getting merged than I do. And 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 like the way to build stuff on Warp right now. And so you will generate a priority with an agent. We will then have an agent. It's all odds. 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 like computer use, make sure integration tests. We do want people checking out and building and running the code. Like I don't have complete confidence yet of merging it, something that hasn't been verified by someone. But if they do that, then we'll do a real code review. Like 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. And 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 100 different people or something. It's really, really cool. And so that's the contribution process and it's letting us ship things that we otherwise definitely would not have been able to ship.

Speaker B: 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.

Speaker C: Definitely not. Yeah, it's made the bar for contributing. I don't want to say lower. It's Just made it wider. Ah, you could be any kind of

Speaker B: developer because that's what always strikes me with. Rust is an amazing language in many ways. People obviously, some very 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, you better be ready to find some far off developer who wants lots of money to come work on your thing.

Speaker C: 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 just, it gives everyone the chance to contribute to the apps that they use. Like no matter what your like technical background or capabilities. It's really cool.

Speaker B: Yeah. And then just kind of wrapping up uh, on this one I guess some people will be asking what is the business model? I mean you've mentioned inference, but that's like sponsored at the moment. Is Aus. Is that the sort of the paid product?

Speaker C: So yeah, we make money in two ways. So one is like if people use our coding harness, so we make money through that. Our harness is mostly on our server still. So we charge for that. Just to be clear, it's our client side app that is open, not the server piece of Warp. So we've maintained some parts of Warp that are closer to the business as closed source for now at least. Uh, we may open them too. I'm very into open source right now. And then the other thing is our cloud agent infrastructure is more like an infrastructure product. So 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 uh, like reselling inference. It's like we're selling infrastructure to companies that want to automate software development and that's Oz. And so that's more of our business.

Speaker B: Got it moving I guess on to just sort of as we start sort of cruise to the end of the episode. But the future, the future 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 installments 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 sort of thing that keeps coming up about junior developers and a, should they even get a CS degree? B, how do they get a job? Uh, initially, now all this kind of stuff.

Speaker C: 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. And so what we're seeing it as is it's like a force multiplier for productivity and there's infinite demand for software in the world. And so 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. So what matters less is coding, which is a weird thing to say about a junior developer. But what matters is do you understand the system? Do you understand how the product should work? Can you use agents super effectively? Like agents are like your new tool set. Are you adaptable? Because the way that these agents are working is changing every month or so. And so we've always hired smart generalists and I've never hired language specialists and I would just like triple down on that like smart generalists who can use all these tools is so valuable right now. And like CS degree, again, I would never view CS degree as like a vocational degree. I would view it as a degree where like you're learning problem solving skills, you're learning engineering skills. I would say like any STEM degree is probably really good for the future, to be honest. And CS is still really good.

Speaker B: Yeah. And um, somebody asked me, there was actually a VC asked me the other day, like how they could sort of encourage some of their FOIL companies to do more agentic coding because they sort of looked at what was going on and they looked in their portfolio and said or talked I guess to some of their follow companies and sort of didn't feel that they were doing enough, shall we say. And um, what would be the inroad that you would suggest there does Warp and Oz? Is that a really nice on ramp to all of this or. Yeah, I mean that's sort of obviously a biased question slightly, but yes, that's perfect.

Speaker C: That's the correct.

Speaker B: Yes, there we go. Just sort of just sales pitch right there. But yeah.

Speaker C: So yeah, when I'VE seen bottlenecks. So I guess a couple 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. And uh, 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 it was, you know, if you're a senior developer, you could write a better thing more quickly if you knew what you were doing than using an agent. And I think that has just flipped based on improvements in the models and the harnesses in the last six to nine months. And so I would try to get your senior developers convinced because the way that the influence tends to work in development orgs in my experience is it's the staff engineers, principal engineers embracing stuff and the junior engineers will come along and do it. So 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 like a horrible term. It uh, diminishes the craft of engineering. So I would call it agentic engineering. And 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. And if you embrace doing it and then I would like 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. And so like model it, show what you can do. And yeah, Warp is a great tool. It's like, I don't need to like 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 cloud code or Codex. OZ is even more of the future. It's letting you set up automations using these agents. So I think they're great tools for getting into it, for sure.

Speaker B: Nice. Well, I think that's a great place to leave it Agentic engineering over Vibe coding. And I definitely support uh, that. Definitely, definitely. So yeah. Zach, thank you so much for coming on. I think this has been super interesting, lots to cover and who knows, maybe I don't think we've ever had a guest on three times. So who knows, maybe in another three to four years. We'll have you back and, ah, we'll hear about the war evolution. Round three.

Speaker C: Cool. Well, it was a pleasure to come chat. Thanks for having me on.

Speaker B: Yeah, absolutely.