Comment by beemboy | Hacker News Reader

Comment by beemboy | Hacker News Reader

Parent Full thread

I'm not convinced that terminal orientedness of AI tooling itself will last. My hypothesis is that it was chosen by developers of the current generation building for developers of the current generation. I hypothesize that there is a future where command lines and terminals don't matter, and hence I feel the focus will shift to, as the author points out, to planning, reviewing and ideation tools none of which demands a command line. In fact I expect an entirely new class of tool to emerge that does these things well that is neither an IDE nor terminal based. I think Claude Code's core will live but it's interface will morph in the coming years to adapt to the builders of the next generation. The analogy I use is my kids and manual transmission cars -- they grow up with EVs and single gear drives with linear torque curves, and will have no nostalgia for a manual transmission, engine noises, or supercharger whines. If you never used a terminal, will you pine for it?

I'm not about to put any money down - I lack that degree of confidence in my prognosticating - but I doubt the terminal will ever really vanish, for much the same reason that 20 years of touch screens hasn't really put in a dent in a keyboard and mouse for serious work, and game controllers have barely changed despite multiple attempts at VR and other interfaces, and why the stylus is still going strong after more than 5000 years. Sometimes you just get it right.

A text interface is just really damn good at efficient and precise information delivery and interaction, in a way that takes a lot more work for a GUI to match, and they are composable in a way GUIs simply are not. Most users won't - and currently don't - care about terminals, but I doubt it will ever stop being a standard tool for power users.

I don't doubt we'll see new paradigms emerge, but I think they'll come in the form of higher level abstractions for certain classes of task rather than a replacement for the sort of TUIs and GUIs we have today.

Yeah, I can’t imagine why anyone would think that moving away from the most explicit source of truth possible would make AI work any better. the things good UIs excel at is data representation, not processing. Representing a tree or a graph in text sucks. But AI can sure read a text representation of a tree or a graph and reason about it much faster than through a UI

> but I doubt the terminal will ever really vanish

I always smiled when in the various Star Trek series (pre 2005) the main crew made something in the holo deck it was always via voice commands and essentially "vibecoded", but whenever details mattered (veeeeeeery rarely, almost never) and a specialist was consulted, that'd be someone clearly looking at a mobile terminal interface

It's obviously fiction, but it amused me nonetheless... And it's possible that that's the future of our industry. But if it is, it'd consider it a dead industry, honestly. Even in that fictional universe, the value the specialist provides is almost never necessary

I have switched to pen and handwriting reckognition in apps that support it.

While using AI, if I am alone on the room, I use voice to text, no way I am typing book sized text that would make any COBOL programmar laught.

This stuff stands on the foundations it's built off of. It's very hard to argue against the stoic determinism of an `ls` call.

And all the success stories I've seen in people using these tools have had a similar theme: top level might be LLM-y but you rush to get to deterministic straightforward building blocks so that you can have reliability.

That, to me, looks like writing up a bunch of small programs to help establish vocabularies and workflows to avoid just churning and getting lost in the weeds.

I'd be interested in seeing some future form of process orientation, but in the meantime.... shells in general have proven they are decently good at tying stuff together quite well.

`ls dir | grep thingy | process` gonna involve less possibility of annoying drift and churn than "run process on all the files with thingy in their name in directory"

Coining this phrase now: "It's the tokens stupid"

Hooking up to and generating calls across filesystem APIs cost multiple orders of magnitude more than calling `ls`. These tooling ideas are interesting, though. Maybe Kenneth_E._Iverson was right all along?

Talking to another senior dev over drinks tonight, we both worried not about our work but about who might come up never having written a single line of code. Never even opened a terminal. Is looking at the code something you learn in semester 5?

I think computer science education is going to stomp onward, poorly. And we will get that generation. And things like "terminal tooling is going out of style" won't even be said any more. Hacker groups will turn from discussions about new ideas to talking about doing leetcode without AI.

Our art died because we used our art to kill it. We are the last human masters.

That's a funny thing to think about.

>Hooking up to and generating calls across filesystem APIs cost multiple orders of magnitude more than calling `ls`. These tooling ideas are interesting, though. Maybe Kenneth_E._Iverson was right all along?

I don't think you understood what the idea was. Its not about calling `ls` vs not. I don't think UNIX commands are going away (or at least deterministic calls).

Its the interface itself that would go away. We won't work on terminals but some other interface which would use commands internally.

Yeah, in the future we will mourn the loss of the art of creating a new JS framework every week.

A terminal still offers a more composable interface than a GUI. Analog feedback is still a concern for high level pilots. You are confusing power tools with entry-level instruments.

I won't debate this. I'm a fan of the enduring pipe operator and the simple elegance of process composition in *nix. My point was more: what will we need them for? To review code written by a bot? GUI tools are better for this IMHO, or at least, terminals aren't any better than GUI tools, possibly worse. To read the plan output of Claude code, why would I want raw markdown in a terminal when I can read the formatted output as intended in a different tool?

To be clear, I'm not suggesting "the future is IDEs/GUI/etc" but that it's some potentially new refinement over TUIs and GUIs where the focus is no longer on editing, tinkering, debugging, but perhaps new tools that make it easier and efficient to work with agent swarms and give them instruction/prompts.

interesting, what do you mean by composable?

Albeit it's the shell, I assume he means piping

That has less to do with terminal than unix commands no?

Piping is a feature of the shell, not the terminal.

But composable means that cli tools produces text, consume text, and are configured through text. You can build independent tools to do separate task and then build a meta tools that coordinate them. While the individual tools may be complex, the coordination can be very easy. With posix shells, you have piping and subshells that do a lot of the heavy lifting.

Piping is implemented in the shell (bash, zsh, etc...), not the unix commands themselves nor the terminal emulator. Whether the above discussion was using the word "terminal" to refer to the terminal emulator, the shell, or the whole combined experience is anyone's guess.

I think AI tooling has actually reminded us how useful the terminal really is. running claude code, running formatters and linters and test suites, managing incremental work with git etc. Are all vital in the modern way we write code. I don't see how you can put a glossy UI on top of that and maintain any fine-grained control. Since we're already giving up a LOT of control by having agents write our code, we need to retain some control and certainty over the quality control and review process of the outputs.

I'm somewhat agreeing with it. CLI tools won't go away, since lines of text as an exchange format between tools is extremely powerful, especially with text based LLMs. However using an interactive TUI application to prompt agents will probably be less relevant in the future. E.g. if I want to build a web frontend, why wouldn't I just prompt and interact directly on the side I'm building?

My current assumption is that the interfaces and workflows that stakeholders and product owners use today to manage software engineering resources are the future interfaces and workflows towards agentic engineering systems.

Reply on news.ycombinator.com