Comment by NathanKP | Hacker News Reader

Comment by NathanKP | Hacker News Reader

Parent Full thread

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...)

Confidently wrong are we? I use VSCode daily with a couple of extensions and it's fast, never stutters and I never have to wait for anything, so I'm not sure where you pulled that one from.

It's not an IDE, and it's actually pretty sluggish.

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.

Reply on news.ycombinator.com