Ask HN: Why are developers switching to CLI-based coding agents? | Hacker News Reader

Ask HN: Why are developers switching to CLI-based coding agents?

9 pointsjust_human12 comments

In the last few months, most of the engineers I know have switched from Cursor to CLI-based agents (mostly Claude Code). I personally love anything CLI-based, but I've been surprised to see developers who almost never open a terminal now becoming Claude Code and terminal power users overnight.

Technically, there isn't a real need for agents to run in the terminal - an agent running in Cursor chat can use the shell as a tool and arguably has a nicer UI. The value you'd normally get from CLI tools (piping I/O, composability) doesn't really apply to how these agents are being used.

My theory is twofold. First, you get better value using CLI agents like Claude Code because you don't need to pay a "toll" to an IDE like Cursor. Second, there are some killer features in Claude Code like "plan mode" that wouldn't have been possible for Anthropic to build without controlling the experience. But curious to hear what others think, and whether CLI-based agents are here to stay?

Well as far as I'm aware and also from my little experience, Claude Code is quite better and it seems simpler to use than Cursor, it's also IDE/editor agnostic. So it's not about using CLI applications it's about the fact that these last batch of tools happen to be CLI applications.

Me personally I'm not a fan of CLI applications and would rather have a nice but simple UI with nicer text rendering, pusheable buttons, etc. but probably these companies wanted something quick to get running. However for this use-case it's not that bad, it works just fine.

Also I can run it via SSH which is very helpful.

> probably these companies wanted something quick to get running I've been wondering about that. Assuming that's the case, it seems like eventually CLI will be replaced with a nice UI-based editor.

The terminal is a excellent abstraction layer to work around the limitations of LLMs. Tools like grep, the composability of commands through UNIX piping, for example.

You can develop something like that from scratch and make it available to an LLM, but why not reuse a proven technology that provides a perfect framework for the LLM to interact with?

For me it's because having an agent actively working and modifying files feels better off on another cloned repo - and a terminal window is a lightweight observation 'window' into that activity. Git cli/tig/sublime merge is what I then use to review changes.

When the IDE is up and looking at the same work files, I'd find myself forgetting changes were being actively made, and I'd start making changes that should have been on another independent area of work. Having multiple full IDE windows feels like a waste of space or switching the IDE both have a small but non-zero level of added context switch friction/annoyance at least for me.

I actually don't know if this will stay my working pattern w/ AI or not, but it's been stable this way for a little bit anyway.

Personally it's the mentality of a CLI-tool over an IDE-tool.

I found Cursor's approach very distracting. It's always there making autocomplete suggestions and always available in the sidebar. This means you have lower-quality interactions with it.

With Claude on the other hand, I usually have to think before I use it. It doesn't favour quick questions. This means I have higher quality interactions with it, after I've thought through exactly what I want it to do.

Personally I like running agents in a container, and so a terminal program works better for me.

Some time ago an agent running on the host started editing something in my Library/Application Support folder (on macOS), even though it was „soft sandboxed” (i.e. through the IDE setting and my system prompt) to the project folder in Documents.

Even though the edit was kinda sorta justified, it scared me because I realized that AI could silently change my OS settings and I might not realize that.. Fun times :)

I have used both claude code and cursor heavily. TBH, I don't like the terminal ui of claude code. it is difficult to send an images for it to view (I have to hold shift), text wrapping messes up when you resize the panel, (I have to do this often on my small laptop), and you get weird ui refresh when you type once your terminal gets very long (likely they are doing some kind of text reflow).

I like the cursor experience more.

Junie (integrated with the Jetbrains IDE) has an "ask" mode where you can ask it questions but it won't change the code -- how is that different from plan mode?

There’s nothing special imo about it being in the terminal run as a command. It’s just nice that it can do stuff in the terminal, and it could have done this as an electron wrapper app.

The only reason I use Claude code is because I prefer its performance/results over using something else.

I was using cursor before through VSC. Instead of the side panel now I just have a pinned terminal on the right in which I use CC.

Why did everyone use _____ framework? Because everyone else was doing it. Nothing is here to stay, everyone is operating in a sandbox right now.

I'd invert the question and ask why AI coding tools need a UI?

I use Windsurf and I've never cared about any IDE integration. Windsurf may as well be a terminal app.

I still find value in the code editor. I often switch between manually editing code and letting Claude Code run free on smaller tasks, but I haven't gotten close to the point where it can write 100% of the code.

Reply on news.ycombinator.com