The Terminal as an Agentic Interface

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 https://www.warp.dev/ 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 https://x.com/zachlloydtweets is the co-founder and CEO of Warp, and a former principal engineer at Google where he led engineering on the Google Docs 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. Sponsorship inquiries: [email protected] mailto:[email protected] The post The Terminal as an Agentic Interface https://softwareengineeringdaily.com/podcasts/the-terminal-as-an-agentic-interface/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  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,

• 0:46Speaker 00

  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 Oz approaches the governance and auditability challenges enterprises face with AI agents, and more. Gregor Van 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.

• 1:32Speaker 01

  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.

• 1:43Speaker 02

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

• 1:44Speaker 01

  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 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 the full version, but what's the kind of like TLDR of how you ended up building Warp?

• 2:05Speaker 02

  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 the 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 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.

• 2:48Speaker 02

  With Warp, I'm really trying to build something that's very useful for developers. And honestly, increasingly, like 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.

• 3:03Speaker 01

  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 sort of like beautiful, fast, Rust-based terminal. You know, trying to bring command line, you know, into like the 21st century. Cause you know, 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, like.

• 3:41Speaker 02

  Well, it's more than the warp is, it's not just the warp has changed. I'd say like, obviously the world has changed. The world of what it is to be a software developer is just fundamentally different.

• 3:52Speaker 01

  Yeah.

• 3:52Speaker 02

  So I would say like the warp journey is right, the way you talk, the way you described it. So, you know, 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 is a really important app. It's where developers spend a lot of their time. It was, you know, the terminal and the code editor, I've always said are like 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 the command line. Like you said, it's it's Rust based, has some very distinct features compared to a normal terminal.

• 4:34Speaker 02

  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. We have this feature where we separate the terminal outputs into blocks. It makes it more readable. You can take actions on them. So those were the 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 I had the, 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 what we were using it for was we would translate English into terminal commands. So it was really like translation, not like a agentic capability.

• 5:19Speaker 02

  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 we brought in like a chat panel in like 2023 into Warp. But that, we realized that was actually like a sort of stupid implementation. Like the terminal itself is almost like a chat interface in a lot of ways.

• 5:59Speaker 02

  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 like, didn't do the more like 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 ask in English, we had this thing called agent mode, which is a term that we actually coined, which has been adopted.

• 6:41Speaker 02

  And it would basically do whatever you asked it 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. And the distinct thing about Warp's coding agent versus like Claude 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 we could, we could talk about this in a bit, we're moving these coding features into the cloud. So we've, 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.

• 7:23Speaker 02

  And so we're just kind of, you know, 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, that's the, the evolution.

• 7:37Speaker 01

  Yeah, nice. And at least back then, the vision, I guess, was, you know, things like multiplayer. Has that kind of survived vision wise?

• 7:45Speaker 02

  It has. So it's like, the whole world has kind of moved in our favor, kind of through luck. So yeah, the, 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 like a link to the commands 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 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.

• 8:30Speaker 02

  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 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.

• 9:03Speaker 01

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

• 9:15Speaker 02

  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. 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.

• 9:56Speaker 02

  It wasn't programmably customizable. Our settings were kind of limited. We were like, this is how it should work.

• 10:01Speaker 01

  I feel like there were a lot of products around that sort of time that were that kind of.

• 10:05Speaker 02

  Yeah, I would say like a linear.

• 10:07Speaker 01

  Ultra opinionated. Yeah, yeah, so yeah, yeah.

• 10:10Speaker 02

  Notion, like, this is like the school of product development. I was like, we're just building a better thing. 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 like a good opinionated set of defaults.

• 10:51Speaker 02

  But the way that I think about developer product is much more like developers themselves have strong opinions and varied workflows and we want to let them hack on Warp and customize it. And like, you know, some people like their tabs looking like one thing, some people like it 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.

• 11:22Speaker 01

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

• 11:33Speaker 02

  Exactly.

• 11:33Speaker 01

  And then others would like love to use like the most kind of visual IDE possible.

• 11:38Speaker 02

  Yeah.

• 11:38Speaker 01

  But both are developers, but like very opinionated on what they want to use.

• 11:43Speaker 02

  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 it has totally changed.

