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

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.

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.

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

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?

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.

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.