Back to the talks Previous by track: Interactive Python programming in Emacs Next by track: Emacs and private AI: a great match Track: Development

Emacs, editors, and LLM driven workflows

Andrew Hyatt (he/him) - ‪@andrewhyatt.bsky.social‬, ahyatt@gmail.com

Format: 21-min talk ; Q&A: BigBlueButton conference room Etherpad: https://pad.emacsconf.org/2025-llm
Etherpad: https://pad.emacsconf.org/2025-llm
Status: TO_REVIEW_QA

Talk

Duration: 20:04 minutes

Q&A

00:00.000 Q: My biggest question with AI code editors trying to integrate with Emacs is -- are the AI code editors able to read unsaved buffers and not just saved files?
02:20.320 Q: Personally I don't agree with the comment you made about VS Code usage dying out because I see companies/products pushing for tightly-integrated VS-Code agents/products like Windsurf. Thoughts?
03:47.760 Q: Do you have any thoughts about the environmental cost of using LLMs - either the training of models we can download and use locally, or the larger, commercial models used from the cloud?
06:09.080 Q: I must say, I liked your conclusion, but I differ insofar as you said that VS Code differ from Emacs because the former is not as easy to adapt as the latter. Why should Microsoft not adapt VS Code as we adapt Emacs for the new era of coding? And why would VS Code be harder hit? Could you please elaborate on this point?
09:14.040 Q: Do you think that we are falling behind in productivity as Emacs users? Compared to all these VSCode forks that have 1000 buttons and textboxes everywhere (i.e. much richer UIs which are basically webpages).
12:17.480 Q: I've been using Claude Code extensively. I recently switched to Agent Shell with Claude Code. Have you tried it, what are your thoughts?
14:32.120 Q: In terms of agent selection, what has your experience been with different agents, and have you had any success with hosting your own models and using open weights?
17:33.440 Q: I'm reading angst in your thinking about AI/editing. What are you excited about?
19:47.920 Q: Why does it matter to have a richer UI? All that is left is basically writing and getting the results.
22:25.080 Wrapping up
23:23.880 Q: I have 45+ years editing, programming. I'm not sure I can think about things without thinking of buffers, editors etc. Is this a handicap/should we just have people with no experience with code learn to prompt?
Listen to just the audio:
Duration: 25:20 minutes

Description

This talk will outline the major ways LLMs are changing the world of editors. There are a few different ways that LLMs are being used now: smart completion, smart feedback, ad-hoc addition and transformation, and out-of-band instructions which are typically done outside of the editor. What are the current Emacs solutions for these, and what does it mean for Emacs?

  • Intro and state of the art of LLMs and their workflow modalities that are currently used
  • Smart completion: Emacs solutions and demo
  • Smart feedback: Emacs solutions and demo
  • Ad-hoc addition and transformation: Gptel, ellama, and other tools; several demos
  • Out-of-band instructions: Aider, Claude Code, and more.
  • Thoughts for what it an editor is for, for those working with LLMs
  • Possible futures, and what these mean for Emacs, for editors in general, and for free software.

About the speaker:

Andrew Hyatt is a software engineer, and Emacs package author (llm, websocket, vecdb, ekg, and more). LLMs have already transformed how many people write and edit text. This talk explores the major workflows that have developed and examines what these mean for Emacs.

Transcript

