I really can't understand why JetBrains hasn't integrated its refactoring tools into the AI system. Really missed the boat on making their platform transformational for AI coding. Imagine how much smaller the context would be for a tool that renames a function than editing hundreds of files. This LSP support is a good start but without the mutation functions it is still pretty lackluster. Plus LSPs aren't as good as JetBrains generally.
Jetbrains seems a bit lost these days. Look at that very recent screw up [0].
I thought about moving after 10+ years when they abandoned the commit modal, and jacked up the plan prices, but I barely understand how to commit things in Vscode anyway. Let's see in 2026.
The commit workflow was what kept me locked in to the ecosystem for so long. LazyGit was so good that it convinced me I didn’t need JetBrains anymore. If you love the workflow with JB for commits check out LazyGit. It’s a TUI so you can use it in any editor without much friction.
I do almost everything git manually at the CLI. But the Jetbrains IDEs have a fantastic GUI git merge tool, and I also like the local git diff UI. Add in integrated blame mode, ability to pull up version-diff files, and that sort of thing.
It's not part of my daily driver toolbox, but they do get used a lot by me.
Exactly. There's a lot of little niceties buried in the integration across the board. I'm convinced that many VSCode supporters have never used a true IDE because whenever I complain about VSCode's shortcomings I'm met with "why would you want that?". Sure, but this git example is a great one because for most of it I *don't* want it, but there's a lot of related bits that I *do* want.
I'm a bit mixed, as I really appreciate the balance that VS Code has brought to the table and even with that feel there's sometimes too much in the base install. JetBrains is definitely better than VS proper in a lot of ways though. I still have nightmares of using VS for web projects, it's not nearly as bad today but I still completely avoid it.
It's the only git operation I do with a gui. But as I said elsewhere, there are a lot of little integrations I do make use of. For instance I find it helpful to have git blame up on the side when editing a file.
I almost always operate in my own feature branch, squashing and then rebasing along the way... sometimes I'll just keep amending my feature commit as I work. I find it just saves me a lot of pain along the way.
That's not the only reason I was using the tooling at the time. Specifically everything else regarding the JetBrains ecosystem kept me hooked, but when I was looking to replace what I liked in JetBrains with other tooling the last piece of the puzzle was replacing the git workflow.
Remember this type of comment. Never let yourself fall into this type of thinking when trying to understand what your users want.
Instead of passing judgement on why someone values something, why not ask?
For example, if you were to ask me why I chose to keep using an IDE that I had spent years of my life building muscle memory using perhaps you would get a better understanding of the specific part of the lifecycle I was at when paying for software.
It's not that the git gui was the reason why I signed up for the software in the first place. The git gui was the last reason for me to not jump ship when switching to something like neovim or helix. This was during a time where LSP was becoming popular so refactoring tools and intellisense were finally getting better adoption outside of the JetBrains tooling. Most of this was achievable with editor du jour + lsp plugins, but the git ui was the one piece I hadn't personally solved outside of the JetBrains ecosystem.
Remember what? That people have different preferences, workflows and methods of staying productive?
Someone voiced that they liked a certain tool for a certain feature and suddenly we are judging them for it? I like that people share their thoughts and opinions.
I think you're thinking about git as a separate thing from the IDE.
I love using IJ + git because there are no seams in between edit and commit. For instance, with IJ, I could easily split every other line of a change into separate commits.
Maybe there's a way in git to stage only certain parts of a diff, but I'd have to go an learn another flag or command that I'm going to forget by the next time I need to do it again.
Also with IJ, I just glance at my main branch tab and the highlighting tells me what commits aren't in my checked out feature branch.
Two small examples but there are many more and it adds up.
I've been using their git diff/checkin tools built into RubyMine since I started with git. Going on about 12-13 years now. Their conflict resolution UI is so much easier than editing text contents between the >>>>s and <<<<s.
It allows you to do stuff so much faster than having to type everything manually into the terminal. Also really enjoy the "Undo Last Commit" feature and how I can easily see all modified files at once and shuffle around stuff between the staging area.
Honestly, the git implementation in PyCharm is better than any git app I've used, including lazygit (which I like and is my go-to when not in PyCharm).
Graphical interface won't work well inside WSL, that's why I dropped my subscription on GitKraken and start using lazygit. lazygit simply works in almost any environment, and it works extremely well even if you are not into terminal stuff.
Yeah, that’s the power of TUI. I would probably give it a go, too, but Git Cola works for me on Linux and Mac without too many issues.
(By “works anywhere”, I meant you can use it with any IDE or editor, or just run it from terminal, though it is cross-platform and should work on Windows, just not sure how well it would play with WSL.)
Really? While there its certainly slightly annoying because they have the "double menu bar" if they use a non-standard one like the jetbrains ides do... I feel like wsl gui support has essentially become a "solved issue" for a while now.
Yes and no, GitKraken actually have a graphical interface for WSL (or Linux generally), but it is barely usable as the WSL-g does not really work well. It's blurry for Hi-Res screen and the performance is like hell.
I would never try running any graphical stuff in WSL anymore, not worth it. VMWare with a graphical installation of any Linux system would be a preferred choice as I'm testing lately.
Hmmm, is there a native virt-manager build on Windows? Though I suppose running it in WSL and connecting with an external SPICE client would work just as well. (I’m wondering if there’s a way to just run SPICE server in WSL.)
Fortunately JB broke that addiction for my by first moving the commit dialog behind an option, and then removing it completely. If I have to learn a new workfrow, I might as well learn a new tool
I mostly rely on the CLI for my git operations anyway. It does make it hard to support others who are using the tools (VS/code/jetbrains, etc) though, since I don't really "get" the workflows in the GUI tools at all.
Jetbrainz needs to give up on Junie and their in house ai and focus on integrating with the established tools. If they don’t, VS code will consume them.
They've already done that. After the Junie fiasco, they pivoted to "AI Assistant", where Junie is just another provider alongside Anthropic and OpenAI. In theory, you have Claude Code inside Jetbrains IDEs now.
What's incredible is just how bad it works. I nearly always work with projects that mount multiple folders, and the IDE's MCP doesn't support that. So it doesn't understand what folders are open and can't interact with them. Junie the same issue, and the AI Assistant appears to have inherited it. The issue has been open for ages and ignored by Jetbrains.
I also tried out their full line completion, and it's incomprehensibly bad, at least for Go, even with "cloud" completion enabled. I'm back to using Augment, which is Claude-based autocompletion.
Yeah, it's quite odd that they can't get AI tools to work, especially considering so many OSS tools available that work surprisingly well (cline, opencode, etc.).
How do these compare? I'm very familiar with Augment and particularly enjoy its fast completions. I mostly don't use its agent, but rather Claude Code in the terminal, because the agent seems superior.
But Augment is not the most stable. I've had lots of serious problems with it. The newest problem that's pushing me over the edge is that it's recently have been causing the IDE to shoot up to use all cores (it's rare to see an app use 1,000% CPU in the macOS Activity Monitor, but it did it!) when it needs to recompute indexes, which is the only thing that has ever made my M2 Mac run its fan. It's not very reliable generally (e.g. autocompletions don't always appear), so I'd be interested in trying alternatives.
They already kinda did. They brough ACP support which allows you to somewhat integrate Claude Code, Gemini CLI or OpenCode they also recently brought BYOK support so you can use an existing provider and don't pay extra subscription for it.
ACP seems super under the radar. It has some support, but it got merged into A2A, which I don't hear anyone talking about, so it seems like it's going to die on the vine.
This is really too bad, as editors should be able to plug and play with AI tooling in the same way that editors <> LSP can plug and play with language tooling.
I mean I tried Zeds implementation with OpenCode was working fine but yeah the whole standards part is really complicated right now. I can't keep track of it. I hear about A2A but did not know it was merged with ACP.
My beef with zeds implementation is they haven’t kept it up to date. I really like the ide integration but when you don’t support half the things that make Claude code really nice, like hooks, it kinda defeats the purpose
I really enjoy Junie, I find it working better out of the box than Claude code. I do wish they integrated their amazing refactoring tools into it though.
I can’t speak for Claude, but Gemini is laughably bad. Like, does someone who develop this shit ever tried to use it? Is it all crab hands that only use mouse? It’s a single line change to switch focus to THE ONLY INPUT on a tool window, but no, you have to use a shortcut to switch to Gemini window and then MOVE YOUR MOUSE across the screen to select input or press tab like 5 times. Embarrassment.
VSCode? Select AI view via shortcut or CMD + P and you’re done. That’s how you do it.
When you become complacent and your ego isn’t checked, you think you have the hottest thing. Hubris is hard. They had a pretty big moat that they let vscode eat away at. I don’t think they saw any of this coming and are struggling to make sense of it.
It never left the preview stage, so they did not feel confident calling it stable enough for their users and I don't use preview versions for products where there are already 10 production grade competitors.
Uncharitable but yeah, reality isn't always charitable.
I heard really good things about Zed, lol. I’m with you. I canceled my jetbrains subscription a couple years ago and I have no intention of returning. They have been superseded and are no longer a relevant company. AI has made them obsolete.
So many salty fools who bought into “professional|enterprise grade ide” cool aid. Glad to see upstarts eating their lunch, they’ve been complacent for far too long.
I've been a massive JetBrains fanboy for a bit over a decade. I finally let my subscription lapse this month. It isn't so much about AI integrations but overall competitors have caught up. The rise of LSP and DAP did a lot to shrink their competitive advantage
They’ve also dropped a huge ball with resisting LSP for Kotlin, thinking that they could lock developers into their ecosystem. Well, now (hopefully) it is too late, karma is a b*tch.
I completely agree. Likewise I'm amazed Microsoft hasn't done it themselves for Roslyn and Copilot. Roslyn analyzers are so incredibly powerful, and it's being ignored.
An explainer for others:
Not only can analyzers act as basic linters, but transformations are built right in to them. Every time claude does search-and-replace to add a parameter I want to cry a little, this has been a solved science.
Agents + Roslyn would be productive like little else. Imagine an agent as an orchestrator but manipulation through commands to an API that maintains guard rails and compilability.
Claude is already capable of writing roslyn analyzers, and roslyn has an API for implementing code transformations ( so called "quick fixes" ), so they already are out there in library form.
It's hard to describe them to anyone who hasn't used a similarly powerful system, but essentially it enables transforms that go way beyond simple find/replace. You get accurate transformations that can be quite complex and deep reworks to the code itself.
A simple example would be transforming a foreach loop into a for loop, or transforming and optimizing linq statements.
And yet we find these tools unused with agentic find/replace doing the heavy lifting instead.
Whichever AI company solves LSP and compiler based deep refactoring will see their utility shoot through the roof for working with large codebases.
In a similar vein, I really struggle to understand why copilot is so crap when writing SQL and I'm connected to the database. The database has so much context (schema names, column names, constraints etc.) yet copilot regularly hallucinates the most basic stuff like table and column names, which standard auto complete has managed fine for the last 20+ years.
No one is interested to solve hard problems. The broad industry got lucky with LLMs and everyone is now blindly burning capital at this. If you think they can't be that stupid remember the covid super hiring frenzy.
Heh, read The Big Short. A large point of the book is that a lot of rich people are both greedy (which we already assumed) and also stupid (which we didn't assume).
It was code-named to disambiguate it from the old compiler. But Roslyn is almost 15 years old now, so I can't call it new, but it's newer than the really legacy stuff.
It essentially lets you operate on the abstract snytax tree itself, so there is background compilation that powers inspection and transformation.
Instant renaming is an obvious benefit, but you can do more powerful transformations, such as removing redundant code or transforming one syntax style into another, e.g. tranforming from a Fluent API into a procedural one or vice-versa.
It really does feel like the Innovator's Dilemma playing out for JetBrains. They have the best semantic understanding of code (PSI) locked away in their proprietary engine, but they seem too attached to the traditional "human-driving-the-IDE" paradigm.
Tools like Claude Code (and Cursor) are treating the editor/CLI as a fluid canvas for the AI, whereas JetBrains treats AI as just a sidebar plugin. If they don't expose their internal refactoring tools to agents soon, the friction of switching to VS Code/CLI becomes negligible compared to the productivity gains of these agents.
Fortunately, Serena has recently been extended to use JetBrains instead of LSP (via a plugin), solving exactly this issue. LSP will never be as good as JetBrains' parsers.
I am trying my damn hardest to drop jetbrains, the only thing they have a stronglehold over is their amazing rust analyzer in rustrover. And yah I agree that they are dropping the ball on providing actual intellisense to AI tools, like why not? It's probably less than 10 lines of code.
Hi! I’m from the RustRover team. RustRover is a full-blown IDE, not just a code analysis engine like rust-analyzer.
In addition to Rust code analysis, RustRover provides many features, including code linting, code formatting, dependency management (Cargo.toml editing), UI debugging, support for web technologies and databases, and AI support (including an agentic approach with Junie).
Comparing code analysis capabilities themselves is quite difficult, because Rust is a very complex language, especially when it comes to implementing IDE-level support. Features such as macros make this even more challenging. RustRover and rust-analyzer use different approaches to solving these problems, and we also share some components. Of course, neither approach is perfect. Depending on the specific project, the developer experience may vary.
You joke and folks downvote, but this is my biggest issue with WebStorm. I'm seriously considering switching for the first time in 16 years. Zed is quite snappy. The Claude Code integration in VS Code is brilliant. I've used the CLI in the JetBrains terminal. I had no idea I could revisit past conversations until I used the VS Code extension!
Zed is snappy in the same way that notepad ++ is snappy: If you don't support 10% of language features you can avoid the hard work. Unfortunately this means that non trivial projects have false positive errors everywhere.
I bought the JetBrains AI last year to support them even though it wasn’t good. It never improved. I didn’t renew. Now, I’m questioning if their tooling is something I’ll even renew at all. All of these AI agents integrate so well into visual studio code…
Being a JetBrains customer lately feels like watching everybody else race by in their cars while your horse is trying to eat the carrot in a grocery store ad on the side of a bus stop
I get it, horse, you're confused, but we got places to go.
I think they are completely screwing up the AI integration.
After years of JetBrains PyCharm pro I'm seriously considering switch to cursor.
Before supermaven being acquired, pycharm+supermaven was feeling like having superpowers ... i really wish they will manage to somehow catch up, otherwise the path is written: crisis, being acquired by some big corp, enshitification.
I'm biased (work at Cognition) but I think it's worth giving the Windsurf JetBrains plugin a try. We're working harder on polish these days, so happy to hear any feedback.
I have running subscriptions with both claude and codex. They are good but, at least for me, don't fully replace the coding part. Plus I tend to lose focus because of basically random response time.
Yes. It is so easy and cheap to refactor in a strongly typed language--no AI needed. And such a waste of electricity, chips, water and money to let some AI model give it a shot. This something we could reliable and correctly do for decades with serious tools and languages.
To this day people still 'refactor' by doing string replacement and hoping for the best. Any serious IDE should just say no to that.
Shameless repost - I'm so sad that JetBrains seems to be floundering. VS Code still doesn't match it in little "oh my gosh, how did it know I wanted that" moments, but the whole JB experience is now just so clunky, especially in a modern WSL2/poly-lang env.
It's interesting that everyone is saying "please don't shove AI down our throat!". But when a company actually takes this approach (JetBrains IDEs treat AI just as a tool at the sidebar), everyone is like "JetBrains is doomed because it's not agent-native enough."
JetBrains are shoving it down our throats though, I have to uninstall their AI plugin after every IDE update, CoPilot suddenly stopped working? Oh, it's because JetBrains has enabled their AI auto-completion feature and it's broken CoPilot.
They've tried to play it both ways. Not AI enough for the AI fanboys, but want to keep a toe in there for everyone else. They'd be better placed rejecting AI entirely, and then when the bubble pops they'll be well positioned to sweep in and eat VSCode's lunch with a product that actually works.
Jetbrains+refactoring - don’t get your hopes up. In Android Studio refactoring was broken for 5+ years and ticket is one of most voted. And nothing happened.
it would hang for me half the time , the last time i tried it (3-4months ago?). when it worked, it seemed really good. but it hung often. time to try again
> I really can't understand why JetBrains hasn't integrated its refactoring tools into the AI system.
Because their refactoring tools are not a "slap on a couple of commands and delegate actual work to external code" like LSP? Because their tools are a huge collection of tools deeply integrated into the IDE? Including custom parsers, interpreters and analysers?
Jetbrains is unforgivable for missing the remote development train. People have been developing on remote huge machines for decades. It’s just the ones who did either were terminal wizards, or they were using hacks to make their IDEs tolerable.
VSCode just scooped up that market with their remote development plugin. And it did not matter that it is an electron app. Still faster than Jetbrains.
I’ve been a JetBrains toolbox subscriber for over a decade. I used to run trainings for new hires to get them up to speed on the eco system as our team would provide licenses. I say all of this because I was about as fanboy as you could get for them.
They’ve dropped the ball over the past five years. Part of me thinks it was the war in Ukraine that did them in. The quality of tooling and the investment in Fleet and AI slop was the death nell for me. I was slated to renew at the grandfathered price on the 17th and decided to let my subscription lapse this year because the value prop just isn’t strong enough anymore.
> They’ve dropped the ball over the past five years. Part of me thinks it was the war in Ukraine that did them in.
I'm also a subsciber for over a decade, and came here to say the same thing. I don't know how their teams were distributed across eastern Europe and Russia but the war is when I pinpoint quality declining.
I've kept my subscription for now as for PHP and Symfony nothing comes close, but I'm actively looking to move away.
can't speak for other languages, but the python LSP in PyCharm is miles ahead of any other lsp out there (and I've tried them all). I give `ty` the best chance of catching up to them, but they're still a ways behind.
I think that the commonly used refactoring functions would make a big difference and right now most IDEs are pretty bad at them (especially across all the languages jetbrains supports):
- rename variable/function
- extract variable/function
- find duplicate code
- add/remove/extract function parameter
- inline a function
- moving code between classes
- auto imports
Others are used more rarely and can probably be left out but I do think it would save a lot of tokens, errors and time.
You’re missing the point, it’s about those tools drastically improving context window management. When you want to tackle large refactors, Claude Code will blow tens of thousands of tokens just searching for files and various refactor related file manipulation. When you run out of window in the middle of a big refactor you’re going to have a bad time.