• 11:54Speaker 01

  Yeah, that's super interesting. So I guess like, looking at where things have gone, you know, we've got obviously like Claude Code, Codex, Genai CLI, like, do you think you saw that coming? Like, at least I definitely didn't, I mean, in the sense that, you know, I still, I was just at a conference, I think, a couple of weeks back in SF, and I'm still amazed at like, 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.

• 12:23Speaker 02

  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 like, 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 like, the IDE is, it's like Microsoft Word for your code. Like, 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.

• 13:02Speaker 02

  And so I feel like we were pitching that code editing was going to be like a secondary thing that developers do pretty early on. And by pretty early on, I mean like mid 2025, like we're not talking like three years ago or something, but like 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 what to do in English. And so, you know, it 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.

• 13:43Speaker 02

  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.

• 14:01Speaker 01

  Yeah. And Warp does explicitly support Cloud Code, Codex.

• 14:06Speaker 02

  Yes.

• 14:07Speaker 01

  JMLI CLI, Open Code. Clearly you've decided to be like very, I guess, agent agnostic. What is like supporting these? Like, what does it actually entail? Like from a, like, let's go a bit technical for a second. Like, what does it actually entail when you have to think, well, we're going to explicitly support these and give like a first-class experience?

• 14:25Speaker 02

  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 toolset 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 notification.

• 15:06Speaker 02

  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, Fish 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 and 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

• 15:49Speaker 02

  agent skills or via plugin system. Like 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 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

• 16:32Speaker 02

  trying to make that feel more natural and more powerful.

• 16:36Speaker 01

  Yeah.

• 16:37Speaker 03

  You're building agents that can write code, summarize documents and automate workflows, but they're missing one thing, 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 Vaisala, whose instruments fly on NASA missions to Mars, XWeather delivers trusted data and unique insights that go beyond conditions to actual impact. From real-time lightning strikes to road surface forecasts. Start with 15,000 free API calls every month and pay only for what you use as you grow.

• 17:18Speaker 03

  Your full weather stack for developers by developers. Start building for free today at XWeather.com.

• 17:26Speaker 00

  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 GuardSquare comes in. 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, multi-layered 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.

• 18:11Speaker 00

  Secure your mobile applications today. Go to guardsquare.com to learn more.

• 18:18Speaker 03

  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 six times faster fixes. Free for developers. Get started at www-endorlabs.com/auri.

• 18:52Speaker 01

  I guess when I look at, I just, 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 sort of case. 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?

• 19:26Speaker 02

  That's not totally wrong. Like, 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.

• 19:39Speaker 01

  Great.

• 19:40Speaker 02

  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 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 than 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 his context and know what files the agent is creating. And so our like guiding principle here has been like, well, there's new technology.

• 20:23Speaker 02

  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, you know, people using it the most productive. And so, yeah, we, we've brought in some features that are more traditionally IDE like, I'm cool with that.

• 20:47Speaker 01

  Yeah.

• 20:47Speaker 02

  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 like, let people control this and control how they do it. But I, I think that is actually a sensible default these days is these are useful things if you're building with agents.

• 21:01Speaker 01

  Yeah, I really like that distinction where like just sort of thinking of it as like 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, a window of, of code. You know, and I think that's sort of where that distinction is.

• 21:18Speaker 02

  Totally. And like by having the main view be the terminal, like in the typical IDE, you'll have like N files open, like 10 files open in one terminal. And in the typical agentic development setup, you might have like 10 terminal windows open and just one diff view that's focused on whatever your current change is. So I think you just, we've like converted it. And it's interesting, you'll notice everyone's converting to that design because it makes sense. Like if you open cursor today or whatever their, their 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.

• 21:55Speaker 01

  Yeah. And then just looking at Claude Code, for example, it does run in Warp. Equally quite, you know, can easily be seen as a competitor, I guess, as well. Like, how do you sort of look at the 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 like, rising tide raises all boats kind of thing? Like, how do you look at that?

• 22:18Speaker 02

  It's a really, really interesting landscape and our, the way we've looked at it has changed over time. So we, we do have like a built in coding agent to Warp and that does generate a bunch of revenue for us. And it's an awesome coding agent. Like, we at various times have been at the top of the different benchmarks, like Terminal Bench, we were top three on Sweet Bench. But developers just want to try different stuff. And so our overall strategy right now is not to like, 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, they want to use Codex, they have contracts with Codex.

