What is the Future of IDEs

0:00 Okay, so here's a question that I keep hearing and honestly one that I've been kind of asking myself a lot lately. With the state of coding agents the way that they are, what is the role of IDE? And I

0:13 think it's really easy to be dismissive and say that you don't need them at all. But also when I find myself actually running code that I want to put into production that I want to know is safe

0:22 and stuff like that, I do want an IDE that I can actually go and look at the code and do a variety of different tasks etc. So you hand clawed code or codeex a task. It goes off and does a bunch of

0:34 changes and usually those changes are not just changing one file that could be touching 10 15 different files there and from the terminal alone you really can't see any of that. Now, that can be kind

0:47 of good when you're just trying to run something on your phone, you're trying to get an idea down, you're trying to do something like that. But I still believe if you're going to call yourself a

0:55 developer that you need to know what the code is actually doing. You need to know that the code is still right. And in some way, shape, or form, I feel you can't leave all of that to AI. So, this

1:06 video is sponsored by Jet Brains. It's not a big push though for any particular product that they make or anything. It came about from me talking to them and them publishing a blog post. And that

1:16 whole idea of that is really what do you need an IDE for in this day and age. And I've got my own answer to this and it's really no longer about writing code at all here. Okay. So just to set a bit of

1:28 background here. When Jet Brains reached out about this, I wrote back with my honest take. I said that I think IDE still matter, but I think they drastically need to change. And to be

1:38 fair, JetBrain seems to see it the same way. air is their take on what an IDE looks like when agents are doing a lot of the writing and I gave them a few reasons that I'm going to go through

1:48 here. I also want to say on a personal note that I actually started using Jet Brains IDEs for doing Objective C development back in 2012. So I've seen their products change over the years. I

2:00 myself never used IntelligJ IDEA but I had lots of friends who did Java development who were using IntelliJ IDEA. I used their Python idea at one stage for doing Django development and

2:10 on the whole I found them to be a very thoughtful company in trying to make products that are really geared for developers and honestly that's why I accepted the sponsorship here. So going

2:20 back and forth with them about IDE and there are a number of things that I told them that I still think the idees are really important here. One was diffs and being able to actually see what an agent

2:32 has changed. So, I see so many people doing vibe coding where they're just putting in a prompt. They don't care. And there's a time and a place for that. Don't get me wrong. I think that's

2:42 really good when you're developing quick ideas and stuff like that. But, for example, a lot of you have asked me about the testing suite that I use for basically testing all of the models and

2:53 that's now become quite an extensive piece of software there. And in the process of developing that, I used an early version of Fable. I used Claude code. I used codeex. There are quite a

3:04 number of different agents that have touched that codebase and often each of them has got their own idea about how that should actually all work. So one of the things that was really important to

3:14 me there is not just the low-level code of how things are actually going. And that software for example can support a whole bunch of different backends. Everything from the Gemini APIs, open

3:26 router APIs to VLM local to SG Lang locally and even things like Llama CPP and Nvidia Dynamo etc. And one of the most important things with a project like that is how you basically build

3:40 something like that in modules and you really need to know how the code base is laid out. And this is where I think ideides are going to become a lot more important in the future that we're very

3:50 rarely ever going to use an IDE for handwriting code. Occasionally, yes, you might go in and make some changes or do things like that, but the majority of the time it's for inspecting the code

4:02 and then for inspecting how that code was made. So, one of the tricks that I learned from one of the people in Anthropic was to basically get the agents to create HTML documentation and

4:15 HTML diagrams for how everything is laid out. And that is really useful and I always try to make sure that's in a lot of my code bases when it's something important. And I'll make sure that that

4:25 actually refers to file names that I can then go and actually look at that in an IDE. That's something that's really crucial here. Another thing that I think is that IDEs are kind of merging away

4:38 from just being things where you look at code but things where you run agents. So I think GitHub copilot was one of the first ones that did this and I used them for a time and they basically had an

4:49 agent panel as well as the code panels etc in there. And for me that started off well but I honestly moved away from them for a variety of different reasons. And over the last 6 months I've

5:00 experimented with a whole bunch of tools. Like you've probably seen in my videos a couple of months back that I was using cmox a lot and running multiple agents in that and having that

5:10 open and then often having some IDE to actually look at the actual code as well. I've also experimented with things like Herder and even more recently with T3 code and even Jet Brains Air also has

5:23 these abilities in it where you can run multiple agents and then orchestrate them from the IDE directly and you're not just limited to one agent. You can run a whole bunch of different ones in

5:34 here. Each of these solve the problem. I think one of the key things here is that you want something that's going to allow you to be able to go very quickly from the highlevel chunks down to the

5:47 low-level chunks here. Now, for a company like Jet Brains, for most of their history, idees really were the place where you write code, right? Gradually later on, you had things like

5:56 autocomplete. You had the ability to do refactoring. For those of you who remember actually writing a lot of code, the whole idea of snippets was really cool and everyone would have their own

6:07 version of personalized curated snippets that they used in developing and all of that was about making typing code faster. The early AI autocompletes were really cool in that suddenly you didn't

6:20 need to write a full function. You could just start off writing the function and it would just autocomplete it and be able to match the variables and do things like that. Now, obviously, we've

6:29 come a huge way since then, and agents have come along, and I would say not only has that made typing code no longer the main thing, more often than not, it's actually made it the bad option.

6:41 So, for sure, if IDEs were only about typing code, then they would be in trouble. But I think a lot of what a really good IDE does is it helps you read code, helps you navigate, it helps

6:51 you understand it, helps you check it. So if we talk about where the bottleneck has moved, if you've been using coding agents seriously, you've probably noticed this yourself, right? That an

