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.
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.
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.
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.
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.
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
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.
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.
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 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.
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!
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 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.
I am super bullish on claude code / codex cli + LSP and other deterministic codemod and code intelligence tools.
I was playing around with codex this weekend and honestly having a great time (my opinion of it has 180'd since gpt-5.2(-codex) came out) but I was getting annoyed at it because it kept missing references when I asked it to rename or move symbols. So I built a skill that teaches it to use rope for mechanical python codebase refactors: https://github.com/brian-yu/python-rope-refactor
This is something I notice often when using these tools (if this is what you are referring too). Like they will grep entire code bases to search for a word rather than search by symbol. I suppose they don't care to fix these types of things as it all adds up to paid tokens in the end.
We have 50 years worth of progress on top of grep and grep is one of the worse ways to refactor a system.
Nice to see LLM companies are ignoring these teachings and speed running into disaster.
Similar experience and timeline with codex, but tried it last week and it's gotten much better in the interim. Codex with 5.2 does a good job at catching (numerical) bugs that Opus misses. I've been comparing them and there's not a clear winner, GPT 5.2 misses things Opus finds and vice versa. But claude-code is still a much better experience and continues to just keep getting better but codex is following, just a few months behind.
Another anecdote/datapoint. Same experience. It seem to mask a lot of bad model issues by not talking much and overthinking stuff. The experience turns sour the more one works with it.
And yes +1 for opus. Anthropic delivered a winner after fucking up the previous opus 4.1 release.
I’m basically only using the Codex CLI now. I switched around the GPT-5 timeframe because it was reliably solving some gnarly OpenTelemetry problems that Claude Code kept getting stuck on.
They feel like different coworker archetypes. Codex often does better end-to-end (plan + code in one pass). Claude Code can be less consistent on the planning step, but once you give it a solid plan it’s stellar at implementation.
I probably do better with Codex mostly due to familiarity; I’ve learned how it “thinks” and how to prompt it effectively. Opus 4.5 felt awkward for me for the same reason: I’m used to the GPT-5.x / Codex interaction style. Co-workers are the inverse, they adore Opus 4.5 and feel Codex is weird.
Codex is an outsourcing company, you give specs, they give you results. No communication in between. It's very good at larger analysis tasks (code coverage, health etc). Whatever it does, it does it sloooowwwllyyy.
Claude is like a pair programmer, you can follow what it's doing, interrupt and redirect it if it starts going off track. It's very much geared towards "get it done" rather than maximum code quality.
My theory is that even if the models are frozen here, we'll still spend a decade building out all the tooling, connections, skills, etc and getting it into each industry. There's so much _around_ the models that we're still working on too.
> Shows how much more work there is still to be done in this space.
This is why I roll my eyes every time I read doomer content that mentions an AI bubble followed by an AI winter. Even if (and objectively there's 0 chance of this happening anytime soon) everyone stops developing models tomorrow, we'll still have 5+ years of finding out how to extract every bit of value from the current models.
The idea that this technology isn't useful is as ignorant as thinking that there is no "AI" bubble.
Of course there is a bubble. We can see it whenever these companies tell us this tech is going to cure diseases, end world hunger, and bring global prosperity; whenever they tell us it's "thinking", can "learn skills", or is "intelligent", for that matter. Companies will absolutely devalue and the market will crash when the public stops buying the snake oil they're being sold.
But at the same time, a probabilistic pattern recognition and generation model can indeed be very useful in many industries. Many of our problems can be approached by framing them in terms of statistics, and throwing data and compute at them.
So now that we've established that, and we're reaching diminishing returns of scaling up, the only logical path forward is to do some classical engineering work, which has been neglected for the past 5+ years. This is why we're seeing the bulk of gains from things like MCP and, now, "agents".
> This is why we're seeing the bulk of gains from things like MCP and, now, "agents".
This is objectively not true. The models have improved a ton (with data from "tools" and "agentic loops", but it's still the models that become more capable).
Check out [1] a 100 LoC "LLM in a loop with just terminal access", it is now above last year's heavily harnessed SotA.
> Gemini 3 Pro reaches 74% on SWE-bench verified with mini-swe-agent!
I don't understand. You're highlighting a project that implements an "agent" as a counterargument to my claim that the bulk of improvements are from "agents"?
Sure, the models themselves have improved, but not by the same margins from a couple of years ago. E.g. the jump from GPT-3 to GPT-4 was far greater than the jump from GPT-4 to GPT-5. Currently we're seeing moderate improvements between each release, with "agents" taking up center stage. Only corporations like Google are still able to squeeze value out of hyperscale, while everyone else is more focused on engineering.
Yeah, I posted here because I was completely blindsided when my claude asked if I wanted to install a go lsp. I didnt even know that was a thing. A little googling led to this changelog from 3 days ago, but I was surprised I hadnt seen any previous mentions of this online (from either creators, anthropic, or HN posts).
I am disabling it for now since my flow is fine at the moment, I'll let others validate the usefulness first.
I am on the latest version of Claude Code and nothing comes up when I follow this and search for "mcp". Looks like this feature is quite undercooked at the moment. I'm hoping for a more straightforward way to enable this and ensure the LSP is being used by Claude in the future.
LOL yeah that would be a solid guess but I just sanity checked and I messed it up only in the comment, in Claude Code when I search for "lsp" I still get no matches.
Interesting. I'd guess you don't have the Claude Plugins marketplace enabled, but I very much agree that the whole plugins/marketplace system seems half-baked in Claude Code.
If you want to add custom lsps, they need to be wrapped in a Claude code plugin which is where the little bit of actual documentation can be found https://code.claude.com/docs/en/plugins-reference
My permissions prompt isnt quite working right with it either. It pops up but isnt blocking, so claude continues editing and asking for other permissions which replaces this prompt. Then when you confirm those prompts, it shows the LSP prompt again. Definitely needs polish (and explanations on how it even benefits the agent)
What boggles my mind is. I've been using OpenCode [1] which had this future for at least 6 months. I sometimes baffled by the slow progress of closed source software. Also highly recommend OpenCode you can also use it with your Claude subscription or Copilot one.
preferring open source and provider agnostic tools, i really want to like OpenCode. i used it exclusively for months, but sadly it has major usability issues which switching to Claude Code solved:
- accidental approvals when trying to queue a prompt because of the unexpected popovers
- severe performance issues when pending approval (using 100% of all cores)
- tool call failures
having used Crush, OpenCode, aider, mistral-vibe, Gemini CLI (and the Qwen fork), and Claude Code, the clear winner is CC. Gemini/Qwen come in second but they do lose input when you decline a requested permission on a tool call.
that said, CC also has its issues, like the flickering problem that happens in some terminals while scrolling executed command output.
I must be doing something wrong, because I can't get OpenCode to actually do anything useful, and not for lack of trying. Claude code gets me great results instantly, opencode (if I can't make it talk to a model, which isn't easy for Gemini) gets me… something, but it's nowhere near as useful as claude code. I don't know why there is so much difference, because theoretically there shouldn't be. Is it the prompt that Anthropic has been polishing in Claude code for so long?
I only played with Claude Code briefly but my experience with OpenCode was amazing. My experience it works the best with Claude especially Sonnet models (I use it with Claude Sonnet 4.5 with my Copilot subscription).
You can move quite fast when you don't have to spend half a week persuading 7 stakeholders that something is worth doing, then spend a week arguing about sprint capacity and roadmap disruptions.
I just started playing with OpenCode over the weekend after working with aider and aider-ce, and I like a lot of things about it, though I miss some aider features. What other code helpers have you worked with?
The big players (Gemini, Claude Code, Codex) and then aider and opencode for open source.
I keep my setup modular/composable so I can swap pieces and keep it usable by anyone (agent, human, time traveler) depending on what the task needs. In the aughts I standardized on "keep worklogs and notes on tools and refine them into runbooks" so that has translated pretty well to agentic skills/tools. (a man page is a perfectly cromulent skill, btw.)
i'm not sure i agree with the assessment that claude code has been moving slowly... but it is cool that opencode has had this for a while. will def check it out
I find it so weird that people are so bullish on the CLI form factor when they are literally just adding functionality that IDE based agents get for free. Stuff like improved diff tools and LSP support in the terminal instead of idk... just using a GUI/IDE?
IDEs have LSP support because they have a plugin that connects to an LSP server. The plugin is a very small piece of code compared to the language server. Creating a new client is not reinventing the wheel. In fact the entire philosophy of LSP is: one server to many different clients.
CLIs can also have a small piece of code that connects to an LSP server. I don’t see why IDEs should be the sole beneficiary of LSP just because they were the first clients imagined by the LSP creators.
I just saw a video of non-technical person describing how they use claude code to automate various workflows. They actually tried vscode and then the desktop gui.
Yet they preferred the CLI because it felt "more natural"
With agents, and Claude Code, we are *orchestrating* ... this is an unresolved UI/UX in industry. The same reasons `kubectl` didn't evolve to GUI probably apply here.
I use Zed and unless there is some MCP server that provides the same thing as the LSP server, the Zed agent won't have access, even though it's in an IDE that supposedly has this information
> It would be a huge step up if agent could interact with LSP (Language Server Protocol).
>
> It would offer :
>
> renaming all instances of a symbol over all files in one action
> quick navigation through code : fast find of all references to a property or method
> organize imports, format code, etc…
And last Friday a Cursor engineer replied "Thanks for the idea!"
So how does the AI agent in Cursor currently have access to LSP?
(I am most interested in having the agent use LSP for type checking, documentation of a method call, etc. rather than running slower commands)
(note, there is an open PR for Zed to pull LSP diagnostics into an AI agent thread https://github.com/zed-industries/zed/pull/42270 but it would be better if agents could make arbitrary LSP queries or something like that)
Well my editor is in the terminal, so is my chatbot. I dont really want to change to an IDE to use a desktop app and a chatbot that both have half-baked UIs trying to complement each other.
But in all seriousness, LLMs have their strengths but we’re all wasting tokens and burning the planet unnecessarily getting LLMs to work so inefficiently. Use the best tool for the job; make the tools easier to use by LLMs. This mantra is applicable generally. Not just for coding.
I hope in a couple of years the industry would have outgrown this adolescene and we'll all collectively look back at this horribly inefficient and poorly engineered tooling with disdain. We need to as these things are literally causing harm to the planet (energy, water, raw materials, geopolitics)
I haven't come across a case where it has used the LSP yet.
Opus 4.5 is fairly consistent in running QA at proper times. Lint checks and all are already incorporated into a standard & native processes outside of IDE. I think lookup can be useful when definitions are hidden deep in hard to reach places on my disk... hasn't been a problem though the agent usually finds what it needs.
Anyway, here is what it stated it could do:
> Do you have access to an lsp tool?
Yes, I have an LSP tool with these operations:
- goToDefinition - Find where a symbol is defined
- findReferences - Find all references to a symbol
- hover - Get documentation/type info for a symbol
- documentSymbol - Get all symbols in a file
- workspaceSymbol - Search for symbols across the workspace
- goToImplementation - Find implementations of an interface/abstract method
- prepareCallHierarchy - Get call hierarchy item at a position
- incomingCalls - Find what calls a function
- outgoingCalls - Find what a function calls
CLIs don't use context space when unused. I find them almost universally preferable just because of that.
Models get stupid after the first 80-100k tokens are used so keeping bloated tools out of the window unless completely necessary is a pretty hard requirement for effective AI use IMO.
Amazing how long this took. Serena has been doing a not bad job of helping solve this issue. But this has been an obvious built in for agents for some time now. https://github.com/oraios/serena
I was hoping LSP support would be implemented. I know there are existing MCP servers that can do something kind of similar, but I doubt the agent would be smart enough to consistently utilize the LSP MCP. Here's hoping for less greps.
The typescript-lsp (and others?) is missing a critical part of LSPs whcih is the diagnostics for real-time errors and warnings. So you still need to run a linter, tsc, etc. to generate those sadly.
I've been using https://github.com/isaacphi/mcp-language-server to do pretty much the same thing for quite a while now in Claude code. And it works with clojure-lsp unlike the limited set of plugins available now.
With a fair disclaimer, that it is very easy to vibe-code a skill oneself, with both pros (you can create one just for you!) and cons (if you look online, these are of any quality, quite a few with some hard-coded versions or practices).
Maybe I'm the only one, but does anyone else have an issue on macOS where Claude Code never updates itself automatically and you always have an error? I guess it's in times when I leave the CLI tool running and an update comes in overnight. But the alert seems to indicate it should update and fails.
Depends on your installation method. I have CC installed on macOS with `bun install` and it self-updates. But you could have different results with, oh, npm or yarn or homebrew or nix or probably asdfvm or maybe there’s a native .pkg I don’t know about or…you get the idea.
I have the same issue since for ever (and update by hand because of it). I always assumed it is because it gets confused by me using Volta for node/npm version management and Volta‘s shim masking where Claude Code is globally installed.
Is there a way to automatically run tests every file change, like post tool somehow, so that it returns a concise test run back to the LLM every tool use? That seems like it would be useful.
You don't want to run tests after every file change, because that will distract Claude from finishing whatever it's doing and add noise to the context window. Of course the tests will be broken if Claude hasn't finished the full change yet.
Running tests makes most sense on the Stop hook event, but personally I've found CLAUDE.md instruction of "Run `just check` after changes" to be effective enough. The Stop hook has the issue that it will run the checks every time Claude stops responding, even after without any changes.
Won't the LSP distract Claude too? I am trying to think of ways to make Claude faster at iterating by reducing tool calls. That always seems to be a bottleneck when it's doing tons of back-and-forth with tool calls.
Back when I was using CC, I had a "mandatory" development workflow that checks if the corresponding test file exists for the changed file, runs tests and runs the test coverage tool for the changed file.
References + a few extra steps will give you rename symbol. Anthropic is seemingly wanting to experiment with this - so it makes sense to limit the integration points.
It's a shame that my company tied itself to claude-code way too fast. It was like a single week last summer of, "oh what's everyone's favorite? claude? okay, let's go!"
OpenCode has been truely innovating in this space and is actually open source, and would naturally fit into custom corporate LLM proxies. Yet, now we've built so many unrulely wrappers and tools around claude-code's proprietary binary just to sandbox it, and use it with our proxy, that now I fear it's too late to walk back.
Not sure how OpenCode can break through this barrier, but I'm an internal advocate for it. For hobby projects, it's definitely my goto tool.
OpenCode had this for a while and overall has better and nicer TUI. Having said that, for same models, especially with LSP, some fancy MCPs, mgrep, has been doing really bad job lately for me. Not sure why. I expect it will be resolved soon.
Otherwise very happy with it.
Claude Code is also solid and this is welcome improvement.
This is an ignorant question, but, what is the benefit of this if you also have your project open in an editor or IDE (presuming they integrate language server?)
If you're vibe coding without an editor, would this have any benefits to code quality over a test suite and the standard linter for a language?
Also diagnostics (errors, warnings), inlay hints like types and parameters, code lens (tiny embedded buttons), symbols, notifications like “document changed”, and more
The only reason I paid my yearly JetBrains subscription this year was to keep my lower price locked-in. I've been using VS Code all year. I won't renew my JetBrains subscription that I've had since 2009. Sad.
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.
[0] https://blog.jetbrains.com/datagrip/2025/12/18/query-console...
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.
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.
I'm not sure this is true, do you have a source? Maybe conflating this with the recent Agentic AI Foundation & MCP news?
https://blog.jetbrains.com/fleet/2025/12/the-future-of-fleet...
And not the dozens of others you have? Do you not consider them also separate families?
Yeah, they completely didn’t see any of this coming.
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.
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.
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.
One thing that I'm really missing is the automatic cursor move.
They have an MCP server, but it doesn't provide easy access to their code metadata model. Things like "jump to definition" are not yet available.
This is really annoying, they just need to add a bit more polish and features, and they'll have a perfect counter to Cursor.
I much prefer their ides to say vscode, but their development has been a mess for a while with half-assed implementations and long standing bugs
This is 5% of what refactoring is, the rest is big scale re-architecting code where these tools are useless.
The agents can do this big scale architecturing if you describe exactly what you want.
IntelliJ has no moat here, because they can do well 5% of what refactoring is.
You can also access the full intellij API via groovy scripts in the filters or when computing replacement variables, if you really want.
Though most of the time built in refactors like 'extract to _' or 'move to' or 'inline' or 'change type signature' or 'find duplicates' are enough.
I was playing around with codex this weekend and honestly having a great time (my opinion of it has 180'd since gpt-5.2(-codex) came out) but I was getting annoyed at it because it kept missing references when I asked it to rename or move symbols. So I built a skill that teaches it to use rope for mechanical python codebase refactors: https://github.com/brian-yu/python-rope-refactor
Been pretty happy with it so far!
No LSP support is wild.
We have 50 years worth of progress on top of grep and grep is one of the worse ways to refactor a system.
Nice to see LLM companies are ignoring these teachings and speed running into disaster.
It seems to be very efficient context-wise, but at the same time made precise context-management much harder.
Opus 4.5 is quite a magnificent improvement over Sonnet 4.5, in CC, though.
Re tfa - I accidentally discovered the new lsp support 2 days ago on a side project in rust, and it’s working very well.
And yes +1 for opus. Anthropic delivered a winner after fucking up the previous opus 4.1 release.
They feel like different coworker archetypes. Codex often does better end-to-end (plan + code in one pass). Claude Code can be less consistent on the planning step, but once you give it a solid plan it’s stellar at implementation.
I probably do better with Codex mostly due to familiarity; I’ve learned how it “thinks” and how to prompt it effectively. Opus 4.5 felt awkward for me for the same reason: I’m used to the GPT-5.x / Codex interaction style. Co-workers are the inverse, they adore Opus 4.5 and feel Codex is weird.
Codex is an outsourcing company, you give specs, they give you results. No communication in between. It's very good at larger analysis tasks (code coverage, health etc). Whatever it does, it does it sloooowwwllyyy.
Claude is like a pair programmer, you can follow what it's doing, interrupt and redirect it if it starts going off track. It's very much geared towards "get it done" rather than maximum code quality.
Surprised that you don't have internal tools or skills that could do this already!
Shows how much more work there is still to be done in this space.
This is why I roll my eyes every time I read doomer content that mentions an AI bubble followed by an AI winter. Even if (and objectively there's 0 chance of this happening anytime soon) everyone stops developing models tomorrow, we'll still have 5+ years of finding out how to extract every bit of value from the current models.
Of course there is a bubble. We can see it whenever these companies tell us this tech is going to cure diseases, end world hunger, and bring global prosperity; whenever they tell us it's "thinking", can "learn skills", or is "intelligent", for that matter. Companies will absolutely devalue and the market will crash when the public stops buying the snake oil they're being sold.
But at the same time, a probabilistic pattern recognition and generation model can indeed be very useful in many industries. Many of our problems can be approached by framing them in terms of statistics, and throwing data and compute at them.
So now that we've established that, and we're reaching diminishing returns of scaling up, the only logical path forward is to do some classical engineering work, which has been neglected for the past 5+ years. This is why we're seeing the bulk of gains from things like MCP and, now, "agents".
This is objectively not true. The models have improved a ton (with data from "tools" and "agentic loops", but it's still the models that become more capable).
Check out [1] a 100 LoC "LLM in a loop with just terminal access", it is now above last year's heavily harnessed SotA.
> Gemini 3 Pro reaches 74% on SWE-bench verified with mini-swe-agent!
[1] - https://github.com/SWE-agent/mini-swe-agent
Sure, the models themselves have improved, but not by the same margins from a couple of years ago. E.g. the jump from GPT-3 to GPT-4 was far greater than the jump from GPT-4 to GPT-5. Currently we're seeing moderate improvements between each release, with "agents" taking up center stage. Only corporations like Google are still able to squeeze value out of hyperscale, while everyone else is more focused on engineering.
• Use `/plugin` to open Claude Code's plug-in manager
• In the Discover tab, enter `lsp` in the search box
• Use `spacebar` to enable the ones you want, then `i` to install
Hope that helps!
I am disabling it for now since my flow is fine at the moment, I'll let others validate the usefulness first.
LSP Plugin Recommendation
LSP provides code intelligence like go-to-definition and error checking
Plugin: swift-lsp
Swift language server (SourceKit-LSP) for code intelligence Triggered by: •swift files
Would you like to install this LSP plugin? › 1. Yes, install swift-lsp 2. No, not now 3. Never for swift-lsp 4. Disable all LSP recommendations
https://github.com/anthropics/claude-code/issues/14803#issue...
https://github.com/anthropics/claude-code/issues/13952#issue...
https://github.com/anthropics/claude-code/issues/13952#issue...
[1]: https://opencode.ai/
- accidental approvals when trying to queue a prompt because of the unexpected popovers - severe performance issues when pending approval (using 100% of all cores) - tool call failures
having used Crush, OpenCode, aider, mistral-vibe, Gemini CLI (and the Qwen fork), and Claude Code, the clear winner is CC. Gemini/Qwen come in second but they do lose input when you decline a requested permission on a tool call.
that said, CC also has its issues, like the flickering problem that happens in some terminals while scrolling executed command output.
But their configuration setup is the easiest and best out of all the other CLI tools
I also use OpenCode extensively, but bounce around to test out the other ones.
I keep my setup modular/composable so I can swap pieces and keep it usable by anyone (agent, human, time traveler) depending on what the task needs. In the aughts I standardized on "keep worklogs and notes on tools and refine them into runbooks" so that has translated pretty well to agentic skills/tools. (a man page is a perfectly cromulent skill, btw.)
Pretty sure Cursor has had this for a while.
CLIs can also have a small piece of code that connects to an LSP server. I don’t see why IDEs should be the sole beneficiary of LSP just because they were the first clients imagined by the LSP creators.
Yet they preferred the CLI because it felt "more natural"
With agents, and Claude Code, we are *orchestrating* ... this is an unresolved UI/UX in industry. The same reasons `kubectl` didn't evolve to GUI probably apply here.
It's less about the codebase, more about the ability to conduct anything on the computer - you are closest to that in the terminal. https://backnotprop.com/blog/its-on-your-computer/
I use Zed and unless there is some MCP server that provides the same thing as the LSP server, the Zed agent won't have access, even though it's in an IDE that supposedly has this information
https://forum.cursor.com/t/support-of-lsp-language-server-pr...
> Feature request for product/service
>
> Cursor IDE
>
> Describe the request
>
> It would be a huge step up if agent could interact with LSP (Language Server Protocol).
>
> It would offer :
>
> renaming all instances of a symbol over all files in one action
> quick navigation through code : fast find of all references to a property or method
> organize imports, format code, etc…
And last Friday a Cursor engineer replied "Thanks for the idea!"
So how does the AI agent in Cursor currently have access to LSP?
(I am most interested in having the agent use LSP for type checking, documentation of a method call, etc. rather than running slower commands)
(note, there is an open PR for Zed to pull LSP diagnostics into an AI agent thread https://github.com/zed-industries/zed/pull/42270 but it would be better if agents could make arbitrary LSP queries or something like that)
But in all seriousness, LLMs have their strengths but we’re all wasting tokens and burning the planet unnecessarily getting LLMs to work so inefficiently. Use the best tool for the job; make the tools easier to use by LLMs. This mantra is applicable generally. Not just for coding.
those wanting lsp support in the loop have been using things such as: https://github.com/oraios/serena
I’ve not noticed the agent deciding to use it all that much.
[0] https://github.com/charmbracelet/crush
Opus 4.5 is fairly consistent in running QA at proper times. Lint checks and all are already incorporated into a standard & native processes outside of IDE. I think lookup can be useful when definitions are hidden deep in hard to reach places on my disk... hasn't been a problem though the agent usually finds what it needs.
Anyway, here is what it stated it could do:
But why would that be better than LLMs using the LSP with a dedicated tool rather than a shell command tool?
Models get stupid after the first 80-100k tokens are used so keeping bloated tools out of the window unless completely necessary is a pretty hard requirement for effective AI use IMO.
Plenty of MCPs and plugins and whatnot out there idly consuming 5-25k tokens 24/7. How is that the same?
I do it all the time. I have several MCPs configured but only enable them on demand.
With a fair disclaimer, that it is very easy to vibe-code a skill oneself, with both pros (you can create one just for you!) and cons (if you look online, these are of any quality, quite a few with some hard-coded versions or practices).
Running tests makes most sense on the Stop hook event, but personally I've found CLAUDE.md instruction of "Run `just check` after changes" to be effective enough. The Stop hook has the issue that it will run the checks every time Claude stops responding, even after without any changes.
Maybe whynotboth.gif?
OpenCode has been truely innovating in this space and is actually open source, and would naturally fit into custom corporate LLM proxies. Yet, now we've built so many unrulely wrappers and tools around claude-code's proprietary binary just to sandbox it, and use it with our proxy, that now I fear it's too late to walk back.
Not sure how OpenCode can break through this barrier, but I'm an internal advocate for it. For hobby projects, it's definitely my goto tool.
One of my favorite features is that you can run it as a server, and then it has a API and SDKs to manage sessions etc.
Great to build a centrally managed agent for your team.
https://github.com/anthropics/claude-code/issues/1259#issuec...
Claude Code is also solid and this is welcome improvement.
2. https://github.com/microsoft/pyright
3. https://github.com/python-lsp/python-lsp-server
4. https://github.com/palantir/python-language-server
If you're vibe coding without an editor, would this have any benefits to code quality over a test suite and the standard linter for a language?
The LLM wants to see the definition of a function. More reliable than grepping.
It's used by most smaller editors so they can backpack off of the efforts languages make to be usable in VSC. (Vim, Emacs, Zed, etc)
They are definitely coding in a LLM maximalist way, in a good way.