• 23:00Speaker 02

  And so like, 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. And, you know, Warp will cross a million active developers this month, which is really exciting. And like, we want to be part of like the chain of building with AI. And, you know, we think there's a lot of strategic value in that. And like, our like, business bet is less on the like, interactive coding agent within Warp than it is on like, helping companies that want to build software factories internally and automate software development. And like, like, that's, I think, where our business will have last CMO.

• 23:45Speaker 02

  And with the developer facing side, we want to just have as many developers using it and like liking it and helping that as be part of our like funnel and do a more of an enterprise business. So that's how I'm thinking about the strategy currently.

• 23:59Speaker 01

  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 source. 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?

• 24:19Speaker 02

  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 debt 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

• 24:59Speaker 02

  companies, so Oz is primarily an enterprise 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 features for automating software development that come with Oz, where we think every company is going to want something

• 25:44Speaker 02

  like this. Some companies will build it, but most companies will buy something like this. And so that's, 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.

• 25:59Speaker 01

  Yeah, I mean, maybe just talk to us a bit more about the auditability side. I mean, that's, 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. You know, like Singapore is a sort of sales hub for technology and it was all about, it was all about agentic, but it was all about sort of, but 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. Like, how do you know?

• 26:23Speaker 02

  Yeah, totally.

• 26:24Speaker 01

  Yeah, yeah, yeah.

• 26:25Speaker 02

  I mean, so.

• 26:26Speaker 01

  So yeah, just, so what does that look like, I guess?

• 26:29Speaker 02

  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.

• 26:54Speaker 01

  Yeah, at least we're recording in May, May 12th. So yes.

• 26:58Speaker 02

  Yeah, May 12th. Yeah, exactly. So on this particular day, I don't know that that will be true, you know, indefinitely. And so what has happened is you will see, I think it was like the head of engineering at Uber was, 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.

• 27:39Speaker 02

  And I think that people are waking up to, you know, 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 can go back and trace what happened. How did it have those tokens? What do we need to lock down?

• 28:19Speaker 02

  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, you know, 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, like now it's, 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.

• 29:00Speaker 01

  Yeah. And I mean, on the deployment side, I guess, is it sort of fair to say this is feels a bit like a sort of C I C D infrastructure? Or like, do you see like a totally new category? Or how do you see that?

• 29:13Speaker 02

  It's in the C I C D family, I would say, has like slightly different characteristics than C I C D. Like 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 that is controlling what other agents are being launched, what other agents, what permissions they have, what their subtasks are. You need more flexible, like permissioning. So I think it's like, it's in the C I C D realm,

• 29:58Speaker 02

  but it's, it's not exactly that same execution pattern. And so for us, we integrate it into C I C D. You can run it from within C I C D. 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. And so I think it's, it's A more flexible, more interactive thing than just like a very rigid CI/CD pipeline. It's more like teammates, I think is where it's gonna end up, to be honest. It's gonna 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.

• 30:39Speaker 01

  Yeah, that makes sense, because I think like an example is like an issue triage app, for example, like this sort of like tackles GitHub issues. So like, that feels like a teammate to me.

• 30:51Speaker 02

  Yeah, exactly.

• 30:52Speaker 01

  So let's move on to kind of a quite an interesting topic, which is the fact that Warp has gone open source. So I think you did talk about this, I believe, like 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. Let's kind of go from there.

• 31:15Speaker 02

  Yeah, so historically, we'd always talked about this, thought about this. We revisited it every single year. You know, Warp's 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 that got me to believe that this was like a smart thing for us to do was the state of agentic development. And we actually, we think we can move faster now. I think we had some concerns around like, like, 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

• 32:00Speaker 02

  or to go to build.warp.dev, where we have like built this dashboard of what's going on in open source. And so 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 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 Warp's app. Video-based integration testing. And so we're just like, we think that we can actually

