Give us some context on what Warp is and what you're building. Specifically, where in the value chain of software creation are you spending most of your time?

Warp is a reimagination of the terminal. The basic concept behind it when we started was that the terminal is used by pretty much every developer every day, and it has a UX that hasn't really changed in the last 40 years. So we said, let's rethink this UX from the ground up and try to make it more powerful and usable.

When LLMs came around a couple of years ago, we, like every company in the world, asked how this technology could apply to what we're doing. And it turns out it applies super duper well. So the modern version of Warp is that instead of just entering commands in your terminal, you can just tell the computer what you want to do through the terminal.

The terminal is a very cool layer of the stack to do that, because it has access across all your projects, and it's also useful across the whole software development lifecycle. From setting up a project to coding it, to deploying it, to debugging it in production, you can do all of that through AI directly in the terminal. So that's what we're working on. That's what I spend my days thinking about: how are LLMs best used to help developers get more done?

If you bucket up the different jobs developers spend the bulk of their time on, what has changed most dramatically? And maybe more importantly, what is going to stay the same?

The most dramatic change so far is in the code writing phase, the code generation phase. The first place where there's been a really huge impact is with things like Cursor and Windsurf and Copilot, where what you get is great autocompletion. You're in the tool, you have the file open, you're about to type something, and AI reads your mind and says, "Oh, no, you want these few lines." I think that's probably the bulk of where the impact has been so far.

What is about to happen, and is already happening to some extent, is that rather than just helping with these local changes in the hand-editing interface, developers are increasingly going to delegate much bigger tasks to AI. That means they're going to prompt AI to build a whole feature or to fix a bug, or in the case of Warp, those things but also figure out an issue in production, or set up a new project and figure out why all your Python dependencies are wrong. So the complexity of the tasks AI is starting to tackle, and the agent-like interface you need to do that, is what's changing most right now.

Going back to the second part of the question, what is going to stay the same? Once you unpack what a software developer is, it's often going to be the first-principles things, regardless of how you're being augmented.

What's going to stay the same is that under the hood, the job of the software developer is to produce working code and to get from idea or spec to working code. A lot of the principles that make a good software engineer a good software engineer are still going to apply, whether you are working through autocomplete or you're working one layer higher, where you're trying to tell an agent what to do.

What I mean by that is that good engineers understand the way the entire system works. They understand that you make more reliable and maintainable systems if you architect them in a composable way. They understand that if you're going to build something big, it's probably best to build it in little pieces. If you're vibe coding something, a lot of the time what I see is people saying, "Here's a prompt to build all of Airbnb." No professional software developer would ever say, "I'm going to build all of Airbnb in one PR." So I think the same principle applies in terms of how you decompose problems when you're using these AI-powered tools to help you along the way.

One of the hot takes that has gone viral is the idea that nobody needs to learn computer science or how to program anymore, because vibe coding is strong enough and will keep getting better, so that's an outdated requirement. What's your take on that?

I think that's bad, bad advice. I do think the level of abstraction is going to go up, so I agree with that. I do think the amount of code that will be written by AI is going to go up. But it's more that the software engineer's job is going to evolve into being a manager of AIs, and to actually be a good tech lead or a good manager, you need more knowledge, more expertise. You need more systems design skills.

In the buckets you're talking about, there's the vibe coding solopreneur or hacker-builder. Then there's the systems and infrastructure engineer who's actually building the complex systems. And then you have a whole other swath of people writing code for space missions and things that people probably don't want them vibe coding.

Yes.

So there are clearly very different buckets, and they're becoming more well-defined. Would you argue that we actually need even more of those sophisticated engineers than before, because now a lot of people are building ideas that need them to support their systems as they scale?

The way I'd put it is that there's an infinite demand for software in the world, and to the extent that these tools help with software production, I think they're going to help at all levels of complexity. They're obviously going to have a huge impact on building the simpler things. It's opening up the ability for a whole new class of people to build apps, which is awesome. But I think it's going to vastly increase productivity at the harder level as well, which is one of the cooler things. Warp is a product for pro developers, and pro developers using these tools should become way more productive.

Do I think it's going to increase the demand for them? I think the demand is already infinite. So there will be demand for the simpler types of apps, and there's going to be demand for software engineers working on harder problems, and I don't think that's really going to change. I could be totally wrong, by the way. Ten years from now, I don't know at all. This is just what I see in the short term.

I also see that there's a lot of skill required to use these tools effectively. It's a learning process for engineers and a total change in behavior, and often there's even resistance to learning to use them. But even when you want to use them, you have to learn how to effectively use a whole new tool set. So the engineers who are going to be the best are the ones with a great baseline of preexisting CS knowledge who can also say, "I'm going to learn how to most effectively work with the AI."

What are the things that go away, whether it's practices, specific vendors, or products that everybody uses today but increasingly won't need? And what has staying power, the critical tools people will still need even if everybody is writing 10x more code with AI?

I think long term, IDEs become less important. The IDE is an interface that's totally geared around, like Microsoft Word, open for all your files, so you can go in there and handwrite a bunch of code. I think handwriting code is going to be the exceptional case. It's not going to be the zero case, but I bet in a few years people are not writing that much code, so having a whole interface geared around that seems less important.

I think reviewing code that an agent has written becomes more important. The code review interface of GitHub is too outer loop, if that makes sense. You need something where you, as a developer, are very, very tightly collaborating with AI as it's writing code, compiling your code, making mistakes in writing the code, and clarifying what you actually meant when you prompted it to do something and it didn't actually do it. So I think a really tight feedback loop between user and agent is going to become the most important thing. I don't know that the right interface for that totally exists today. This is what we're trying to build at Warp.

If you had a crystal ball, what would you expect the future to look like? Let's keep it to a time frame of two or three years, because beyond that it's hard to know.

It's so hard. But let's say I'm a pro developer working at a place like Google or Facebook or a tech startup. I think my day is going to look like this: I come to work, and I have a bunch of different things I'm trying to do. Maybe I'm fixing bugs, maybe I'm implementing features, maybe I'm figuring out why something's going wrong for a user. I am going to be in constant dialogue with a series of agents that are doing work for me.

Some of it is just that I've told them to do something and they're doing it. Some of it is more that they're proactively figuring out what needs to be done. They are trying to implement the feature I told them to implement, debug the bug, figure out the production issue. But they can't quite do it on their own, so at the right moments they loop me in. They tell me that they're stuck, that they need help.

These agents have a ton of context, and the more context they can be provided, the better. They're going to know about your infrastructure, your code, your company practices, your Slack, your ticketing system, whatever. But they're still going to need you as their personal tech lead, to make sure they're actually getting to the outcome you want.

I really think it's going to be like that in a couple of years. There are moments where I'm able to use these tools like that today, and they work, and I'm like, "Oh shit, this is amazing." It doesn't work that well today, but my bet is that the models advance, the ability to get context in advances, and the skill of developers in working this way advances. So that's what I think the future looks like.