Hacker News Reader

Comment by verdverm | Hacker News Reader

I don't get why terminal agents are so popular of late. Having spent more than a decade in terminal based development (vi*), and now fully moved over to a real IDE (vs code), it seems bonkers to me. The IDE is so much more... integrated

View on HN

At this point, TUI's still feel like the most streamlined interface for coding agents. They're inherently lighter weight, and generally more true to the context of dev environments.

"Feels like" is a subjective measure. For example, Gemini CLI does feel inherently lighter than something like VS Code. But why should it? It's just a chat interface with a different skin.

I'm also not sure whether Gemini CLI is actually better aligned with the context of development environments.

Anyway—slightly off-topic here:

I’m using Gemini CLI in exactly the same way I use VS Code: I type to it. I’ve worked with a lot of agents across different projects—Gemini CLI, Copilot in all its LLM forms, VS Code, Aider, Cursor, Claude in the browser, and so on. Even Copilot Studio and PowerAutomate—which, by the way, is a total dumpster fire.

From simple code completions to complex tasks, using long pre-prompts or one-shot instructions—the difference in interaction and quality between all these tools is minimal. I wouldn’t even call it a meaningful difference. More like a slight hiccup in overall consistency.

What all of these tools still lack, here in year three of the hype: meaningful improvements in coding endurance or quality. None of them truly stand out—at least not yet.

> None of them truly stand out

I don't think any will every truly stand out from the others. Seems more like convergence than anything else

I like them because the interface is consistent regardless of what editor/IDE I'm using. Also frequently I use it to do stuff like convert files, or look at a structure and then make a shell script to modify it in some way, in which case an IDE is just overhead, and the output is just something I would run in the terminal anyway.

Integration trades convenience for flexibility.

For me, a terminal environment means I can use any tool or tech, without it being compatible with the IDE. Editors, utilities, and runtimes can be chosen, and I'm responsible for ensuring they can interop.

IDEs being convenience by integrating all of that, so the choice is up to the user: A convenient self contained environment, vs a more custom self assembled one.

Choose your own adventure.

VS Code has the terminal(s) right there, I'm not missing out on any tool or tech

What I don't have to do is context switch between applications or interfaces

In other comments I relayed the sentiment that I enjoy not having to custom assemble a dev environment and spend way too much time making sure it works again after some plugin updates or neovim changes their APIs and breaks a bunch of my favorite plugins

Because integrating directly with very large varities of editors & environments is actually kind of hard? Everyone has their own favorite development environment, and by pulling the LLM agents into a separate area (i.e. a terminal app) then you can quickly get to "works in all environments". Additionally, this also implies "works with no dev environment at all". For example, vibe coding a simple HTML only webpage. All you need is terminal+browser.

All of the IDEs already have the AI integrations, so there's no work to do. It's not like you don't have to do the equivalent work for a TUI as an IDE for integration of a new model, it's the same config for that task.

> works with no dev environment at all

The terminal is a dev environment, my IDE has it built in. Copilot can read both the terminal and the files in my project, it even opens them and shows me the diff as it changes them. No need to switch context between where I normally code and some AI tool. These TUIs feel like the terminal version of the webapp, where I have to go back and forth between interfaces.

The words "the AI integrations" are doing some weird work there, right? Agents all have opinionated structure, which changes how effective they are at working on different kinds of problems.

By AI (model) integrations, it's mostly pointing at a URL and what name the API keys are under in ENV. Everyone has pretty much adopted MCP for agents at this point, so also very standardized integration there too

MCP is a pretty minor detail relative to all the other design decisions that go into an agent? A serious agent is not literally just glue between programs and an upstream LLM.

Not new to AI agents, either. I'm sure you can set up vim to be like an IDE, but unless you're coding over ssh, I don't know why it's preferable to an actual IDE (even one with vim bindings). GUIs are just better for many things.

If the optimal way to do a particular thing is a grid of rectangular characters with no mouse input, nothing prevents you having one of those in your GUI where it makes sense.

For instance, you can look up the documentation for which keys to press to build your project in your TUI IDE, or you can click the button that says "build" (and hover over the button to see which key to press next time). Why is typing :q<enter> better than clicking the "X" in the top-right corner? Obviously, the former works over ssh, but that's about it.

Slowness is an implementation detail. If MSVC6 can run fast enough on a computer from 1999 (including parsing C++) then we should be able to run things very fast today.

Clicking X at the top right corner... Not exactly muscle memory. Way slower than ;q

Wait til you find out you can do ;q in vscode too

I primarily code over ssh with VS Code Remote to cloud vm instances

Ever heard of Emacs? WPE for terminals as a C/C++ IDE? Free Pascal?

Being some IDE for a terminal doesn't mean you can't have menues and everything must be driven with vi modal keys and commands.

It seems like you might have missed the gap between vi and modern terminal based development. Neovim with plugins is absolutely amazing and integrated, there are even options like Lazyvim that do all the work for you. I took the opposite journey and went from IDE to Neovim and I'm glad I did. vs code is a bunch of stuff badly cobbled together in a web app, running in Electron. It's a resource hog and it gets quite slow in big projects. Neovim had a much higher learning curve but is so much more powerful than vs code or even jetbrain stuff in my opinion and so much snappier too

