Trisha Gee is a developer advocate and Java champion with over 20 years of software experience.]
Congrats to Stack Overflow user citelao for winning a Famous Question Badge for their question VS Code SSH keeps dropping connections, but I can SSH just fine.
Ryan Donovan: Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I’m your host, Ryan Donovan, and today we’re going to be talking about the IDE and its place in the AI age. My guest is Trisha Gee, who is a Java champion and a developer productivity advocate. Welcome to the show, Trisha.
Trisha Gee: Thank you for having me.
Background in Software Development
RD: Before we get into the IDE business, give us a little insight into where you came from, how you got into software and technology.
TG: As I get older, this story gets longer. I came through a sort of classic route. I’m fairly old, so I started coding when I was about nine, in the 80s, like a lot of my cohort did with BASIC. Then I did a computing A-level when I was 16 through 18, because I’m from the UK. Then I did a computer science and artificial intelligence degree at the turn of the century. AI was very different back then.
RD: I took an AI class back then too.
TG: Yeah, it was different. There were only two schools of thought: classic search-based AI and modern neural networks AI. It was interesting to learn about the two different approaches. I went to the University of Sussex and they taught Java back when it was Java 1.1 and brand new. So I was really lucky that when I came out of university in the early noughties, I had experience in Java. I’d been working for Ford Motor Company as an undergraduate, so I knew what professional software development looked like, and I got into web development and Java in the early noughties.
I spent about 10 years as a classic software engineer, then I worked at LMAX with Dave Farley when he was writing the Continuous Delivery book. We did a whole bunch of XP, Continuous Delivery — all the stuff I’d read about for 10 years and never seen anyone really do. I’m like, oh, this is what software engineering should be all about. I worked there for four years and loved every minute of it.
I learned a lot about using the IDE there. We were pair programming in IntelliJ IDEA, and previously I’d used an IDE but only done basic stuff with it — this is around 2012. When you’re pair programming, every individual you pair with has a set of tricks they use. As a team, you all get much better because you learn everyone else’s little tricks. So I learned a whole load about the IDE and about how to work effectively in software — how XP works in the real world.
And I thought, what I want to do is go out and tell other developers there is hope and everything doesn’t have to be rubbish. All those classic software development grind jobs — it doesn’t have to be that way. There are lots of things you can do on lots of different dimensions to improve your life as a developer. That’s how I got into advocacy. I wanted to go to conferences and write blog posts and do videos showing people tricks with the IDE, talking about where the trade-offs are with certain agile techniques or certain design decisions — the pragmatic implementation of the things you read about in books.
With that, I ended up working at MongoDB, then at JetBrains doing IntelliJ stuff, and then at Gradle doing developer productivity advocacy. That brings us to now, where I’m trying to figure out what’s still relevant in the age of AI, what is genuine productivity, and what is noise as we travel along the hype curve.
Developer Emotion Around Tools
RD: What is the sort of productivity gain of an IDE? We ran an article about IDEs a while back, and the author made an offhand snide remark about Vim and Emacs and people got super mad about it.
TG: People feel very emotional about their tools, full stop. I’m very emotional about IntelliJ IDEA, and one of my reticences for embracing some AI programming is because I’m like, I’m faster with my IDE because I know how it works. I’ve seen the same thing with people who know Vim and Emacs very well. I’ll say, but you could use the refactoring tools in IntelliJ IDEA. They say, yes, but that requires a learning curve. I’m not willing to pay that price. I’m perfectly productive enough with the tools I’ve spent so long using.
The point about understanding a tool very well, no matter what it is, is that it becomes a lot of unconscious competence. Your fingers use the right key bindings. When people ask me what the shortcut for something is in IntelliJ, I have to imagine the keyboard and see what my fingers do, because I don’t know the shortcut — I know what my fingers want to do.
RD: It’s muscle memory, right?
TG: It’s muscle memory. Once we get familiar with tools, once we find tools that work for our flow, they become muscle memory and they become very integrated — kind of a part of ourselves. We don’t want people to say IntelliJ sucks because we’re like, I use it really effectively, and if you say IntelliJ sucks it must mean I suck — which is not true at all.
AI and the Evolving Role of the IDE
RD: It’s interesting that everybody has their tools, everybody has their keystrokes memorized, but AI is disrupting that productivity flow. You don’t need the magic words or the keystrokes to navigate anymore. Are we losing something from the productivity by losing that? Or is it all roses?
TG: I think we don’t know yet. We’re very much in this fuzzy area where we know AI is definitely going to change everything, and AI is here to stay — the same way that higher-level programming languages are, or NoSQL databases, or cloud computing. In the early days of all of those things there was a lot of hype, a lot of people doing superuser-type stuff, and a lot of people resistant to change. The truth is somewhere in the middle.
If you’ve got an experienced developer who knows the IDE inside out, knows how to use the refactoring tools, knows how to do various things without thinking about it — they’re not going to be spending AI tokens to do that stuff. And why spend AI tokens on something you can do quickly, reliably, and deterministically inside your IDE?
For folks who don’t have that kind of muscle memory or aren’t that integrated into their own IDE, that’s an interesting question. I’ve been thinking about whether there’s a way to teach developers where the balance lies — something like a “spending no tokens” productivity course, taught with the assumption that of course you’ll use AI for a bunch of other things, but here are the areas where the IDE is really good. I think that’s a great idea, but it’s going to depend on your team, what you’re doing, and your appetite for learning different tools. Some developers will be quite happy to use the IDE for refactoring; others will really just want to use the IDE’s diff tools for more effective code review. The IDE isn’t going away, but its role is definitely evolving quite quickly.
RD: It almost sounds like there’s a new role for it where some of the IDE shortcuts are skills that are built more deterministically.
TG: Yeah. If I ask Claude to refactor something for me, I want it to use IntelliJ’s deterministic refactoring tools. I don’t want it to do something unexpected.
RD: And I think one of the things I’ve seen is that for people who come up on programming with LLMs, it’s very easy to use the LLM for everything. I saw somebody asking what’s a good LLM for converting a PDF — and I’m thinking, none of them.
TG: None of them — or all of them, you know?
RD: Right. That’s not the right tool. So how can we revitalize what an IDE is for the folks who think purely in terms of prompts?
TG: AI is different from any other kind of tool. When Docker came along, for example — and I use Docker as an example because it took me years to figure out where it sits in the ecosystem. I hadn’t used it in my previous engineering role, and in my Java advocacy role I didn’t really need to touch it. But eventually you play with it, you figure it out, and then you’re like: this is its niche, this is where it fits, this is what it’s good at and what it’s not so great at. AI is very different because it spreads all over everywhere.
RD: Right. It can do almost anything.
TG: It can do almost anything — generating code, writing presentations, doing code reviews, debugging, probably writing Docker scripts, running your tests, identifying flaky tests. And I think that’s really cool. But I also think that’s its weakness. If you have very general models trying to do everything, it’s a jack of all trades and it’s not going to do any one thing very well.
I think each team — each individual, even — is going to figure out which AI tools work for them, how it fits into their workflow, and how much to lean on AI versus using an IDE or a command-line tool. The PDF example is a great one. I was generating PDFs with AsciiDoc when I was writing my book, but it took me ages to figure out because it was more complicated than I wanted. Now I wouldn’t get an LLM to do that for me, but I would get the LLM to describe how to set it all up so I could do it myself. It’s all going to be a case of finding the niches where it fits for a team and for an individual.
RD: Yeah. And I think we’re running into situations where people are starting to feel the burden of their token spend, and realizing that not every task warrants reaching for the most powerful — and most costly — tool available.
TG: Exactly. And that awareness is what’s going to push developers back toward understanding their full toolchain — IDE included — rather than treating AI as the only hammer in the box.