• 32:42Speaker 02

  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 like coding, verification, triage, all of the stuff that can be like a lot of work around open source and then have the community provide a bunch of ideas, guidance, you know, we still are like manually testing everything. It's really cool because the community is fixing issues that, you know, we dog food warp extensively, but we're, you know, we're not using warp in Chinese or for instance, we're not using it constantly with like IMEs. We use it way less on Windows and Linux than we do on Mac.

• 33:25Speaker 02

  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 that 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 not, 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.

• 34:07Speaker 02

  There's obviously VS Code, but VS Code is still very much an IDE. And so, you know, we think that there's like a real opportunity for people who want to build like 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. Like we, you know, we did it two weeks ago? I don't even know how long, not long ago. It was recent, yeah. And we more than doubled our GitHub stars, like 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, you know, it's a bunch for us to figure out exactly how to like work with the community and make sure we're doing a good job there.

• 34:52Speaker 02

  But we've shipped a ton of fixes and improvements and people seem generally really psyched. So I'm very happy that we did it. It's so cool.

• 35:01Speaker 01

  Yeah, I mean, being a developer tool, it's just a huge signal when you're open source versus versus not. So for sure, it's the best way forward. And I think that the how is, I'm always curious, we had Convex on a couple, a couple of years back. Wow, at this point, and they had just gone to 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 to open? Like, just any sort of interesting things there?

• 35:28Speaker 02

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

• 35:36Speaker 01

  No more comments with like expletives or that kind of thing, yeah.

• 35:39Speaker 02

  You just have to work differently. If everyone's looking at your stuff, we spent, so the, 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. You know, making sure from a commit history standpoint, no secrets, nothing like 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 is 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.

• 36:20Speaker 02

  We had to move all of our issue tracking, like, we had like, kind of dual issue tracking before of like, public was GitHub issues and internal was linear and everything's moved on the GitHub 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, you know, so we, 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 like, see around the corner on those and see if we could build the functionality for doing that. And the forks that people want are not surprising to me. And so we're, but now we have a bunch of signal.

• 37:04Speaker 02

  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 like fairly popular. And so we're building that into Warp as you know, as quickly as we can. And so it's been really awesome from a like signal perspective on what's important to developers to work this way. But yeah, lots of stuff to clean up the code base. 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, like these things were latent.

• 37:42Speaker 01

  I would agree that's it is a pro, it is a pro, yeah.

• 37:45Speaker 02

  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 like a couple of things, nothing like too bad, but it helps us harden the security of it. So super interesting process.

• 38:01Speaker 01

  Yeah. And I guess for those sort of detail oriented people licensing, I believe it's AGPL. So I not MIT, not Apache. Could you just talk to us about that?

• 38:13Speaker 02

  Yeah, so the like overall Warp code base license is AGPL. Parts of it, like we also open source our UI framework. For anyone who wants to build a UI app, it's a pure Rust UI app. That's MIT. But the 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 like 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 that it'll become a better product, people contribute.

• 38:58Speaker 02

  But you know, if someone wants to build another business off of it, they're going to have to build like 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 like a closed source business off of it.

• 39:11Speaker 01

  Yeah, I think that's just sort of hot take here. I think that's, I think that's probably the right, the right way forward. I mean, we, we've seen some interesting cases of, you know, let's say like VS Code becoming

• 39:21Speaker 02

  Exactly.

• 39:21Speaker 01

  Something that is definitely not-

• 39:22Speaker 02

  This weighed on us very, very, very clear. Like, so that was the thinking behind the license.

• 39:28Speaker 01

  Yeah. And it did always look a bit strange, you know, taking something that has, okay, it came, 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, and then basically sold almost as is on day one.

• 39:50Speaker 02

  Right.

• 39:50Speaker 01

  I think that's, that's a bit strange.

• 39:51Speaker 02

  Yeah. So I, 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've 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 like a GPL license.

• 40:18Speaker 01

  Yeah. And in terms of contributing, I think you sort of described a model of like agents doing the actual sort of heavy lifting on the implementation, community members focused on like ideas, direction, verification, and then the actual warp team itself kind of guiding the what gets built. Like, does that sound about right? Or like, how do you look at this?

• 40:39Speaker 02

  Yeah, yeah. So I, I walked through the process. Actually, it's kind of an interesting workflow.

• 40:43Speaker 01

  Yeah.

