Why Are Developers Switching to CLI-Based Coding Agents?
Mood
calm
Sentiment
mixed
Category
other
Key topics
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?
The author observes a trend of developers switching from Cursor to CLI-based coding agents like Claude Code, sparking a discussion on the reasons behind this shift and the benefits of CLI-based tools.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
10m
Peak period
10
Day 1
Avg / period
6
Based on 12 loaded comments
Key moments
- 01Story posted
Sep 3, 2025 at 9:09 AM EDT
3 months ago
Step 01 - 02First comment
Sep 3, 2025 at 9:19 AM EDT
10m after posting
Step 02 - 03Peak activity
10 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 5, 2025 at 6:15 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
I use Windsurf and I've never cared about any IDE integration. Windsurf may as well be a terminal app.
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.
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?
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.
I like the cursor experience more.
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 :)
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.
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.
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.