[00:00:01.040] Introduction
Hi, I'm Andrew Hyatt. I'm going to talk to you today about Emacs and AI, and where things are right now in the world of Emacs and AI, via large language models, and where things might be going, and what it means for the future of Emacs. I think what we're seeing with Emacs is interesting. We've seen a lot of different things come around in the past year, in the past several years. There's lots of different solutions. But in the past year, things have been very interesting. I think there's new and interesting questions about what does it mean to use Emacs? What does it mean to use any editor? I'm going to be talking about Emacs, and I'm going to show you various Emacs packages as demonstrations of these ideas. But there's the general question of what does it mean to use any editor, not just Emacs? What does it mean to do work? And I think the industry in general is facing these challenges of we don't really know where things are going to end up, but we do know the direction they're going. Emacs is a reflection of that. I think the answer for Emacs might be a little bit different than everything else, but I do want to show you what's out there so we can explore what are the possibilities of Emacs, AI, and generally how we get things done. Thanks. Let's dive right into it.
[00:01:44.720] Copilot
We're going to start by showing you some things that are pretty well integrated, that look a lot like what you see in Emacs and fit in with the kinds of editing that you normally do in Emacs. So this is just kind of like, it's well integrated. So we're going to talk about Copilot and Semext. Copilot is by Microsoft via GitHub, and Semext is just my personal demo, but they're both showing you, you know, this kind of thing. Let's start with Copilot. Let's try out Copilot on just a standard bit of Elisp. We're going to write a Fibonacci function. Let's try out Emacs on a standard bit of Elisp. We're going to write a Fibonacci function. And you can see like as soon as we even start typing it, we get everything as a completion. So you can just press Tab here, and you've just completed a significant bunch of Emacs Lisp code. It will do this no matter where you are. So, pretty useful. It will just keep suggesting things. Do you want to do this? I'm not sure. But it usually is offering pretty reasonable things. So you could do this with code, of course, any code. You don't really even have to have a mode for it, right? That's kind of the beauty of AI is that you don't need any Emacs functionality for this, except for Copilot. It doesn't need to know the structure of your code. It doesn't need anything except for the text itself and whatever AI integration that this is. We can look at, you can do the same thing with Org-mode. So we could say create, no, how about let's, let's do, you know, spring cleaning. It's actually the fall, but still we'll say spring cleaning. And it'll start suggesting things that, you know, maybe at first, it doesn't really know what to do to clean up all code. It thinks I need to clean up code, but no, this is going to be actual, you know, clean hood over range. Clean out pantry. These are all really reasonable suggestions. You just keep going here.
[00:04:38.320] Semext
I'm going to demonstrate Semext, which is a package I have on GNU Elpa, that is designed to integrate AI in a very Emacs-like way. And so what you could do is you could do a semext-search-forward. The UI looks just like other Emacs commands, but you can search for anything. There's really no way to express what I'm about to, what I'm trying to demonstrate in Emacs's normal search commands. You could really ask for anything. And it takes a little while, which is not Emacs-like, but everything else is sort of like it's designed to be like Emacs, except way more powerful. You don't need any mode to be active for this. You just need the library and an AI provider of some sort, either locally or, you know, your favorite cloud provider.
[00:05:41.200] Integrated AI experiences: gptel, ellama, chatgpt-shell, etc.
Now we're going to move on to a different way of interacting with AI and Emacs. This way is less like the normal editing experience. So you lose some familiarity. However, in exchange, it is a lot more powerful. And there's a whole suite of these tools. I'm going to demonstrate gptel, which is the most popular one. But there are many. And I think different people have their own preferences of what they like to use. We're going to try now something that is a step away from just editing. And we're going to, I'm actually using gptel. There are several packages that are going to be doing the same sort of thing as I'm going to show you. gptel has sort of become the most popular one. So that's why I'm showing that to you. But let's just highlight everything and say gptel rewrite. And gptel basically just has a few things. There's different ways of thinking about this. With just a few very configurable menus, you can do a large variety of things. So let's give rewrite instructions. "Turn this into an iterative program instead of a recursive program." In Elisp, you really should not be using recursion. So we could say "return to be ready". Do we accept it? Yes, we accept it. Or we could iterate and say, no, no, that's not what we meant. We meant something else. Or you did something a little something wrong. Please fix it. So this is all very powerful. Is this editing? Well, it's in the editor. You could do this while editing, while deleting, you could be doing some sort of traditional editing. And then this, which is editing in the sense that it's in your editor, you might have to highlight some parts of the file and do things, but generally you don't even need to, or you go to a spot and you say, put code at this spot. It's kind of like editing. I would say it's not exactly editing, but it's at least something that must happen in an editor and it's well integrated into Emacs. As you can tell, it used very sort of modern standard Emacs UI paradigms and it's all written in Elisp. Everything is happening in Elisp here. So this is just very much an Emacs experience. It's just not exactly editing because the thing doing the editing is the AI and not you. You're just kind of telling it what to do.
[00:08:36.040] Outside the editor
Now we're going to go and look at a way of interaction that's even more powerful and even more disconnected from the normal editing experience. In fact, it's so disconnected that most people are using this without an editor. These are things like Claude Code or the sort of open source equivalent, Aider. There's a few other things that follow this pattern as well. But it's very interesting in the sense that while you can integrate these with the editors, and I'm going to show you an Emacs integration, you don't need to. And that's not the way most people are using them. And I find it very interesting that sort of we're going back kind of full circle where, you know, in the 1960s or 70s, we were using Ed from the terminal to edit files, but then we created editors, and that was a really good idea. It is a lot easier to edit files when you have an actual UI. But now it's 2025, and we're back in the terminal, and we're editing files through the terminal, and you know what, it's great, but I think it's even better with Emacs. On the other hand, it comes with some trade-offs, as you can see, as we will see.
[00:10:04.734] Outside Experiences: claude-code.el, aidermacs, eca
Okay, we're going to look at [audio glitch] Claude Code IDE, aidermacs, ECA. Last time, I didn't show you all the variants. I do want to show you eca, which points to, it is a very similar tool in what it does, but does have a different and I think better type of Emacs integration. All right, we're going to demonstrate Claude Code IDE, which is one of three Claude Code packages. It's a bit confusing. One of them will be demoed by another presenter at the Emacs conference, so stay tuned for that. Here I'm just going to give you a little taste of what these packages look like. So if we say Claude Code IDE, it presents us with basically almost exactly what you would get when you're running this in the terminal. And essentially there's a terminal interface. You can see that there's a vterm. But here we're going to say, "In scratch.el"... let's say what we want to happen. [In scratch.el, there is a fibonacci function. Can you add all normal elisp headers and footers to this file?] So, we just say what's going to happen, and this is going to do things in the background. It's not going to do things through Emacs. That said, there is an integration with Emacs, so that it can do things like show you these nice ediffs. My screen is not really wide enough to show you a really great ediff here, but you can kind of see what it's doing, and you can see, yeah, that looks good, so you could say yes, yes, accept the changes, and if we... Just need to revert the buffer. We can quit the printout of this. We see that it just did everything I asked it to. Is everything exactly right? Probably not. It's reasonable for a start though. But you could ask it to do anything. You could say, write unit tests for this, and it will. You could say, write me a suite of functions like Fibonacci, and it'll probably do something reasonable. But you can see this is not editing. There's nothing editing-like about this. That said, there is something that is editing. You need to give it instructions. You need to tell it what to do.
[00:13:10.960] Org files
And what you could do is... You could have a project.org, and what you could do is you could have functions. The way I've done things often is .... You could say something like, unit tests for Fibonacci. How do you spell Fibonacci? I don't remember. But then you could say that this is, you could clock it, basically. org-clock. What I've done is... You could add custom commands to Claude Code, and you could just say, look, here's my Org file, read it and do the thing that I'm clocked in as. And then you can write a bunch of instructions here, like, I like to use ert for tests. Tests should, like, whatever. You should just say... everything you need to kind of specify. As you get to more complicated tasks, it's harder and harder to give it all the context it needs for a task, and Org Mode is actually a pretty good way to do this. I find that this works pretty well, and you can even have it instruct Claude to just mark things done in your Org file when they're done. And it knows how to do this, of course. So, let's just clock out. That's one way to do things.
[00:14:45.240] ECA
So one other thing I'd like to show you is eca, which, compared to Claude Code, ECA is open source. It's very nice in that respect. It doesn't have to use Anthropic's models. You can use local models, but it has the advantage of integrating very well with Emacs. I'm not going to demonstrate it, because it works essentially the same thing you could do approximately the same kinds of things you could do with Claude Code. You just write what you want to happen and it will make it happen. It again does not do this through Emacs, but what it does do is it gives you a much better Emacs interface that's not terminal-based, because you're not using it through the terminal, or not even through comint, you are using it through a backend that is exchanging structured information with this process that is doing all the work. But other than that, it's the same model as Claude Code and projects of that nature.
[00:15:52.060] Editing
We've seen in the demos that I gave that there are AI experiences that are very natural in the world of editing. because they, like Copilot, just offers completion, it fits very well with what we all do in Emacs. And it's truly, yes, it's kind of a cheat in a sense for editing experiences, because it can do so much, but it's just editing. Whereas things like gptel and those kinds of tools, they are clearly in an editor and using editor, they're using Emacs, but they represent sort of like, well, you can edit for a while, then you could use these tools to do something that is not editing, this AI just changing the buffer for you. And that's fine. It's still... It may not be editing, but it's still clearly something that is useful to do in Emacs and belongs in Emacs. But the new tools like Claude Code and things like that are kind of different. Yes, they will get better integrated with Emacs, but it's not clear that they really need to. They can do a lot of things without editing. In a sense, editing is obsolete in some sense. For as many tasks, you don't need to edit anymore. And that's a nice thing. No one really knows when all this will end, how far things will go. It could be that in a decade or so, no one's really editing for work anymore. Maybe you're just writing instructions. You could do that with anything. You don't need Emacs or any special editor. We could all be using Notepad. That would be bad. But... I think it could go that far, but it could be that, well, for many specialized things, people are still using editing for certain tasks, but most tasks are getting fed to just... AI is just doing those things. In any case, I think it's clear that editing is diminishing, the need for editing itself is diminishing. And in such a world, It's interesting to think where Emacs is headed, especially in relation to all the other editors. I think people will use Emacs less. But I think other editors, like VS Code, may simply disappear or be a relatively fringe tool. And Emacs is going to follow its own path. It's very extensible. It could do anything. If there's one thing Emacs can do, it's adapt. Emacs has been around for a long time. It's pretty clear that Emacs will be around for a long time. It might be that in the future, editing is some sort of like an artisanal activity that we do. It's kind of weird to think about it. It's not like baking bread. But it is the sense that AI might be churning out code in the way, you know, the factories are turning out bread, but if you really want the good stuff, you'll have to do it yourself. I don't know if it'll be exactly like that, but it could be that Emacs survives and thrives in a very kind of specialized ecosystem of people who contribute and use it in the way it has survived and thrive right now. And I think that's a really nice way for all this to end up. There's the whole sense of how society will end up if all this happens. I don't know, but Emacs will be there for us when whatever happens. So thank you, and let's help make Emacs the best it can be to survive and thrive in the next decade.

