🎙️ Goodbye IDE. Hello ADE?

What comes after the IDE (Integrated Development Environment)?
In this episode of Inference, I sit down with Zach Lloyd, founder and CEO of Warp, to talk about a new category he’s coining: the Agentic Development Environment (ADE).

What does it mean for coding?

We explore why coding is shifting from keystrokes to prompts, how Warp positions itself against tools like Cursor and Claude Code, and what it means for developers when your “junior dev” is an AI agent that can already set up projects, fix bugs, and explain code line by line. Super interesting stuff!

We also touch on the risks: vibe coding that ships junk to production, the flood of bad software that might follow, and why developers still need to stay in the loop – not as code typists, but as orchestrators, reviewers, and intent-shapers.

Zach also tells me about the freshly launched Warp Code, a new interface for coding with AI.

This is a conversation about the future of developer workbenches, the end of IDE dominance, and whether ADEs will become the default way we build software. Watch it!

This transcript is edited by GPT-5. Let me know what you think. And – it’s always better to watch the full video) ⬇️

Ksenia Se:
Hi Zach, and welcome to the Inference show by Turing Post. I'm very glad to have you here.

Zach Lloyd:
Yeah, I'm excited to be here. Thanks for having me as a guest.

Ksenia:
Absolutely. So before our conversation, I was playing with Warp and it’s mind-blowing how it builds applications almost by itself. on your website, you call it an agentic development environment. Can you explain what that means in relation to the terminal, the CLI, and the IDE?

Zach:
The basic idea is that development is shifting from development by hand to development by prompt. For most of my career, if I wanted to build something I’d open an IDE and start typing code, or I’d open the terminal and type commands. Today, I open Warp and type in natural language – or just talk to Warp – and ask the computer to do something for me.

As workflows become more agent-first, we need a workbench that supports that. We think it should look more like a terminal than an IDE. The terminal has always been about direct input: you type commands, you get answers. Now you speak English and launch agents.

Warp began as a terminal, but today its main interface is natural language. It writes code, lets you pair with agents and review diffs, and even provides file editing. Things that once lived only in the IDE are now in Warp. None of the old labels fit anymore, so we started calling it an agentic development environment.

Ksenia:
Did you come up with that term?

Zach:
I did! We played with different names and landed on ADE – similar to IDE, but with the I swapped for an A. I’ve started hearing others use it too. I was watching a podcast with some engineers I respect, and one of them – Nathan Sobo, the Zed founder – said what the world needs is an agentic development environment. That was pretty cool to hear.

Ksenia:
That feels logical after IDE. But in today’s environment, with coding agents everywhere, how does Warp stand out? What makes it different from Cursor, which is so popular, or Claude Code, which a lot of people use?

Zach:
Compared to IDEs like Cursor, there are two main differences. First, because we operate at the terminal level, Warp covers a wider range of tasks – the full software development lifecycle. You can set up projects, run coding agents, deploy the code they build, and debug production issues, all in Warp. IDEs are more file-editing focused – they look like Microsoft Word for code.

Second, Cursor’s sweet spot is auto-completion – ghost text suggestions as you type. That’s super valuable. But the agent experience in Warp is stronger than what you get in IDEs. In an IDE the agent lives in a side chat panel, which isn’t as effective. Warp’s agent quality is also benchmarked – number one on TerminalBench, top five on SWE-Bench – so we know it’s competitive.

Claude Code is closer to Warp, since it also runs in the terminal. But Warp has some advantages. One is that Warp is multi-model – we route to the best models rather than locking you into one provider. Another is that Warp includes file editing and diff review, which makes it far easier to pair closely with agents.

Tools like Claude Code or Gemini CLI are great for what I’d call “vibe coding.” You spin up a few agents and let them hack on different parts of a project. But if you’re a pro developer, success with agentic tools comes from pairing with the agent step by step – code reviewing its output, guiding it, making sure it follows the plan. Warp is designed for that level of collaboration.

We’re not against vibe coding, but for pro developers vibe coding is kind of the fastest way to ship crap to production. Warp gives you a much tighter, more reliable workflow.

If you look at the most recent Stack Overflow survey, the number one and two complaints about agentic tools are: they generate a lot of code with subtle bugs, and the code is hard to comprehend. Sometimes it takes longer to understand what the agent is doing than if you’d written it yourself.

Our view is that you need something very agentic, but also reliable for real production codebases. That comes down to comprehension – can you understand what the agent is doing, guide it carefully, correct it when it goes wrong, and ensure it follows your team’s coding conventions? Warp has a built-in advantage here because it’s designed for tight pairing with the agent. CLI-only tools can’t support that as well.

Ksenia:
When I was playing with Warp, I thought of it as a meta tool. We recently did a report with Focus AI testing coding agents, and Warp came out so strong that my husband – who was running the tests – joked that you should hire him as an evangelist. His big conclusion was that Cursor+ and Warp is the best combination.

