Ryan welcomes Zach Lloyd, founder and CEO of Warp, to the show to talk about reimagining the terminal. They also discuss why Warp was built in Rust (“it’s definitely harder”), how AI is transforming developer tools, and what Zach (formerly a principal engineer at Google) learned building Docs and Sheets.
Warp is an intelligent terminal that combines AI tools and developer resources in one interface. Zach’s hope was to give more developers access to the arcane magic of the command line.
Connect with Zach on LinkedIn.
If you’re a terminal user, which one is your go-to and why? Let us know at podcast@stackoverflow.com.
[intro music plays]
Ryan Donovan Hello everyone, and welcome to the Stack Overflow Podcast, a place to talk all things software and technology. My name is Ryan Donovan, and today we're going to be talking about the advances in the humble terminal. A lot of people, a lot of developers love to operate out of the terminal, but could it be better, could it have AI? We're going to talk to Warp founder and CEO, Zach Lloyd today. Welcome to the show.
Zach Lloyd Thank you for having me here, Ryan. Excited to be here.
RD So at the top of the show, we like to ask everybody how you got into the world of software and technology. What's your origin story?
ZL So I did a little bit of coding as a kid. I always liked computers. We had an Apple IIe and I remember coding some stuff, but for real I didn't get into it until actually freshman year of college when I decided to take a coding class. I remember very distinctly, it was the first time I'd ever done an all-nighter on an assignment. I was programming basically a Boggle game, trying to solve boggle, and I just got super into the puzzle-solving and the building aspect of it. And since then I've actually done some stuff outside of software but I've always kind of come back and really love working with tech.
RD And your current company, you’re the CEO and founder. How did you come to decide to jump from writing code to managing a whole business?
ZL That's a great question. So I was a professional engineer for a long time before I decided to found. So I was a principal engineer at Google, I used to be the engineering lead on the Google Docs and Sheets team. I loved building. I thought a cool challenge, though, after being at Google for a long time would be to see if I could build something outside of a big company. And there's a whole different set of challenges when it's kind of you versus the market as opposed to just you doing something at Google, you launch it, you're probably going to get millions of users just by virtue of Google's distribution and network. And so I thought it would be a cool way to challenge myself and try and build something useful on my own. And as far as working on this particular company, I was looking for pieces of software that I regularly use. So I am a developer, so I was looking at developer tools, I was looking at tools for knowledge workers, and I was looking for something where there really could be a big improvement made to the product experience, and it was something where it was widely used and there could be a big impact. And I kind of was like, “You know what? I use the terminal all the time. It's probably my least favorite thing to use, but it's essential.” And I know that I've always worked with developers who, if they get really good at using the command line, they can do sort of magical things very quickly. And so I was like, “Is there a way to bring that power to more developers?” And the more I thought about it, the more I was like, “Hey, I could think of a lot of cool ways to improve this as a product.” It wasn't super clear if there was going to be a good business around that, although that's changing now. But so I was like, “This would be a really potentially impactful thing to try to improve for a lot of developers.”
RD And that's right. Like we said, a lot of developers use a terminal. I remember walking around the last office I was in and just seeing every developer on the terminal all the time. We've written articles here about Emacs versus Vim.
ZL That's classic.
RD And it's interesting. A lot of the terminal productivity and power comes from knowing the sort of arcane spells you have to do to get everything to work quickly.
ZL That's right.
RD What's the sort of way you can give people that power user access without having them consult man pages every couple steps?
ZL So this is where sort of the rise of LLMs has been game-changing. In Warp, you can just tell the terminal what you want it to do in English. So let's say you want to set up a new project, a new node project. You could just write, “Help me set up a new node project, bring in the following dependencies, do it in this directory, initialize the Git repo.” Literally you can write that in English, you can even say it in English, and what will happen is that, through the LLM integration, something we call ‘agent mode,’ all of that prompt will be translated into a series of commands, and the computer won't just execute commands, it will gather context, check whether or not the command is executed correctly, and sort of agentically do what you tell it to do, which is a totally different paradigm than what I used to do of type the command, look up the flag someplace. Maybe you had completions configured, maybe you’ve got to bug your buddy on the team to be like, “How do I do this?” It's drastically lowered the barrier to entry of using what is one of the most powerful tools in the developer's toolkit, which is pretty awesome, to be honest. It's very cool.
RD That sounds pretty awesome. And I didn't use the terminal too much, but when I did, it was installing dependencies. Do you have a sort of automated gathering dependencies, installing them for you to sort of ease that process?
ZL So it works with anything. So if you wanted to install dependencies, what it would do is, you would point it at a project to be like, “Hey, I'm missing dependencies.” Maybe you would come there because there was some error printed in your console, and if there was an error printed in your console, Warp is smart enough to take that error message, figure out what you need. It has general knowledge of what's available via NPM or PIP or whatever and get you the dependencies. Also, if you want it to, you can have it literally be like, “Hey, look at my code base and figure out what libraries I'm using and make sure that my package.json is set up correctly.” It's super duper flexible and it can do that for dependencies, it can do that for you have a compiler that you need it to fix, it can do that for you have logs on a production server that you want to read. And so one of the cool things is that because the command line is such a low level tool in the developer stack and has so many different CLIs available, anything you can do in a CLI, the AI can help you do.
RD I was just thinking, you built up a whole new terminal system for this and I wonder if there's much difference between building an entire terminal program and just bringing something that interprets text within another terminal or CLI system. Is there much difference?
ZL It's a great question. So the quicker way to do what we have done is definitely to not write a terminal, but write a terminal app. And you actually see these things exist on the market. I don't know if you've played with Claude Code, but Claude Code is Anthropic’s new terminal app, and you tell it what code changes you want and it does it. There's various other things that work in the terminal like this and that's definitely much less work, however, when you actually write the terminal and the platform app, you can do things in a much richer way from a user experience perspective. So if you're limited to being a terminal app as opposed to the terminal, all of your rendering has to be done via characters, the mouse interactions don't work, you can't do any kind of interactive GUI elements. It's literally one of those apps, the way that they work is they're just using the terminal screen as a place to write characters. Whereas if you actually are Warp and at the level of the terminal app, it's kind of like the difference between being the browser and a webpage. If you're the browser, then you can do whatever you want outside of the webpage context. So we can sort of read the output of different terminal commands and different programs and do intelligent things on triggering how the AI interacts, where if you're in the sandbox of being one terminal app, you can't do that. So it's a great question though.
RD And you talk about using other terminal apps in that other command line. Do you run those within the terminal or are you just calling those separately?
ZL There's different ways of doing it, but to give a concrete example of something that we can do that is really cool, so we can actually give you AI assistance in any terminal app. So say you're running the PostgreSQL REPL, so PSQL, and you want to interactively query your database tables. So without the PSQL REPL having to do anything to build an AI feature, Warp by virtue of the fact that we know that you're running PSQL, can within that program, make it so that you can be like, “How do I join these two tables together?” and it will generate the SQL query for you. So again, being one level up lets us interact with those apps in a pretty powerful way.
RD I think the AI is an interesting add to a terminal application because terminal applications, like we talked about before, is sort of about knowing the secret codes. A lot of devs value that as a technology. So if somebody wanted to just write in a regular terminal code without the AI, they'd be able to do that?
ZL Yeah, and that's how Warp started. So Warp’s initial value to a user was actually just a much more usable terminal interface. And so Warp is fully backwards compatible, so you use it to run, you can run bash, fish, csh, any of your common shells. And say you don't want to use AI at all and you're like, “I don't like AI, I don't want AI in my terminal,” the value of Warp is still there, you get a much nicer user experience. So literally the first feature that we launched within Warp was to make the mouse work when you're inputting long terminal commands, which is a crazy thing to say, but if you're using a regular terminal like iTerm or the VSCode terminal and you try and click and put your cursor someplace, doesn't work, doesn't do what you expect. And so we tried to fix a bunch of those, just I consider annoying, old school usability issues. So if you want to use Warp like that, by all means, do it. That will definitely improve your productivity, but the AI features I think will transform your productivity. So it's there for however you want to use it.
RD I know that is a big frustration. It almost seems like a lot of the terminal command line stuff was built before GUIs.
ZL Oh, it was. That's right.
RD The Windows CMD is just like, you haven't updated that since like ‘85 and it's just fine.
ZL I mean, we just launched on Windows and we're working with the Windows terminal team and they just have crazy requirements around backwards compatibility because there are big enterprises that are still running 16-bit programs through command.exe and if you were to ever mess with it, it will break things that will cost the economy a lot of money. So it's very, very old school technology and the compatibility aspect makes it kind of hard to change, to be honest.
RD Oh, so you have to respect that backward compatibility when you're releasing a new terminal in Windows?
ZL Yeah, or you have a choice as someone who's developing an app like this. So you can respect the compatibility which is what Warp has tried to do by and large, or you could be like, “No, this thing needs a wholesale reinvention and it's too hard to make it work with the old stuff,” and that is kind of freeing if you go that route, but the problem is it just makes it very hard for people to adopt unless they're totally new to the ecosystem. So we wanted to build something that existing developers could just open up and it would work in a way that they expect with their existing scripts and all of that. So we went with the way of trying to innovate while still being compatible.
RD And you built the terminal in Rust, is that right?
ZL Yeah.
RD Can you talk a little bit about the decision to use Rust and whether you eventually found it better or you had regrets?
ZL So we're happy with the decision. So the progression was we actually prototyped Warp with webtec and Electron just to understand if the product idea was compelling, and then we switched to Rust after finding that it was just going to be very hard to get the performance to the level that we wanted. That was the primary motivation, and my background of building these pretty data-intensive web apps at Google, like Google Sheets for instance, you want it to have performance at the same level of Excel. It's really, really hard to basically impossible to do that in webtec, or at least it was when I was trying to do it, and I don't think it's fundamentally changed that much unless you use something like WebAssembly and WebGL, which is actually what we do. So we have a web rendering and we can pile up our Rust into WebAssembly WebGL. So we were like, “If we're not going to use webtec for this, what's a solution that is high performance, that is cross-platform, that has good community?” I really like working in sort of strongly typed languages and so we went with Rust. It's definitely harder. It's a steeper learning curve for a language. We have to do more. So for instance, we have our own full graphics stack that we wrote, so we do all the rendering on the GPU. So even up through shader code, we have that in Warp, which is not an architecture I would recommend for most apps, just to be clear, but we're pretty happy with where it landed in terms of super high performance and we've been able to successfully use 90+ percent of the same code base on Mac, Linux, Windows, and the web. The only other stack that I think you could really do that with would be the web stack, so it worked out pretty well.
RD That's interesting you talk about having to write your own rendering stack for a terminal application. What things does a terminal application need to render and needs shaders, did you say?
ZL So great question. So the primary requirements for rendering terminal apps are, honestly, we could render almost any graphics. You need to be able to render text, so that's glyphs. You need some variant of rectangles, rounded rectangles, rectangles with borders. So there's one sort of code path for rendering, just rectangle rendering. There's one for image rendering so if you're doing icons, and that's kind of it for our primitives, which is crazy to say. There's very few primitives, so to do all of the graphics in a terminal app, we probably have less than 500 lines of shader code. Now there's a whole UI framework on top of that that looks something like Flutter where you go one level up and you define abstractions for making rectangles and image elements and hover effects and all that stuff, but the actual graphics code is very minimal. It's pretty cool.
RD So in terms of actually using the terminal, do you use it yourself to write code?
ZL Yep. That's our thing that we live in. We use it to do kind of everything at this point, everything from Git in production stuff to increasingly, like you said, actually just telling it to write code, and it will produce code and show you code diffs, which is pretty awesome.
RD I've been talking to one of our engineers here. Their sort of hot take is, when you're dogfooding like that, I hope your experience sucks. Do you feel like that was your experience at any point and was that useful?
ZL Oh yeah, the thing was horrible at the beginning, but I think your engineer is right. If you don't feel the pain that you're doing something wrong, and for us, we want stuff in our dogfood build as fast as possible. Our kind of rule of thumb these days is that it probably shouldn't slow us down, but as long as it's something that's not going to actively harm the productivity of our engineering team, it goes on to dogfood even with a million rough edges. But the first time I felt like people might actually want to use Warp was when we were able to use it successfully ourselves.
RD How easy/difficult was it to get the AI piece working in there?
ZL So we've had various iterations of it. So we had AI even before ChatGPT launched. We were using Codex, which was a different coding API from OpenAI. When ChatGPT first came out and the GPT models first came out, we sort of did the thing that a lot of companies did, which was we stuck a chat panel in Warp with AI, which was by far the most expedient way to get that experience into Warp. And then nine months ago, we ripped that chat panel out and made it so that the primary terminal input is how you interact with AI, and that was a much bigger change and a much deeper integration. So when you use Warp, you type a command or you type English, and in much the same way where if you use Chrome the browser you can either type the URL or you can type a search query, that's how Warp now works. And making that change and interleaving the AI directly within the terminal session, that was a much bigger engineering effort from the user experience standpoint. And then we've made the AI way, way, way more powerful and sophisticated, so we're adding things like that it understands your code base context, it can create code diffs, it can delegate to different models based on what type of task you're doing, it can help predict the next command that you're going to type. And so most of our team, not all of it, is now working on how we make the intelligence aspect of Warp most useful for people.
RD Do you have any sort of agentic aspects? Can your AI use tools or inference time data sort of reasoning stuff?
ZL Yeah, so it's super agentic. So the tools that it has, the first tool actually and the most powerful tool is it has access to use any CLI. So for instance, if it wants to read a web page, it can cURL it. If it wants to make a pull request, it can use the GitHub CLI. If it wants to understand process usage on your computer, it can run PS. And so one of the cool things about having AI in the terminal is that you don't have to do a one by one tool integration to give the AI power, the AI has the power of all of your command line apps and it can actually help you install new ones too. So that's the first tool that it has, but we have added more tools. We've added a very specific code writing tool which can give you diffs in your code files. We're looking at integrating MCP– model context protocol. You can get your Slack messages or your Notion or that kind of stuff. But the short answer is anything that has either a CLI or if it has an API that's callable via cURL, it's already usable directly in Warp, which is amazing.
RD That is interesting. I've talked to folks from other companies doing API AI stuff and it almost sounds like we're moving to a future where there's going to be one thing that you interact with that does everything for you. Do you think a terminal will be the sort of dev one thing?
ZL It's possible. So if you look at the popular IDE-based AI tools like Cursor or Windsurf or Copilot, what you see is that the agentic features in them have kind of started as chat panels that can do agentic stuff and are kind of morphing into something that feels a lot more like a full-fledged command line interface. And it's interesting, so Anthropic’s Claude Code literally is a terminal app, so it's like they're kind of moving back to the command line paradigm. I don't know exactly what it's going to look like, but I do think the terminal is really, really well set up for it as you think about agentic stuff. The terminal is already a place where developers naturally are telling the computer what to do. It's already a place where there's a concept of a long running task. It already allows for multitasking, which I think is something that's coming with a lot of these agent platforms. So a lot of the primitives for an agentic future where developers are telling the computer what to do are kind of there in the terminal, which would be a crazy full cycle thing if that's where people end up. I don't know if that is what will happen, but I do know that there is a lot going for it and a lot of value that our users are getting from these agentic features in the terminal right now.
RD I mean, you always want to get your software or whatever where the people are working, where they’re living.
ZL Exactly. One of the other things that we see happen a bunch in Warp is people coming to Warp because they might just want a better terminal. They've heard from a friend, “Hey, this is really nice to use,” and then what we're able to do is surface some sort of wow moment for them in AI that they may not even have thought to do. But let's say in the course of doing their normal work they hit some missing dependency. Well, we can be like, “Hey, do you want us to just install this for you or fix this messed up node modules thing for you?” And no developer wants to spend their time doing that, and so if we can just do that for them, it's an amazing aha moment where that's like, “Oh, I actually kind of like this. I didn't think I liked AI, but I don't like fixing node module errors and so this is awesome.”
RD Sure. If I have five different versions of Python on my computer, can you pick the right one?
ZL Because no developer I've ever met wants to spend time on that stuff and so to the extent that the AI can help with the really annoying parts of their job, it's pretty awesome.
RD So what are you most excited about the future of either the terminal or AI or AI in the terminal?
ZL So I think this is the coolest time ever to be working in the dev tool space. It's way cooler than when we started Warp. It's cooler from a business perspective, it's cooler just from a ‘what the heck is going to happen’ perspective. I think no one knows exactly where things are going, but the bet that we're making is that the models are going to keep improving, they're going to keep getting better and better at reasoning. That's going to allow for more and more autonomy for them. But we think that it's going to be the developer's job to actually sort of manage this autonomy and learn how to use it effectively, and we're not of the position that the right direction is to replace developers here. As a developer, what I want to do is multiply myself, multi-thread myself, allow myself to do more and have kind of more output building stuff that I'm interested in, less time doing annoying stuff. And so to the extent that Warp or any of these other developer tools companies can bring about that future, I think it's a super exciting time to be in this space.
[music plays]
RD Well, that's the end of the show, ladies and gentlemen. And while we usually shout out a question on Stack Overflow, I'd like to try something different and ask you all a question. What terminals do you use and how much time do you spend in it? Email me at podcast@stackoverflow.com and we may feature it in a future blog post. My name is Ryan Donovan. I host the podcast, edit the blog here at Stack Overflow. You can find the blog at stackoverflow.blog. And if you like what you heard today, leave a rating and a review. It really helps.
ZL So I'm Zach Lloyd, I'm the founder and CEO of Warp. You can find Warp at warp.dev. We're now out on all platforms which has been a very long-standing feature request, so if anyone has heard about Warp and been waiting to try it on Windows, we're now officially launched. But this has been an amazing conversation.
RD All right, everyone. Thank you very much for listening, and we'll talk to you next time.
[outro music plays]