Emacs and Vim in the Age of AI

I'm a muggle when it comes to vim, but I've considered learning it again recently because of AI. I'm building more than I have in years because I love being able to try things out without investing 3 months to get something working before I can really test the idea. And so I am typing A LOT. Less code, but lots of markdown, prompts and config. My hands are hurting, I really wish I had a power tool for typing. Writing is always going to allow us to be more precise than speech, and is a tool for creative thought in its self. I can see how we might be bearish on our expectations around new adoptees, but I think there's pressure to get more out of our editors too. Two of my recent projects have been vscode extensions, because I'm needing more help from my editor, not less: https://www.appsoftware.com/blog/fixing-agent-llm-context-de..., https://www.appsoftware.com/blog/as-notes-turn-vs-code-into-...

In my view, Emacs is getting more powerful in the AI era. The cost of writing Elisp has dropped significantly — I've ended up with 15+ personal Elisp packages as a result. The freedom Emacs offers is still unmatched. For example, I heavily rely on automatic response snippets (https://github.com/ywatanabe1989/emacs-claude-code) and creating targeted context from dired.

I have been a die hard emacs user for 20 years, and I have a very nice emacs setup (if a little bit idiosyncratic, but all emacs configs are idiosyncratic). However, recently I realized that I read code, but almost never write it. What is more, I spend a lot of time doing it in tmux, over mosh, from my phone. Emacs ergonomy is just not great if all you have is a horrible phone keyboard (and no swiping, because tmux redraws the screen if you swipe). And then I discovered helix. It has all the things I was jealous about vim, BUT it has sane defaults ootb. And truth be told, another thing I use a lot is bat, which is cat with syntax highlighting and an automatic pager.

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?

How much of this article was AI written? I can sense the AI smell all over the place, also I found it way too long with little substance, but maybe that’s just me.

In my mind I had the opposite picture than the one the article portrays.

Emacs was lagging behind common IDEs, like IntelliJ and VsCode, cause big companies put thousands of developers to combine many features into one integrated package and everything works together providing a very smooth experience compared to Emacs (and Vim probably).

Now IDEs are useless. I personally haven't felt the need to goto_definition or autocomplete variable names for almost 2 years.

Now programming becomes closer to plain text writing and editing and it levels the playing fields for all editors.

Also Emacs can run Rust plugins, the user is not limited to Elisp. Not very convenient but possible.

Agreed.

We should also consider whether the rise of AI for any type of implementation task will reduce the number of new Emacs and Vim users, thereby limiting and ultimately killing the communities' growth.

I came to Vim, and then Emacs, because I wanted a tool for coding that I could configure exactly how I liked. If AI does my coding for me, my need for a custom editor will decrease. More generally speaking, if AI can do any type of implementation task -- coding, task management, email, etc -- my need for software customized for those things will decrease.

If people don't need custom software, many fewer people may seek out and find Emacs and Vim.

Who will maintain them and evangelize once today's generation cannot?

I have been an emacs user for almost a decade now.

My laptop taskbar is: terminal, filebrowser, emacs, firefox.

With emacsd running to make startup instance.

This week I removed emacsd service and Emacs from my taskbar because I had more miss-clicks - accidentally opening it - than I had need for it in the past few months.

I find Emacs better than ever in the age of AI. Install agent-shell to run Claude Code inside Emacs and give it a skill to run Emacs Lisp using emacsclient. Voila - now you have all the integration you could ever need if you are a little resourceful.

Claude Code can now introspect the entire editor and it can manipulate everything. You can have it build whatever features are missing - it will even debug those features for you, live in the editor.

I recently came back to Emacs from VSCode and ended up just letting Claude build me the features I was missing, mainly related to tabs and project management.

I think Emacs has unique advantages in the age of LLMs, you can just mold it like clay.

Agreed on the config. I just launch a Claude code in my vimrc directory now if I want to change anything about my setup or have any questions about how to do something.

Also, I love running a tmux pane for vim, and then like 4 or 5 more -- a few Claude code instances, one for the dev environment, one for interacting with jj/git or other random commands. So easy to switch between tasks. My main annoyance with my setup is that my Bluetooth trackball times out after a period of inactivity, and when I eventually need to use the pointer again there's a lag while it reconnects...

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.

Yeah, I use Slime in vim to drive programs (like psql) via their stdin/stdout, so an "agent" that does stdin/stdout only for UI is perfect.

If I ever write my own agent, it will be in this fashion.

-----------------

[1] I have a `scratchpad.sql` file filled with whatever sql snippets I am testing and have `psql mydbname` in a vertical split. Doing C-c C-c in the scratchpad sends the paragraph to the psql instance.

emacsclient + codex has been a game changer.

I probably add or change a feature in emacs once a day, or every other day. I've been using emacs for some insane amount of time, maybe 20 years? And still I had more customization to go.

Emacs and programs with it's level of programmatic user customization will survive the AI period in my opinion. Anything static will falter.

With the idea of the recent HN article that files are the common media of communication between humans and LLM's, it's still useful to have direct file-skills; to be able to read raw files the LLM outputs, or give it input through files, and able to manipulate the files efficiently. You can use an LLM to prompt to search through the files and all that, but for such basic things it's worth learning it yourself, if you do it often.

learning and using and customizing emacs has never been better

getting a bibliography and citation workflow up and running in org is incredibly easy. Use a model to read the first page of your PDFs dir and add bibtex entries...

then you just build your static site around that

please don't write with a model. We want your own prose

> Part of the case for Emacs and Vim has always been that they make you faster at writing and editing code.

That was a side-effect of using software that is deeply customizable, but not the main goal. It comes from being comfortable with your tools to the point of relying on muscle memory to use them. The main benefit to me has always been comfort. My favorite commands are a keystroke away, I know how the tool will react and what it's doing at any moment, I know all of its quirks, etc.

None of that changes in the age of "AI". This new technology won't replace computing for me. My hurdle to adopting "agentic" workflows has nothing to do with my choice of tools, and everything with not trusting the companies and ecosystems around this new tech, especially during this insane hype cycle. I've been slowly adopting parts of the stack I'm comfortable with, because, again, my comfort trumps anything else.

Besides, if anything, a deeply customizable platform like Emacs is ideal for building any type of workflow. There are already great packages for LLM integration, and I don't think Emacs users are missing out on anything. The fact "AI" companies decide to build their moats with custom tooling is not a problem I care about. Apple has been pushing their idea of what computing should look like for decades, and it has never appealed to me. I don't miss something I don't want.

Anyway, confusing article. The author acknowledges all of these points, but also the alternative scenarios. Both cannot be true for the same person. There will always be people who enjoy using Emacs and Vim because of their customizability, not necessarily their features. And there will always be people who just want to use a supported and official product, without any tinkering. Emacs and Vim will outlast this hype cycle just fine.

Thanks for all your work, batsov! I do hope you stick around these communities. :)