For me, as more of an amateur builder, Warp feels like a meta tool because it helps me do steps I might not know. But what about professionals? Is your vision that Warp will live alongside other tools, or become the meta tool for developers?

Zach:
Right now, people use it in both ways. It’s common to combine Warp with an IDE – do project setup, Git work, Docker, Terraform, all the “terminal-ish” tasks in Warp, then switch to the IDE for file editing. That’s fine.

But our vision is bigger. Over time, developers will need less hand-editing and auto-completion, and more agent guidance – adjusting the path of the agent and giving it feedback. Warp is built for that, so we see it evolving into a single workbench.

Developers do like mixing tools – some run Claude Code inside Warp, or combine Warp with Cursor. That works too. But we think there’s more value in a single integrated agent experience. For example, if you code directly in Warp, it can share context across all your terminal panes – the output of a server running in one pane can be used as input for an agent in another. You can’t do that if you’re juggling separate CLI apps.

So while we support different workflows, we believe many developers will eventually see the benefits of staying inside one integrated environment.

Ksenia:
That’s a lot of rethinking for developer workflows. What do you think will disappear from today’s workflow once these meta tools exist?

Zach:
I think existing tools will just be used less. You’ll still want a file editor for a long time – sometimes it’s faster to fix something yourself, or the agent isn’t getting it right, or the language isn’t well supported. So file editors won’t disappear. It’s like how developers rarely, but sometimes, need to look at machine code. The abstraction is more convenient 95–98% of the time, but you still want the fallback.

The difference is that the predominant way of working will shift to agent-first. You’ll rely on agents most of the time, and drop into hand editing when you need to.

Ksenia:
So I’d say Warp is already like a junior developer. You’re saying it will be agent-first – does that mean it could become a senior developer, or even a fully independent one?

Zach:
That junior developer analogy is pretty good. If you give Warp a spec or iterate with it on a plan, it can build something at the quality of a junior dev – sometimes better. It’s not just a coding tool either – it can solve problems: fix dependencies, debug servers, figure out crashes. It does a lot of what a developer can do, but it still needs guidance from a more experienced engineer.

Over time, the tasks it can handle will get more complex. That will come from improvements at the model layer, but also the app layer: more context sharing, better ways to learn a team’s knowledge so it doesn’t start from scratch each time. In the next few years, senior engineers who embrace this way of working will be able to do 5–10x more. Their role will shift toward communicating what needs to be built, while the agent handles the brunt of execution. Then the engineer reviews for quality, security, and fit with the larger architecture.

If you’re a junior developer now, the best path is to level up as fast as possible – become a senior developer who knows how to leverage these tools.

Ksenia:
And how can these tools help you do that?

Zach:
That’s an overlooked piece. There’s a lot of fear about replacement, but they can also accelerate learning. Tools like Warp don’t just do tasks – they explain. They can walk you through a codebase line by line, explain why it works, or show you multiple ways to solve a problem and outline the pros and cons.

It’s like ChatGPT: you can use it to cheat, or you can use it to learn faster. It depends on your intent. If you use Warp with learning as your goal, it’s an incredible shortcut.

Ksenia:
I have two questions about languages. First: you chose Rust for Warp’s foundation. What does Rust enable that wouldn’t have been possible otherwise?

Zach:
We chose Rust mainly for performance. Developers are uniquely sensitive to app speed, and also curious about how apps are built. Rust gives us speed, safety, and fewer crashes. I strongly prefer strongly typed languages, and Rust makes it harder to write slow or memory-leaky apps.

Another factor was cross-platform support. Warp is a native app for Mac, Windows, and Linux, and also supports the web. You basically have two options: build on the web platform with Electron, or build natively. We prototyped Warp in Electron, but ran into performance issues quickly. So we chose Rust – harder, but worth it for streaming gigabytes of text without stuttering. Rust’s async primitives make that possible.

Ksenia:
Now you’re working so closely with AI, and machine learning is built mostly on Python. Do you think the ADE era will shift more of the stack toward Rust or newer contenders like Mojo, or will Python remain central?

Zach:
Most of our agent logic runs on the server, which is built in Go. If we did it again, we might use Rust there too, so we could share code between client and server. Go is fine, but I’m not a huge fan. It feels stuck between Rust and Python – not getting the best of either. Python would be nicer for AI-heavy work, but the truth is you can build anything in any language. We’ve been able to iterate fast enough in Go that it hasn’t been a bottleneck.

Ksenia:
So why do you think machine learning stuck with Python?

Zach:
Because it’s easy and ergonomic. The core data libraries in Python caught on early. It’s dynamic, interactive, and fits perfectly with Jupyter notebooks, which is where a lot of ML work starts. You don’t want a compiled language there – you want something quick, high-level, and transparent. That’s why Python became the default for ML, and it still makes sense.

Ksenia:
Now that you’re not just in software development but in agentic development, what excites you most – and what concerns you most – about the future you’re helping to build?

