There are still people not even using an editor, but rather using vibe-coding apps like lovable.
Also,I don't mean to be rude to cursor but the fact that they are literally just a vscode wrapper still, to this day makes me really crazy thinking that the value of an AI editor could be so high..
I think it was the lack of competition really, Cursor (IMO) always felt like the biggest player, I think there was continue.dev before that, but that's all I know before Cursor.
After Cursor became a hit, there are lot more things now like (Void editor?) etc.
Also, if you Find Vscode editor slow, try zed. But like my brother said to me when I was shilling zed, Vscode is just for manipulating texts and using LSP. He personally didn't feel like it was there any meaningful slowness to Vscode even though he had tried zed. Zed has Ai stuff too iirc
Now Sure, they could've created CLI, but there are a lot of really decent CLI like SST/opencode and even gemini cli. Though I have heard good things about claude code too.
Honestly, I just think that any efforts in anything is cool. I just like it when there are a lot of options and so things stay a little competitive I guess.
Isn't that like all software. Before Claude 4 and Copilot agent mode, Cursor/Cline did a lot of work under the hood to achieve the same agentic capabilities, that stuff has nothing to do with VSCode.
Stay tuned! I think there is definitely room for a CLI version as well. That said, IDE's have a significant advantage over CLI because of the features available to them. For example, the reason why IDE's feel "slow" is often because they just come with more features: automatic linters and code formatters, type checkers, LSP servers.
An agent running in the IDE can make use of all this context to provide better results. So, for example, you will see Kiro automatically notice and attempt to resolve problems from the "Problems" tab in the IDE. Kiro will look at what files you have open and attempt to use that info to jump to the right context faster.
The way I describe it is that the ceiling for an IDE agent is a lot higher than a CLI agent, just because the IDE agent has more context info to work with. CLI agents are great too, but I think the IDE can go a lot further because it has more tools available, and more info about what you are doing, where you are working, etc
That's all old news. Claude Code and even Amazon Q CLI can leverage all this context through MCP as well, with connecting to LSP servers, computing repo-maps or code indexes, integrating with linters, etc.
In my opinion, CLIs have a higher ceiling, and then they are easy to integrate into CI/CD, run them in parallel, etc.
MCP is great, but it adds a lot of extra latency. The MCP servers themselves will stuff your context full of tool details, taking up valuable tokens that could be spent on code context. Then at runtime the LLM has to decide to call a tool, the tool call has to come back to your machine, the data is gathered and sent back to the LLM, then the LLM can act on that data. Multiply this by however many rounds of tool use the LLM decides it needs prior to taking action. If you are lucky the LLM will do a single round of parallel tool use, but not always.
The advantage of something more purpose built for gathering context from the IDE is that you can skip a lot of roundtrips. Knowing the user's intent upfront, the IDE can gather all the necessary context data preemptively, filter it down to a token efficient representation of just the relevant stuff, add it in the context preemptively along with the user's prompt, and there is a single trip to the LLM before the LLM gets to work.
But yeah I agree with your point about CLI capabilities for running in parallel, integrating in other places. There is totally room for both, I just think that when it comes to authoring code in the flow, the IDE approach feels a bit smoother to me.
I feel what you say is true only for auto-complete, which is no longer the ideal workflow for agentic coding. Otherwise the IDE doesn't know what it should include or not in the context, and you need an AI model to determine that.
What people do to avoid what you discussed, is multi-agents. The main agent can build up context, plan, than delegate execution to other agents, etc.
In my opinion, the benefit of the IDE is really just in the possibility of an improved UI/UX over a TUI.
- cmd-t fuzzy finding files of cmd-p finding symbols to open the various files that are relevant
- selecting a few lines in each file using fast IDE shortcuts to move and add
- drag and drop an image or other json files into prompt
- not leave the editor im already working on
Not to mention:
- viewing the agents edits as a diff in the editor and all the benefits of easily switching between tabs and one click rejecting parts etc
- seeing the sidebar of the agents thoughts and progress async alongside the code as I keep looking at things
- pausing the agent and reversing back steps visually with the sidebar
- not having to reconfig or setup my entire dev environment for some CLI - for example the biome v2 lsp just works since it’s already working in code which has the best support for these things
And really the list of reasons an editor is far better just never ends. Claude is ok, but I’m way way faster with Cursor when I do need AI.
To each their own, and I absolutely agree with the prior poster about both existing making a lot of sense. It comes down to personal preference. I just wanted to point out the CLI has no less support for feature and context, just a different UX to them.
The next level of features I want from Claude Code is LSPs built right into it, rather that something I have to configure with some random MCP server I download from some random place.
They already have a CLI that is similar to Claude Code: Amazon Q CLI, you can download it here: https://github.com/aws/amazon-q-developer-cli
It actually has a pretty decent free tier, and maybe the subscription is better value than Claude Code, but hard to tell.
There are still people not even using an editor, but rather using vibe-coding apps like lovable.
Also,I don't mean to be rude to cursor but the fact that they are literally just a vscode wrapper still, to this day makes me really crazy thinking that the value of an AI editor could be so high..
I think it was the lack of competition really, Cursor (IMO) always felt like the biggest player, I think there was continue.dev before that, but that's all I know before Cursor.
After Cursor became a hit, there are lot more things now like (Void editor?) etc.
Also, if you Find Vscode editor slow, try zed. But like my brother said to me when I was shilling zed, Vscode is just for manipulating texts and using LSP. He personally didn't feel like it was there any meaningful slowness to Vscode even though he had tried zed. Zed has Ai stuff too iirc
Now Sure, they could've created CLI, but there are a lot of really decent CLI like SST/opencode and even gemini cli. Though I have heard good things about claude code too.
Honestly, I just think that any efforts in anything is cool. I just like it when there are a lot of options and so things stay a little competitive I guess.
> just a vscode wrapper
Isn't that like all software. Before Claude 4 and Copilot agent mode, Cursor/Cline did a lot of work under the hood to achieve the same agentic capabilities, that stuff has nothing to do with VSCode.
Stay tuned! I think there is definitely room for a CLI version as well. That said, IDE's have a significant advantage over CLI because of the features available to them. For example, the reason why IDE's feel "slow" is often because they just come with more features: automatic linters and code formatters, type checkers, LSP servers.
An agent running in the IDE can make use of all this context to provide better results. So, for example, you will see Kiro automatically notice and attempt to resolve problems from the "Problems" tab in the IDE. Kiro will look at what files you have open and attempt to use that info to jump to the right context faster.
The way I describe it is that the ceiling for an IDE agent is a lot higher than a CLI agent, just because the IDE agent has more context info to work with. CLI agents are great too, but I think the IDE can go a lot further because it has more tools available, and more info about what you are doing, where you are working, etc
> For example, the reason why IDE's feel "slow" is often because they just come with more features:
IDEs don't feel slow, they ARE slow
because written in HTML and Javascript
go and try Delphi from 2005, it's blazing fast (and more functional...)
I'm surprised none of them have built on Zed yet
Rust is too hard when you can quickly fork vscode and hack together enough JavaScript to hopefully get acquired before the moat evaporates.
That's all old news. Claude Code and even Amazon Q CLI can leverage all this context through MCP as well, with connecting to LSP servers, computing repo-maps or code indexes, integrating with linters, etc.
In my opinion, CLIs have a higher ceiling, and then they are easy to integrate into CI/CD, run them in parallel, etc.
MCP is great, but it adds a lot of extra latency. The MCP servers themselves will stuff your context full of tool details, taking up valuable tokens that could be spent on code context. Then at runtime the LLM has to decide to call a tool, the tool call has to come back to your machine, the data is gathered and sent back to the LLM, then the LLM can act on that data. Multiply this by however many rounds of tool use the LLM decides it needs prior to taking action. If you are lucky the LLM will do a single round of parallel tool use, but not always.
The advantage of something more purpose built for gathering context from the IDE is that you can skip a lot of roundtrips. Knowing the user's intent upfront, the IDE can gather all the necessary context data preemptively, filter it down to a token efficient representation of just the relevant stuff, add it in the context preemptively along with the user's prompt, and there is a single trip to the LLM before the LLM gets to work.
But yeah I agree with your point about CLI capabilities for running in parallel, integrating in other places. There is totally room for both, I just think that when it comes to authoring code in the flow, the IDE approach feels a bit smoother to me.
I feel what you say is true only for auto-complete, which is no longer the ideal workflow for agentic coding. Otherwise the IDE doesn't know what it should include or not in the context, and you need an AI model to determine that.
What people do to avoid what you discussed, is multi-agents. The main agent can build up context, plan, than delegate execution to other agents, etc.
In my opinion, the benefit of the IDE is really just in the possibility of an improved UI/UX over a TUI.
It’s so much easier for me to prompt by:
- cmd-t fuzzy finding files of cmd-p finding symbols to open the various files that are relevant
- selecting a few lines in each file using fast IDE shortcuts to move and add
- drag and drop an image or other json files into prompt
- not leave the editor im already working on
Not to mention:
- viewing the agents edits as a diff in the editor and all the benefits of easily switching between tabs and one click rejecting parts etc
- seeing the sidebar of the agents thoughts and progress async alongside the code as I keep looking at things
- pausing the agent and reversing back steps visually with the sidebar
- not having to reconfig or setup my entire dev environment for some CLI - for example the biome v2 lsp just works since it’s already working in code which has the best support for these things
And really the list of reasons an editor is far better just never ends. Claude is ok, but I’m way way faster with Cursor when I do need AI.
To each their own, and I absolutely agree with the prior poster about both existing making a lot of sense. It comes down to personal preference. I just wanted to point out the CLI has no less support for feature and context, just a different UX to them.
The next level of features I want from Claude Code is LSPs built right into it, rather that something I have to configure with some random MCP server I download from some random place.
What kind of toaster are you running vscode on, it runs about as fast as any basic text editor even in VMs for me.