add sat dev discussions

1 files changed, 70 insertions, 0 deletions

diff --git a/2025/talks/llm.md b/2025/talks/llm.md
index f9b5633a..402d1910 100644
--- a/2025/talks/llm.md
+++ b/2025/talks/llm.md
@@ -33,7 +33,77 @@ 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.
 
+## Discussion / notes
 
+-   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?
+    -   A: 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.
+-   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?
+    -   A: 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.
+-   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?
+    -   A: 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.
+-   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? Thx!
+    -   A: 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.
+-   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).
+    -   A: 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.
+
+-   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?
+    -   A: 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.
+-   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? 
+    -   A: 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.
+-   Q:   I'm reading angst in your thinking about AI/editing.  What are
+    you excited about?
+    -   A: 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.
+-   Q: Why does it matter to have a richer UI? All that is left is
+    basically writing and getting the results.
+    -   A: 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.
+
+
+-   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?
+    -   A: I think experience only helps here - I don't trust people
+        with no experience creating code.  It's OK for one-shot type
+        apps where you don't care about maintainability, but for
+        serious code where you need to think about a lot of different
+        types of typically software-engineering concerns such as
+        latency, maintainability, scalability, etc, experience is a huge
+        boost.  We see this in the industry right now where junior
+        engineers are less desirable than senior engineers, because
+        senior engineers can just use LLMs more effectively.  So I think
+        dipping your toes into the water is well worth it.
+    -   A:
+-   I really like that sentiment. I like the idea that maybe we could
+    have a place for code that is "good enough", and have a place for
+    code where passion for the craft shines through
+-   I think editors like Windsurf/Cursor/VS Code will stick around but
+    to Andrew's point, the editing portion of the app will shrink while
+    the agent interaction will take center stage
+-   Thanks for answering the questions in such a clearly articulated
+    manner :)
+-   Monster write up on energy usage:
+    [https://www.technologyreview.com/2025/05/20/1116327/ai-energy-usage-climate-footprint-big-tech/](https://www.technologyreview.com/2025/05/20/1116327/ai-energy-usage-climate-footprint-big-tech/) -
+    tldr; AI's energy use is small per query but exploding
+    overall---driven by opaque, power-hungry data centers.
+-   interesting talk. I'll start asking it for everything: "but is it
+    editing?"
 
 [[!inline pages="internal(2025/info/llm-after)" raw="yes"]]