May be splitting hairs, but I don't think it's the terminal-native part that's relevant, so much as that both LLMs and emacs/vim are text oriented in ways which e.g. VSCode isn't. (Or perhaps just the text-oriented nature is a result from initial constraint from being terminal-native).

As the author points out, that Emacs is a highly extensible 'operating system' which makes it relatively easy to bring different tasks together. -- This ought to be a natural parallel to what the agentic tools are trying to do (use MCPs and skills etc. to bring different functionality to the LLM execution environment).

That LLMs can help users extend emacs ought to lower the difficulty curve.

Still. It's silly to wish that Emacs could be the LLM's best friend, rather than demonstrating how it is.

RE: "what if in the future all coding skills are irrelevant". My experience has been that good results from LLMs come from putting good thought into its usage. They're quite far from a magic "push the button and get the result you want" where the skill doesn't matter.

Not totally related to your point BUT I’d like to tack on that lisps and generally repl-friendly languages are in an interesting spot in the LLM-enabled world.

The calva-backseat-driver vscode extension runs an MCP that lets LLMs manipulate and eval clojure expressions in a REPL. It provides a tighter feedback loop and lets LLMs do much more complicated stuff with much more confidence. They can test functions as they go, read docs, check query outputs, write and eval tests. It’s actually crazy what Claude opus can do with REPL access.

It might be insanity to let an LLM modify your emacs on the fly, but I’m sure people will have some crazy and interesting ideas in that vein!