7:01 agent can produce a change in a few minutes, but then reviewing that change can take you much longer than it actually writing the change. This is especially true if you're the one

7:12 responsible for committing that to the codebase for production. I know for example in a lot of organizations like Google and if you go back to the interview I did with Logan Kilpatrick

7:22 earlier in the year he actually talked about this that nowadays anyone can write code and submit a pull request in there but one of the software engineers on that project has to go through it and

7:34 sign off on it and they're the ones that are responsible for it not the person who came up with the idea and vibecoded it with an agent etc. So that radically flips your tools from being just about

7:47 generation to much more about curation now. So Jet Brains put out a post recently based on talking to a bunch of engineering teams and the pattern that they found is pretty much what I see.

7:58 Implementation has become quick. The bottleneck has moved to the code review and the planning. They talked about that one team actually measured it and found that their PR time went up, not down as

8:10 they're actually rolling out agents. And I think at big organizations there really is a trust problem over the agents of how much can you actually trust them to do stuff. And honestly I

8:21 kind of feel that that's the right behavior. I'd be more worried about a team where review time has gone down to zero here. And of course there's a version of this where people say well

8:31 just get another agent to do the review and look the AI can review itself. It catches stuff, but that still doesn't remove the need for a person who understands what the system is supposed

8:42 to do to actually check not only is it getting to a good result, is it getting there in a way that is not breaking the law that is not running up huge compute bills or database bills. And while it's

8:55 definitely possible that we may get there in the future as the models keep getting better and better, I think at the present we still need humans to actually sign off on what goes into

9:05 production. Okay, so let me get concrete about what actually I use for nowadays. So the first off is diffs. It's the most basic one and probably still often the most important. But before anything an

9:18 agent writes that gets fully merged, I want to at least have a good sense of what the file structure is, what's in those files, has the documentation actually documented properly, what it's

9:32 doing. All of those things are sort of key, and you just can't do that with with a wall of text in a terminal or some kind of agent panel where you never actually see what's going on in the

9:42 background. The second up is navigation. So when the agent actually changes a function, I want to be able to jump in to where that function is actually called. I want to find usages, see what

9:55 implements the interface there. And ideas have had this forever, but it's often exactly what you need to judge whether a change is safe. And of course, I'll admit that if it's something that's

10:05 not that important, I'm not going to spend that much time on it. But if it's something that I know is making a large amount of database calls or something like that, I want to check and see is

10:16 that done in a reasonably efficient manner in there. And that kind of brings me to the third use. And the third use is verification. So this is running tests, running the inspections, then

10:27 when something looks off and that's not going to be a huge amounts of times, but I want to be able to step through it with a debugger to actually see, okay, what is going on here? or I want to be

10:38 able to have a set of tests that I can run and I can see the outputs of that in the IDE to see okay which of these tests are running which of these tests are failing which of these tests are doing

10:51 well etc. That's something that's really key here for any sort of verification is to be able to have tests to be able to quickly look at those tests and make sure they don't just have a return

11:03 equals true on them, but they're actually doing what you think they're doing. And then being able to see the outputs of those and go through those quickly in a nice way. The fourth

11:12 element here I think is really underrated is documentation. I think that the IDE becomes much of the place where you document code as it's being written. So if agents are producing most

11:24 of the code definitely they should be writing documentation as well but you should be reviewing that documentation. You should be reviewing that what it's saying it's doing is actually what you

11:35 want it to be doing. Just checking things like why does this particular component exist? What are the constraints are here? And then also being able to see if I asked for one

11:45 particular change, did the agent go off and change things that I didn't want changed in there? And then having that allows you to basically feed back into agents. So that gives you better

11:56 documents, that gives you better context, that gives you better output. Especially that's true if you're using multiple agents. So if you're using something like claude code plus codeex

12:06 plus open code plus a custom harness that you've created yourself plus a bunch of different open models and I think that's one of the areas that really gets overlooked here is that all

12:16 of this IDE intelligence isn't just for you it's useful for the agent too. An agent that can only gp through files and have to basically use its full context window to sort out what is actually

12:29 going on is often an agent that's kind of working blind. An agent that can kind of work with what you've given it and what you're looking at in the IDE and that can use that IDE to do things like

12:41 semantic search across the codebase is just going to have much better context and therefore it's just going to be more accurate. And then on top of that, this is often just going to save you money by

12:53 using fewer tokens. And that's something I think that we're all being spoiled with here is that we're paying these $100, $200 plans, perhaps even going up to $500 plans now, and you're getting a

13:05 very high amount of token usage. If suddenly that starts to come to a stop as the models get bigger and better, and you have to start paying for API calls, this whole game is going to radically

13:17 change then. Anyway, hopefully this video, whatever tools you use, has got you to think a little bit about the way that you and your team are actually building software these days. Like I

13:27 said earlier on, my whole answer here is that the idees are really not where you write code anymore. It's where you read it, where you check it, where you decide whether it ships. The writing part has

13:38 gotten cheap. The verification hasn't. That's really the direction Jet Brains is heading with Air. bringing the agents that you already use into the IDE so that you can review and check their

13:49 work. So anyway, I'll include the link to the blog post and Jet Brains IDEs in the description and you should also check out Air for yourself and really I'd like to start a conversation here of

13:59 what do you find yourself using to actually push software into production here. Now I know some of you are brand new to software development but I also know a lot of people listening to my

14:08 channel do this as a full-time job. So let me know what are the challenges that you're facing and how are you actually trying to address and fix those challenges now that the entire world is

14:20 moving to these coding agents as we go forward. Anyway, as always, if you found the video useful, please click like and subscribe and I will talk to you in the next video. Bye for now.