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
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"
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.
>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.
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.
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.
The end of terminals has been forecast ever since mouse pointers showed up. If you build any nontrivial workflow across weird infra and hairy edge cases, GUIs locked to whatever version of "AI assistant" they're pushing will either make you faster or block you until you rage-reopen a shell.
I think there will always be a class of tool for users who want escape velocity from vendor UX conferences and forced upgrades. The moment sandboxes or walled gardens get in the way of the weird things that keep devs productive, someone will bolt a CLI to the latest AI.
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.
I often get the impulse to call people stupid fucking morons on this site, because despite how intelligent people supposedly are, they really are complete fucking morons. It will, however, get you flagged and banned.
Isn't there a point at which it trains itself on these various outputs, or someone somewhere draws one and feeds it into the model so as to pass this benchmark?
Can someone enlighten me as to what the debate here is really about? Is the concern that the implementers of age gating could steal data? Is it that one entity (the "government") would obtain information about your age, etc? Doesn't this already happy IRL? Why is an online version suddenly more draconian?
As a parent, here is my perspective:
- there is no debate about seat belts in cars. I'm not choosing whether or not my child should or should not wear them
- there is no debate about ID checking outside businesses that sell alcohol. No one is debating whether I should get to choose whether my 7 year old has alcohol or not
- pornographic content on television is already banned and we have ratings for media content
- etc
Why are "privacy" and "freedom" arguments for age-gating of internet content? As a parent, it is impossible for me to gate access or exposure to internet content like 4chan or YouTube conspiracy theorists and what not on my kids' developing brains so some mandated help sounds common sensical. And busy, poor, or uninitiated parents may not have time to invest in something like self-driven internet censoring, and I believe society as a whole benefits when every child is automatically kept safe from unsavory content (by definition a subjective phrase yet a moral choice every society must make).
I can see an argument for mandating that every parent must individually purchase an in home internet age-gating "device" (hardware, software or whatnot) as a compromise so that the gating is still done by the parent (possibly with the help of a third party of their choice) while the mandation is done by the government. But it seems overly heavy handed in the other direction to me to say everything everywhere should be accessible to everybody of every age without gating and left to individuals (often sometimes with poor, underdeveloped, or temporarily ill-advised) judgment.
Looking for someone to change my mind on some of these (or links to studies or articles making the arguments pro-freedom in this context). I'll also virtue-signal for context, that I'm fully aware of and actively mourn the ill effects of corporations like Meta, etc that vacuum up our data and build profiles and sell to data brokers, etc.
Pretty much. That is why this was a tiny personal project I did. The key for me is to be a le to track article and comments on HN for myself. I found it useful and that's why I decided to open source and make it available for everyone else.
This is depressing and not going to stop because it is so lucrative and relatively easy for these malware companies to find victims. It makes me wonder if cybersecurity should be considered a state responsibility and infrastructure so it will be uniform and available for every business like electricity or police protection.
Mason America | Lead Devops Engineer | US/Seattle | Full-time, onsite | https://www.bymason.com
Mason (YC W'16) is mobile IaaS that enables businesses to automate deployment of their own Android-based device ecosystems. Think AWS but for devices. We turned profitable in 2018, raised Series A in 2019, and are growing organically. Still an intimate team of 10 engineers in Seattle.
We're looking for a SRE/devops lead to own and evolve the cloud infra for Mason. Cloud stack is Golang/K8S/EKS mixed with Node.js/Ansible/Terraform/EC2, with several new services needing to be architected over the next few years. You have prior experience with building and scaling infrastructure, ideally understand AWS/EKS well, and think about ways to empower your team to ship early and often.
Our process: Phone screen => Take-home (or share existing body of work) => In-person architecture/design/soft skills => Offer (we adjust/shorten based on the candidate, and have been skipping the take-home step in favor of one in-person coding interview in many cases)