Captioner: amitav

Q&A transcript (unedited)

[00:00:00.000] Q: My biggest question with AI code editors trying to integrate with Emacs is -- are the AI code editors able to read unsaved buffers and not just saved files?
So let's, I'm just going to answer the questions as I see them on the pad. So yeah, this first question is really good. And I think it's actually this great thing that I did not mention is that like, if you have unsaved buffers, which is, you know, when you're actually doing editing, most buffers are unsaved. really you need something tightly integrated with Emacs to deal with that. So things like, you know, I demonstrated Copilot, I demonstrated Gptel, things like those things, things like Ellama, these things will all work with unsaved buffers because they work via, you know, the input is the buffer. as opposed to a file. Things like Claude Code, Gemini Code, et cetera, those are working with files. They have no idea what is going on with your buffers. And it could be that you can solve this problem by using this thing called MCP, which kind of gives the coding agent a way to see anything in particular. In this case, it would be Emacs and the state of your buffers. But I think that's not a particularly great solution if that's how you want to work. But I think that's kind of like if you're in the Claude Code that kind of world where you know things are happening, basically through a terminal. It's okay, like you typically would not be doing a mix of things. You would just be doing things either in one place or the other place. You know, it could be that you switch off from one place to another, but you wouldn't be doing both at the same time. And it's kind of a, you tend to just fall into one, you know, editing outside the editor or editing inside the editor. And I find myself switching between the two when I use those kinds of tools. So David, let me interrupt you for just one moment. I want to just take care to read out the question that we're answering. The question was, my biggest question with AI code editors trying to integrate with Emacs is, are the AI code editors able to read unsaved buffers and not just saved files? Sorry. Yes. Yeah. Thank you for reminding me to. I will read the questions from now on. But yes, that's what I think about. that interesting questions about unsaved buffers.
[00:02:20.320] Q: Personally I don't agree with the comment you made about VS Code usage dying out because I see companies/products pushing for tightly-integrated VS-Code agents/products like Windsurf. Thoughts?
The next question is, I don't agree with the comment you made about VS Code usage dying out because I see companies and products pushing for tightly integrated agent and products like Windsurf. So thoughts on that? Yeah, I mean, it's really hard to be certain of anything, like things are changing very fast and it's very hard to predict the future. But the trend I see is that um, the sort of outside editing experience where you just kind of instruct a model, what to do is getting better. And as long as that keeps getting better, I think that's going to lessen the demand for these tightly integrated editing experiences. So it could be that, um, a lot of people, especially in, you know, corporate environments just start using, they're going to use whatever is going to make the most productive. And I think right now, it's not clear that that will be, you know, the very agent-based, you know, command line-centric way of doing things. But it certainly, the trend is, if that continues, I think it probably will be like that. So I think we'll have to see. I don't think your opinion is unreasonable. I guess I'm kind of cautiously saying I think it's gonna be the opposite, but I guess we'll see. Like, let's reconvene in a year and see what happens.
[00:03:47.760] Q: Do you have any thoughts about the environmental cost of using LLMs - either the training of models we can download and use locally, or the larger, commercial models used from the cloud?
Uh, the 3rd question answer, do you have any thoughts about the environmental costs of using either the training of the models are we can download or use locally or the larger commercial models used from the cloud. Um, I think. The, you know, I'm on social media, probably a little bit more than I should be. And I do see a lot of discussion there and a lot of concern about the environmental costs of using LLMs. I've looked into this as I'm also concerned about keeping my environmental footprint personally down. And I do this in many ways, but I certainly don't want to kind of like blow that all the water because I'm using LLMs so much. I think that the concerns are mostly overblown. There's a concern that, well, it uses a lot of energy. In aggregate, the total amount of energy used by the data centers in the US is a few percent. And this is a fraction. I think this is like LM's account for something like 20% now of all data center usage, which is a lot. But Those data centers are doing lots of things. They all need to be water cooled. Um, if you like per LLM prompt, the costs are relatively small and by relatively small, I mean, you know, people have said online, well, it's like a few bottles of water per prompt. That, that is not true. It is much, much less than that. It's a fraction of that. So, uh, I don't think the answer is nothing, but I would say it's, I would say you probably, if you want the most bang for your environmental buck, probably the best thing for you to do is take less flights and things like that. Like, yes, you can cut down on this, but I think it's pretty marginal at the moment. We do probably need to think about the total costs like of humanity using all of this. Like a lot of stuff you'll see corporations are using a lot of these things. And so like, just like if you look at water usage or energy uses in total, it's like really corporations that are using this. So there might, there's a lot of leverage there to make things more efficient as opposed to personal use. So I think it's wise to be cautious, but I think it's okay, I think, at least for personal use.
[00:06:09.080] Q: I must say, I liked your conclusion, but I differ insofar as you said that VS Code differ from Emacs because the former is not as easy to adapt as the latter. Why should Microsoft not adapt VS Code as we adapt Emacs for the new era of coding? And why would VS Code be harder hit? Could you please elaborate on this point?
The next question is another, yeah, this is also disagreeing with me about VS Code, but it says, I must say I liked your conclusion, but I differ insofar as you said that VS Code differs from Emacs because the former is not as easy to adapt as the latter. But why should Microsoft not adapt VS Code as we adapt Emacs for the new era of coding? And why would VS Code be harder hit? Could you please elaborate on this point? Yeah, thanks. This is a good question. I think maybe I wasn't as sharp on my point as I could be. Because I think the core of what I'm saying is like, there is a going to be a trend. I believe there will be a trend away from editing. And if we are going to be editing less, I think VS Code, like people will be in editors less. And that means people will be in VS Code less, people will probably be in Emacs less. And yes, I think you can, VS Code is to some degree extensible. but I think there's less of a community, or that is, I think the people using Emacs have used Emacs for a long time. They're going to continue to use Emacs. I speak for myself, but I know a lot of people here are kind of like this, and they're going to just, like, we have a lot of momentum to keep doing things in Emacs, and especially because we have a lot of things that we already do in Emacs. We do to-do lists and, you know, with org mode and some people read email and some people are using shells in Emacs and all these things, I think will make Emacs kind of a better environment if you want to do various editing like things in Emacs. In, you know, in an editing environment, because I think just emails can edit more types of things I think will naturally be a bit more useful than VS code, which people are really just using to edit code and if people find it less useful to edit code. I think it's VS Code will be harder hit than emails because that's its whole, like, that's in the name, like the whole reason for it to be doing things as to edit code. So I think that it's it's vulnerable in a way that Emacs isn't just because Emacs is so very... you know, it's, it could do so many things and and people use it for so many different kinds of things that it's I think it's going to be a little bit more resilient. But as I said with the present. For those of us that are using Emacs, it's everywhere for us. Not necessarily everyone is an I live in Emacs person, but whatever you're using Emacs for, it is the thing you reach for to do that thing. Is that touching on the point? Yeah, that's a great way to say it. Thank you. Thank you, Corwin. Yeah. Thank you. Thank you for that question.
[00:09:14.040] Q: Do you think that we are falling behind in productivity as Emacs users? Compared to all these VSCode forks that have 1000 buttons and textboxes everywhere (i.e. much richer UIs which are basically webpages).
Do you think we're falling behind in productivity as Emacs users compared to all these VS code forks that have a thousand button and text boxes everywhere, which are basically much richer UIs, which are basically web pages? I do think Emacs is falling behind in some ways. I mean, it's definitely showing its age a little bit, especially you mentioned richer UIs that are basically web pages. I mean, this I think is one of the big problems Emacs has is that it uses a very, you know, a much more ancient way of kind of doing UIs that is not particularly flexible and not particularly comfortable for any modern UI coder. And I think if you look at the Emacs stuff out there, like, yes, you can do a few things with UIs. You can have some amount of UI richness, but it's pretty limited. And I kind of, if there's one thing I could wish for in Emacs, it's sort of like, I kind of wish Emacs could be on a, could be built on top of basically like Atom or something like that, where it's like a web framework that allows us to write actual rich pages, rich UIs in a modern style using things like CSS instead of the kinds of things Emacs lets you do. But that said, that is an advantage of VS Code and other editors like that. I think that Emacs does a good job of eventually catching up to all sorts of things people are doing in other editors. It's often that other editors get there first, but there's a lot of momentum to kind of keep Emacs fresh, keep it modern. And it's pretty easy to- I love that. I forgot about the lag. We do have a little bit of lag, but I just, I find that very captivating. We have with technologies like Apache Cassandra in the database world, we have this idea of eventual concurrency. And you make me think with Emacs, we have this idea of eventual feature parity, right? If a feature stays desirable long enough, Emacs will eventually grow it. I think that's a very contagious idea. Yeah, yeah, thanks. I hope that idea makes sense. And I hope it's correct, because I think that I do want Emacs to continue to succeed. And I personally, using Emacs, do not feel myself falling behind in productivity. That said, there's a lot of ways that Emacs can improve and should improve on this front. And a lot of these ways are pretty fundamental. So I kind of hope people pay a lot of attention to some of these more fundamental lower-level Emacs things that really allows the packages to do more richer and better things. Sorry, you have a ton of questions. I shouldn't be doing so much active listening. No, no, I appreciate your input.
[00:12:17.480] Q: I've been using Claude Code extensively. I recently switched to Agent Shell with Claude Code. Have you tried it, what are your thoughts?
OK, next is I've been using Claude Code extensively. I recently switched to Agent Shell with Claude Code. Have you tried it? And what are your thoughts? I actually have tried Agent Shell. And currently, I recorded this video like three months ago. So Agent Shell did not exist then. If Agent Shell did exist, I probably would have demoed it as well. Agent shell is great in the sense of it's... It does use comint, which is the way that I think all Emacs users would prefer to interact with something like Claude Code, or any of those types of tools, which is like, I don't. Um, the other, but it's a trade-off it uses like on the back and it's, it has a common buffer. And then on the back end, it's using a protocol to talk to agent, uh, to Claude Code and other things. The problem is this has a lot of problems. For example, like you don't have completion of slash commands. You don't have, um, if you ask to see the, in Claude Code, you can get a visual representation of. the context window. But you can't do this. I mean, last time I tried, I couldn't do this in agent shell. It's progressing rapidly. But it's not as rich in functionality as using Claude Code directly. On the other hand, because it's letting Emacs be Emacs and using comint, it's a much better experience to actually give instructions. I think the maximum power, though, is, to me, the best way is still like, you know, do your editing in org mode, and then just tell, you could have, you know, the richer experience of using of using Claude Code in, in it's more like shell like form where everything is, it's much, you know, designed to be used in the terminal, but you don't have to type in that much because you're really doing your typing in order to me, I think there's kind of the sweet spot that I like. Um, but agent-shell is a great step forward and I think it's, uh, it's quite good to use. And I, I personally use it a lot.
[00:14:32.120] Q: In terms of agent selection, what has your experience been with different agents, and have you had any success with hosting your own models and using open weights?
Um, OK, so in terms of, next question, in terms of agent selection, what has been your experience with different agents? And have you had any success with hosting your own models and using open weights? I think there's, you know, many people have many different opinions on this. I think Claude Code is, most people I know would say Claude Code is probably, sorry, Claude is probably the best for coding right now. Gemini can be very hit and miss even with 3.0, but Claude is quite good. 4.5 Opus is actually relatively cheap compared to the previous version of 4.1 Opus. There's other models out there, but I think most people just stick with Claude because it's very reliable, it's very good, and nothing is obviously better than that. And as far as DeepSeek is pretty good as well, and then much cheaper. I've had some good luck using that locally, but actually the problem is for my day-to-day machine, like my personal machine, it's not powerful enough to run anything locally. And my work machine, it is powerful enough, but I can spend my company's money at will on more powerful models. So there's really not a lot of incentive for me to run locally. I think, as far as I know, I haven't heard of local models being incredible, but I think you can get reasonable quality with them. That is, especially if you're doing relatively simple things, I think it's pretty reasonable to be using those. Also, they tend to be slower than the models that are elsewhere just because they just have more horsepower, they can churn through those tokens a little quicker. we've got about 7 minutes left before we're cutting over this great discussion so far. I'm very happy to keep going. There's no time limit, but at a certain point, I may have to leave to jump in and prep with the next speaker, but you'll be able to keep going as long as you have the steam for it. I think we have 3 questions. Let's see if we can get through them all in that time period. OK, this one is interesting talk. I'll start by asking it for everything, but is it editing? I think there's more of a comment than a question. So yes, let us all ask, but is it editing? All right. I can move on to the comment area.
[00:17:33.440] Q: I'm reading angst in your thinking about AI/editing. What are you excited about?
I'm reading angst in your thinking about AI editing. I think that's true. It says, and the question continues with, what are you excited about? Wow, that's an interesting question. I mean, I think there are possibilities. Like, yes, people are going in sort of a relatively obvious direction with LLMs right now. And I think there's lots of opportunities, clever opportunities to do things we couldn't have thought of... Things that are useful, but in ways that are not super obvious to us, and I think I'm still excited about the possibilities of using them in ways that are super helpful and different than normal. I'll give you an example. This is something that I intend to, I think, post on Reddit in a few days, but I have a extension to eshell where you can prefix a command with at, and then just tell it what you want to do, and it will substitute the command that you are thinking of. Because often, I do not remember. I never remember, like, how do you find a file in a directory tree, you know, recursing? Who can remember how to do that? It's like a find, and there's like a dash print there somewhere. Yes. There are some smart people who remember this but I am not one of them. And so I think, like, something like this is like, you just type out, find me this file, and it will substitute the correct command. I think this is, there's a lot of little, little tweaks you could do like, you know, if you want the AI, it could be there for you, and it will help you. And if you don't want it, it's not going to get in your way. And I think this is where Emacs can really shine. It can really take advantage of LLMs, but still remain true to its kind of editing experience, because it's not forcing you to use LLMs all the time. So thank you for that great question. And then the final question. Yep.
[00:19:47.920] Q: Why does it matter to have a richer UI? All that is left is basically writing and getting the results.
This final question is, why does it matter to have a richer UI? All this left is basically running and getting the results. I think maybe this is a response to me complaining about Emacs not having a richer UI before, but I think it does matter a lot for all sorts of things. It's hard to kind of explain succinctly, because I'm talking about UI and I'd have to show you things. But it should be just something like, oh I have an error, and I'm using flymake and I'm, I'm using the... I have options where it'll show me the error in line by underlining things and having a little message, but like, you know what, that message doesn't appear quite right a lot of the times. Or here's another one like. I program in Python a lot. And Python, it's super hard to program in unless you have these little vertical lines that shows you what the indents are. At least I find it. There are two packages that do that. None of them do it particularly well, just because Emacs at its base does not allow you to do this. And so you kind of have to hack it in. And there's lots of ways to mess it up. And when editing, you'll find yourself messing this thing up regularly. So it doesn't look quite clean. And like, there's little artifacts, or, you know, there's little ways that it, it kind of gets things wrong, or you can get things wrong with it. So I think that, like, there's a lot of issues with that sort of thing. And also, like, you know, what if you want to do something like play a video inline, like, I don't know, you might should be able to do that, you might should be able to do anything. But right now, it just can't. I think a lot of the reason as well... you know, we wanted to be compatible with TRS 80 machines or something like that. This is important, this really is important, but I hope there's some way that we can kind of eventually figure out how to get the best of both compatibility and more modern UIs. So, you know, we can have more modern UIs for people that have modern machines and other people either do without that functionality or sort of fall back to some reasonable default. So we have about 30 seconds or a minute. I know there's one more question. I'd love for you to get to it. I just want to make sure that while we're still live on stream, you get a chance to share any closing remarks you might have. Thank you for that. Um, yes. So first of all, I want to thank everyone involved for listening. And I want to thank the core when I think thanks for moderating this. And Sacha, thank you for putting that together. And I know there's more people that are working behind the scenes. So thank you all for putting this together.
[00:22:25.080] Wrapping up
I'm so happy that we all are here. We care about Emacs. We're pushing Emacs forward. We are I think Emacs remains this really remarkable achievement. Like it's amazing that it exists. It continues to exist. It hasn't got... It's hard. It's like, really, there's a lot of work to go into it. So I think let's all just appreciate everyone who contributes and makes all of this possible. Cause it's, if you ever read the emacs-devel mailing list, it's a lot of work, a lot of deep thinking, a lot of careful thinking. And I think this is really important. So thank you, especially to the maintainers of Emacs and everyone who's contributing to the core experience, all the libraries, all the LLM stuff we mentioned before. You're all doing such a fantastic job. It's exciting to be here. It's been just fascinating. If you don't mind, I'd love to jump right over to the last question. OK, let's do that.
[00:23:23.880] Q: I have 45+ years editing, programming. I'm not sure I can think about things without thinking of buffers, editors etc. Is this a handicap/should we just have people with no experience with code learn to prompt?
It says, I have 45 plus years editing programming. I'm not sure I can think about things without thinking of buffers, editors, et cetera. Is this the handicap? Should we have people with no experience with code learning to prompt? I feel like I do not want to see people that have no experience with code learning to prompt. I think it's very limited what you could do right now with that. Like you could do, if you could sort of one-shot it, that is like, I have something that's relatively easy, And it could do it, and I'm going to tell it to do it, and then I'm going to give feedback. OK, as long as this is for relatively short-lived things, I think that works well. But for people who really care about the longevity of their code, really care about software engineering, which is software engineering is very different than just writing code. Software engineering is about maintainability. Software engineering is making sure everything is scalable and all sorts of things that it's unlikely, I think, that an LLM is going to get right. And I've seen a lot of bad cases where people who don't understand code are doing things and it's not working well, because they don't understand some of the complexities or some of the concerns that that you might have in maintaining a piece of code. So I think those people who have lots of experience are the best people to use this. And I think that's what we're seeing in the industry as well, where more senior people are doing quite well because they're able to use LLMs more effectively than junior people. That may all even out because LLMs get even better, but for now hasn't happened. So I think, you know, I also have a ton of experience, not 45 years, but a lot. And, and I think that it's those, those years of experience will only help you. And I think it's great to dip your toes in the water and see what you can do.

Questions or comments? Please e-mail ahyatt@gmail.com

Back to the talks Previous by track: Interactive Python programming in Emacs Next by track: Emacs and private AI: a great match Track: Development