> It seems like you might have missed the gap between vi and modern terminal based development.

No, I used neovim and spent way too much time trying to turn it into an IDE, even with the prepackaged setups out there

VS Code is sitting below 5% CPU and 1G of memory, not seeing the resource hog you are talking about. LSPs typically use more resources (which is outside and the same for both)

Neo(lazy)vim user here.. not sure what I'm missing from IDE...

Language server, check, Plugin ecosystem, check, Running tests on demand, check. lua sucks but that's an acceptable compromise as vimscript is worse.

Mice are good and the terminal doesn't make the best use of the information density possible on modern displays.

You can use a mouse with a terminal. Also one could argue that you opt into your own level of information density.

My experience is the opposite. Terminal UIs make better use of information density because they don’t have ridiculous padding between widgets and other graphical chromes that modern GUIs have.

Also terminals support mice. Have done for literally decades.

Ultimately though, it just boils down to personal preference

Modern terminal emulators run at native resolution and support window splitting. You can have the exact same information density (I'd argue that a nice neovim environment has more information density than most IDEs since vs code and jetbrains seem to love putting extra space and padding everywhere now.)

Terminal emulators can only do exactly that. Emulate increasingly large terminals. They are almost fundamentally unable to render something smaller than a single character.

I was neovim in the end, 100% agree lua is so much better than vimscript, but now I don't need either. I spend no time trying to match what an IDE can do in the terminal and get to spend that time building the things I'm actually interested in. I recalled Linus saying the reason he (at the time) used Fedora was because it just worked and he could spend his time on the kernel instead of tinkering to get linux working. This is one of the biggest reasons I stopped using (neo)vim

I had lots of problems with plugins in the ecosystem breaking, becoming incompatible with others, or often falling into unmaintained status. Integrations with external SaaS services are much better too

Also information density (and ease of access) as a peer comment has mentioned

> match what an IDE can do in the terminal and get to spend that time building the things

This is a common complaint but I haven't done any setup for months.. And installing a language server because I need to write typescript is just <leader>cm and then lllll on the servers I need.

For me, the workflow that Claude Code provides via VSCode plugins or even IntelliJ integration is great. TUI for talking to the agent and then some mild GUI gloss around diffs and such.

I like terminal things because they are easy to use in context wherever I need them - whether that's in my shell locally or over SSH, or in the integrated terminal in whatever IDE I happen to be using.

I use vim if I need to make a quick edit to a file or two.

Idk, terminal just seems to mesh nicely into whatever else I'm doing, and lets me use the right tool for the job. Feels good to me.

My VS Code has a terminal and can remote into any machine and edit code / terminal there.

What I don't get is going back to terminal first approaches and why so many companies are putting these out (except that it is probably (1) easy to build (2) everyone is doing it hype cycle). It was similar when everyone was building ChatGPT functions or whatever before MCP came out. I expect the TUI cycle will fade as quickly as it rose

I think a fairly large number of people using IDEs use them for the writing code coding part almost exclusively, e.g. don't use many/any of the other "integrated" features like VCS integration, build integration, etc. As an example, I think most people I've seen use vscode still use git via the cli (less sure but I'd guess most of them use a separate terminal even).

I don't know for sure or have anything besides anecdotal evidence but I'd wager this is a majority of vscode users.

I like them because they're easier to launch multiple instances of and take fewer resources. Being able to fire agents off into tmux sessions to tackle small-fry issues that they can usually oneshot is a powerful tool to fight the decay of a codebase from high prio work constantly pushing out housekeeping.

I think it lets developer concentrate their energy on improving the agentic experience, which matters more right now. It's hard to keep up with all the models, which the developers have to write support code for. Once the products mature, I bet they'll go visual again.

I also use IDEs and I think people who use terminal-based editors are lunatics but I prefer terminal-based coding agents (I don't use them a lot to be fair).

It's easier to see the diff file by file and really control what the AI does IMO.

On another note VS Code is not an IDE, it's a text editor.

Copilot opens the files and shows me the diff, that is not missing in the IDE

Perhaps your definition of IDE is more restrictive. I see VS Code as my environment where I develop with masses of integrations

Terminal based editors can work as an IDE too, with diff and the like. EMacs it's like that and it has magic, ediff and who knows what. And VIM can do the same, of course.

> a real IDE (vs code)

Much better to use Neovim than a very clunky slow editor like VS Code or Jetbrains just to edit a text file.

The keyboard is far faster than clicking everywhere with the mouse.

This gets said a lot, but it's not like vscode doesn't have keyboard support.

I wouldn't have made the switch if I was not able to keep my vim movements and modes. There's a great extension `vscodevim` that even implements some of the common extras like vim-motion

I use the Vim plugin to keep my keyboard navigation, editor modes, and such... best of both worlds.

I think the sentiment that VS Code is clunky and slow is outdated. I have seen no noticeable impact since moving over from neovim

IDEs are slower, use more battery/ram/cpu and are ugly without adding any features.

it's the flexibility, no need for packaged extensions, just compose / pipe / etc..

Reply on news.ycombinator.com