• 40:44Speaker 02

  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. You can open an issue directly from within warp agentially 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, 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 dedupit, it will do, and like- Initial like complexity and feasibility analysis, it'll like assign it to like a part of

• 41:26Speaker 02

  the codebase. 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 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 market 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 a product 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 the second thing we

• 42:08Speaker 02

  might do. And the third thing we might do is say like, not now. And I think we need to like, reserve the ability to be like, not now for, for certain things. Cause there's, you know, we, we really want the app to be cohesive and works 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

• 42:52Speaker 02

  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 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 like the way to build stuff on Warp right now. And so 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.

• 43:36Speaker 02

  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, saying it 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, like, you know, it's gotta be a good app. And so we, we, we do that and then we merge it. And I don't know the exact number, but we've had like over 500 people have like created contributions. I think we've merged over PRs from like 100 different people or something. It's really, really cool. And so that's the contribution process and it's, it's letting us ship things that we otherwise definitely would not have been able to ship.

• 44:19Speaker 01

  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.

• 44:28Speaker 02

  Definitely not.

• 44:29Speaker 01

  No.

• 44:31Speaker 02

  Yeah, and it's, it's made the like bar for contributing. I don't want to say lower, it's just made it wider, like, like.

• 44:37Speaker 01

  Yeah.

• 44:38Speaker 02

  You could be any kind of developer.

• 44:39Speaker 01

  Cause that always, 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, but it is still a bit of a niche language. Like, if you're gonna build something in Rust, you better, you better be ready to find some far off developer who wants lots of money to come work on your thing.

• 44:58Speaker 02

  We're just like 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 sort of 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, you're like technical background or capabilities. It's really cool.

• 45:32Speaker 01

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

• 45:44Speaker 02

  So yeah, we make, 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 servers still, so we still, we charge for that. I should 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 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. 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 versal model or something like that where we charge companies for orchestrating

• 46:25Speaker 02

  cloud agents and we're not making money there necessarily, even on 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.

• 46:38Speaker 01

  Got it. Moving, I guess, on to just as we start to 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 SCD news monthly installments, where we're sort of like, where are things going? How do junior developers get, get in the door? You're quite close to this, I think. Like, 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 CES degree? B, how do they get a job additionally now? All this kind of stuff.

• 47:17Speaker 02

  One data point here is we're hiring and like we're hiring at all levels of seniority. And it's never been more competitive for us to hire extremely talented people. Like we have a really amazing team. And so what we're seeing it as is like, it's like a force multiplier for productivity and there's infinite demand for software in the world. And so my expectation is that like, 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 is coding.

• 48:01Speaker 02

  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? Like agents are like your new toolset. 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 agentic tools is so valuable right now. And like CS degree, again, I would never view a CS degree as like a vocational degree.

• 48:46Speaker 02

  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.

• 48:58Speaker 01

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

• 49:31Speaker 02

  Yes, that's perfect. That's the correct.

• 49:33Speaker 01

  There we go. Just sort of just sales pitch right there. But yeah, so.

• 49:36Speaker 02

  When I've seen Bottleneck, so I guess a couple of thoughts here. One is I feel like that's actually less and less common. Like, 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.

• 49:52Speaker 02

  The like reticence from the senior developers at the time, I think, was like pretty warranted in that, you know, the agents couldn't do as good of a job and, 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 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. So I would try to convince that cohort that there is a way to do engineering with these tools that produces

• 50:36Speaker 02

  a better quality product more quickly. I would not call it vibe coding. I think that that's like a horrible term. It like diminishes the craft of engineering. So I would call it agentic engineering. And I would say that there is like a new standard of doing development that's actually really fun and empowering. And like, it just moves the abstraction layer for engineering up one level 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 Warp is a great tool. It's like, I don't need

• 51:19Speaker 02

  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 like letting you like set up automations using these agents. So I think they're great tools for getting into it, for sure.

• 51:38Speaker 01

  Nice. Well, I think that's a great place to leave it. Agentic engineering over vibe coding. I definitely support that. 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 have you back. And we'll now, and we'll hear about the Warp Evolution Round Three.

• 52:00Speaker 02

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

• 52:03Speaker 01

  Yeah, absolutely.