But until language servers, IDEs with built-in code analysis had a huge advantage. This stopped once LSP was designed and some language servers got mature. LSP was developed originally by VS Code and it is easy to see why - it allowed VS Code to compete with IDEs without writing their own code analysis by letting language developers write a standard server. This made VS Code (and others like Zed) so powerful, that they had already replaced IDEs for many users (maybe outside Java). LLMs are just another nail in the coffin.
If you use ideavim you can enable feature which shows you action ID you have currently triggered (Ideavim: Track action IDs). If you click on anything it will show you name of that action and you can setup vim shortcut for that. This way, you can use almost anything by just typing a few letters. But that is just a start.
Now imagine you can use this to create "macro" which will create something like skill for LLM. So in a few seconds to minutes you can create "skills"/runbooks for major refactorings, project updates, git bisections, project deployments, log analysis or whatever you can think of. You will just click on 20 features and it will record what you did with some additional context (files, connected services, build systems etc.). This is the strength of integrated tools.
Of course this is just my imagination but I am not the smartest person in the world and I am pretty sure/hope that someone in jetbrains or in other IDE company is thinking this way.
I think that world is farther off than you think, especially in critical line of business software. You can YOLO it with your internal dashboard or your hipster coffee review site, but in my 2M-line highly regulated banking system, humans sign off on the code - even if LLMs do most of the typing.
No, it didn't stop. In my experience, LSPs are still incredibly poor and comparatively primitive vs the actual analysis that JetBrains have implemented. It's night-and-day different in terms of the supported refactorings, actual understanding of the types and the codebase etc.
Also, LSP is just poorly designed and inefficient. JSON-RPC was an awful choice, the specification text is not well-written and the whole thing feels like a Microsoft pet project for VS Code than an open specification that everyone agrees works well.
Not many did that because JetBrains never cared much to properly document this path, and so using LSPs is a better paved cowpath. But that's because IDEs aren't a real business for Microsoft, whereas they are for JetBrains, and we know where that leads - the landscape is filled with the skeletons of dead IDEs that were just loss making corporate side projects, defunded and "donated" to some foundation once the executive sponsors moved on. NetBeans and Eclipse are two of the most obvious but there have been others.
The risk with VS Code is it goes the same way. Eventually Microsoft needs to cut back, perhaps due to needing more capital for AI or due to AI related losses, and in the general layoffs that follow VS Code gets cut back to a skeleton crew.