Why are developers switching to CLI-based coding agents?

Question

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?

PaulHoule · Accepted Answer

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?

dysoco · Answer

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.

jf22 · Answer

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.

fmw · Answer

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?

dv_dt · Answer

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.