Zach:
The thing that excites me most – and I’ve been a developer for a really long time – is how much easier it is to build great software, how much more can be built by fewer people, and how many more people can build at all. It lowers the barriers and removes a lot of gatekeeping. We even have teammates who aren’t developers building apps to do their jobs better – our head of engineering recruiting built an MCP server that connects to our ATS. He’s not a developer, and now he can automate his own workflow. That’s exciting.

What concerns me is the potential flood of crappy software. As a user I hate using broken apps – the pharmacy site that can’t find my prescription, buttons that don’t work. My fear is we’ll see an explosion of that. Even for pro use cases, agentic tools can lead to security holes or unmaintainable code if they’re used as pure “vibe coding.” Software engineering practices exist for good reasons. To make agents work in production you need tools that let you specify precisely what to build and keep a short, tight feedback loop – understand what’s being built, guide the agents, and ensure quality. And my worry is that there's going to be just a lot of bad shitty software shipped.

Ksenia:
We just need to change the world’s system prompt: don’t build shitty software.

Zach:
Like if we could just tell it that maybe that would just solve it. No shitty software, please! Agents are like savants – give them a goal and they’ll pursue it, sometimes by deleting tests and claiming success. They don’t yet understand the user problem. That’s the key – why are we building this, and how is it useful? Until agents understand the user’s problem, you need a human to provide that context.

Ksenia:
Do you think about AGI and superintelligence?

Zach:
I do, though I’m not qualified to forecast timelines. The pace is clearly fast – compared to six months ago it looks exponential. Typically curves become S-shaped; with AI there’s the possibility of recursive self-improvement, which is what ASI folks expect. We’re not there yet, but progress is very fast.

Ksenia:
From what I hear, you are saying is that the human is still needed in the loop.

Zach:
That’s our bet. Models will keep improving and agents will become more autonomous, and we’re building Warp for that future. But today the first breakthrough was autocomplete. We’re now seeing early adoption of agents, though most developers still don’t use them – the workflow is new. Next you’ll see more autonomy – system triggers like “there was a crash” and an agent investigates. Even then you need a tight loop – today it’s iteration, tomorrow it’s orchestration. You still need a way to express intent and manage agents at scale. In 6–12 months things will look very different, but right now a tight loop is what ships production-quality code.

Ksenia:
Predictions are hard, but if we focus on adoption – what happens in the next 12 months?

Zach:
Today most mainstream developers have adopted autocomplete like Cursor. For agents, adoption is heavy among AI enthusiasts and non-technical folks like PMs and designers, plus a growing but still small slice of pro developers who start tasks with a prompt. In 6–12 months I think agentic will be the primary workflow and autocomplete secondary – that’s the bet Warp is making. Developers will realize they can ask the computer to make the change, provide the right context, and review. Fully autonomous coding will grow in parallel for a narrow slice of tasks – think Cognition, Google’s Jules, OpenAI’s Codex-style flows – and that slice will expand. Simpler tasks will be automated; the core work – features, bugs, production fixes – will be agentic with human guidance. Two years out – honestly, no idea.

Ksenia:
It’s crazy how fast it all is. My last question – is there a book you’ve read this year that you can wholeheartedly recommend?

Zach:
Yeah, I’m reading The Beginning of Infinity by David Deutsch, a well-known physicist and pioneer in quantum computing. It’s a dense book – he’s a very smart guy – so it’s taken me a while to get through. My background, before engineering, was in philosophy of science, so it really resonates.

Deutsch writes about what makes human intelligence special – our ability to produce explanations that are hard to vary – and how that drives progress. He also covers quantum physics and the multiverse theory. It’s one of those all-encompassing worldview books, like Guns, Germs, and Steel or Gödel, Escher, Bach. I recommend it – it changes the way you see the world.

Ksenia:
Expands your thinking. That’s cool. Thank you so much for your time and for the insightful conversation.

Zach:
I really appreciate you having me on. This was awesome.

Ksenia:
Before we go – a little something I can share with my audience. Tell me about your new thing.

Zach:
This week we’re launching something major called Warp Code, and it should be live by the time this episode airs. There are a few key features:

• First, you can now review diffs with an agent and edit those diffs directly inside Warp. The workflow is: start a coding task, the agent produces diffs, and then you as the developer review them – you can have the agent correct itself, or make the edits yourself.

• Second, we’ve upgraded file editing. The built-in editor is now much richer, closer to something like Sublime Text. It’s not meant for starting code from scratch, but it’s perfect for iterating and refining an agent’s code.

• Third, the agent can now spin up a new project or pull one from GitHub, set up project-based rules, and build a project-level index. We’ve streamlined that whole flow. We’ve also added slash commands – like /init or /code-review – similar to what you see in other agentic tools, but built right into Warp.

So if you want Warp to be your primary coding tool, the experience just got dramatically better.

Ksenia:
Awesome. Thank you for sharing this news.