I'm happy with how the integration is shaping up, enabling me to have my cake and eat it too (Emacs + AI agents).
I wrote an agent-shell post recently with the latest changes https://xenodium.com/agent-shell-0-47-1-updates
Also, you'll need to enable resuming as per post (it's a new feature) https://xenodium.com/agent-shell-0-47-1-updates
I use VIM and I get some inspiration from LLMs sometimes, but me and other developers always after some time give up and just quickly do it manually.
AI Agents will just full the code with maaaassive swaths of texts it will just make a project unusable.
We even get paid to turn client's AI LLM Claude sketches into real programs.
If it's not something very common LLMs could end up generating random code.
Also if you work on something performance critical, you can get inspiration from LLMs, but they often don't write fast code.
But do you never need a specific change (e.g. bugfix), that even describing in English is slower than just doing it? Especially in vim where editor movements are fast.
P.S. Software developers aren't being paid to be "fast". In fact, being "fast" is called "technical debt" and you're usually punished for it as a software developer.
If you prompt and hand-hold the LLM it is a big help. Things like boilerplate, basic crud etc etc is something I dont have to worry about anymore. And if I am looking at an unknown codebase or area, the llm can explain things to me, it's the rubber duck that talks back.
I'm not using vim plugins (yet) for LLM, tmux and a couple of panes etc is all I need at the moment.
I have used Emacs for over 40 years but I found myself getting sucked into the black hole of VSCode as discussed in the article. When I bought a new MacBook a few months ago, I only installed Emacs, no VSCode, and so far that is working out for me.
Also, after many hours of experimenting with AI packages for Emacs, I have reverted to keeping Emacs mostly a pure human activity, and several times a week have sessions with gemini-cli and Claude Code when I want an AI coding assistant. This is just for me, not general advice, but I like to separate use of AI from my regular coding and writing workflows. I use AI for coding cumulatively about three or four hours a week.
So what the MCP does it just evals Elisp in my active Emacs session via emacsclient.
Now, I can tell LLM to change practically any behavior of my editor, and because it's in the REPL-driven loop, it opens up some mind-blowing opportunities. The other day I developed a tiny package on the go, while at some point I asked Claude to run the profiler, find the bottlenecks and fix them - the whole thing was a jaw-dropping complete and utter bananas.
They say: "Well Cursor can understand your code contextually"... Dude! My LLM-infused editor understands not only some arbitrary code, it can touch and improve it's own code at the point where it's touching your arbitrary code. On the fucking go!
Using Emacs was fun before. Now it's gotten crazy awesome.
Currently trying out various Emacs packages. I got 'claude-code.el' actually working. But there is some flickering and also the interface is a bit wonky.
I will try other packages mentioned in the article.
For the life of me, I can't _edit_ with VSCode. My Emacs/Doom/Evil muscle memory is too ingrained.
Escaping the god awful AI implementations in both vscode and jetbrains product is also a refresher. They don't know what the ** is going on, they don't know what users want, but I do and AI being able to extend my IDE in a way that helps me be more productive is very undervalued.
I'd assume that a good portion of people working on things like that know what is going on. My (very very subjective) feeling is that they just spit out WAY more tokens than needed, so that it hits the limit as fast as possible and people buy more. And the people responsible for that are probably the evil evil PM's
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.
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!
( See "meta tooling" in https://poyo.co/note/20260202T150723/ )
I think most engineers are reading code than writing it. I find it very hard to not use Emacs when reading large codebases. Interestingly, its mostly because of file navigation. I love using ido/ivy for file navigation, quickly filtering through buffers, magit.
Emacs in terminal is not an ideal experience though. So I can imagine it being multi-fold worse with phone keyboard.
This has been the norm for a few decades. Even software engineering courses emphasize the fact that code is read far more often than it is changed, which leads to all the basic software engineering principles around the importance of making code easier to read and to navigate through.
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.
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
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.
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.
That's a funny thing to think about.
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.
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.
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.
LLMs are like living with a depressed person who doesn't see the point in doing anything because it's all just been done before. Who cares if you do a good job? Just recycle some shit that others have done and it'll be passable. This isn't a bicycle for the mind, it's just going to drag you into depression with it.
Every VS Code update these days feels like it's exclusively AI orientated. The Vim approach seems fundamentally opposed to an AI-driven development model, or at least says, like everything else, "sure, you can do that, but set it up yourself."
I find the Vim philosophy appealing coming from a work environment that wants to replace me with API calls to American companies.
I recently said to a co-worker:
"Linux is free if your time has no value" is no longer true in the era of LLMs. Just about any wonky Linux issue can be fixed quickly with even just OpenCode and free models.
Commercial programming will be fully automated. That will not stop people doing it by hand. For all intents and purposes clothing manufacturing is fully automated but some people still do it themselves.
One example near to my heart is my mother. She collects her dog's shed winter coat in the spring, cards it, spins it and ultimately knits it into a coat she puts back on the dog the next autumn - all by hand. She could just buy a cheap dog coat from Amazon, but she thinks it's funny to see the dog wearing a coat made of its own fur so she bought the equipment and learned the functionally useless skills required to do it.
No matter what level of automation is available, a small number of people will still do things the hard way as a hobby or out of perverseness. We might be living in the matrix in 100 years but I'm certain someone will still be trying to work out how to exit vim in their holopod
The dog would disagree! :-)
I admire your mother. She is a real hacker.
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. :)
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...
For me essays are something very personal, so it'd hard for the AI agent to read my mind about my thoughts on a subject.
I've been a devout emacs amateur for 10 years, and recently learned nvim/lazy.vim because I was tired of web dev kinda sucking in emacs. Sure, you can get a setup with lint-on-save, inline TS errors, and all the other bells and whistles you get in vscode working on a react-tsx project, but then when you `helm-projectile-switch-project` to a vue project, suddenly you have to get a whole new config set up. And oops, for whatever reason, tab spacing isn't being pulled from the editor config for this directory...
But like the author says, LLMs fixed that. I pointed Warp at my emacs config, said my problems, and said "fix plz," and it did. No more "oops," just "fix plz" whenever I'm editing rust, or svelte, or golang, or whatever else for the first time in emacs.
I'm very excited for the possibility in the portion I quoted. I moved away from mu4e and org mode because managing it all was getting tedious: too much time procrastinating by tweaking org configs. Too many emails not rendered properly in mu4e or fat fingered by me and lost. But in world+llm, that's not really a problem anymore. I haven't migrated back to org mode yet but I did an experiment recently asking claude to set up org similar to my trilium set up, and it did a passable enough job that I was convinced it's possible.
So, now I'm back in emacs, trying out the various LLM tools, doing poorly at getting anything other than copilot to work well, and waiting with patience and desperation for someone to make an LLM completion experience in emacs that has a multiline completion experience at least 50% as good as Cursor's.
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?
AI is okay at doing simple things, but it needs to be overseen. Even before any viable AI, I used to read code more than to write. And Emacs is a good tool for that.
Then, Emacs specifically has a killer app, Org mode. For me, it's about as important as good programming modes, if not more
More importantly, Emacs is a platform (as is Neovim, and VS Code). It adjusts to the needs of the user and the moment.
That said, I've been using Vim as my editor for the last ten years. The last few companies I worked for had integrations with VSCode, so I use it sometimes so that I could show those off, but nothing about it makes me want to give up my awesome Vim setup with my weird color scheme (Dalek).
It took me a few months to go fast with Vim, but once I did, nothing compares. (Yes, I have tried the Vim plugin for VSCode, though it's been a few years.)
RIP Bram; thanks for giving the world this wonderful and timeless piece of software!
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.
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.
So you are vibe coding? Some of us still check every line of code generated and an IDE definitely helps with that. Even more so when you need to take control.
I purposely try to keep my extension count as low as possible. It's just too distracting for me personally.
If I really want to use AI tools or something else, then I don't mind opening a full suite, but as of right now, I still spend most of my time in vim and use AI mainly in chat mode.
For instance I would love for it to seamlessly melt into a "highlight comments/pseudo code" -> some keybind, then AI would expand those to actual code for instance, or I don't know.. but something not like what we have currently
For strategic use on any larger codebase though, it's more productive to use something like plan mode in Claude code.
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.
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
IF this is the case. But is it?
I have some doubts because to me it seems as if domain knowledge is shifted onto an AI. Then you become dependent on the AI. Is AI really better than a skilled human though? After all, if AI is doing the work and the human providing the input to it as guide, it should be possible to cut away the human completely. So Skynet 3.0 does not need humans. But when it does, then something doesn't work in that explanation - AI must thus not be "smart enough".
I would have framed this as a disadvantage ;p
Using free software and not giving away ones own abilities to create is as important now as it's ever been.
Between Emacs, the improved XEmacs, and vi, the answer was obvious at the time, I joined the Emacs faction with XEmacs.
Mastered elisp good enough, had my configuration scripts, go to know enough vi to handle telneting (or sshing) into random UNIX servers without anything else installed.
Both are still kind of stuck in time, going back to them in random UNIX distribution feels like I am back in that UNIX decade.
Initially I went with Cursor, but the terminal setup feels way faster, more natural.
I run my own models, you can have models for code suggestion/FIM in the middle and you can have another for chat mode. You can point it to your local model if that's your thing or to a cloud model.
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.
Oh boy, am I instantly turned off
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.
A.i: this is vi text editor.
Human: exit from it and open word processor.
A.i: rm -rf /
Human: good job exiting. Now where's my word processor? ....
Hello? Where's my word processor? Brint it on screen.
Can you hear me ?
