Hacker News

> LLMs have inspired a similar change in me

FWIW, the age of LLMs made me build a deeper, more intimate relationship with Emacs, because it's a Lisp REPL loop with a built-in editor, not the other way around. When you give an LLM a closed loop system where it can evaluate code in a live REPL and observe the results, it stops guessing and starts reasoning empirically.

LLM that I run inside Emacs can fully control the active Emacs instance. I can make it change virtually any aspect of it. To load-test things, I even made it play Tetris in Emacs. And not just simply run it, but to actually play it without losing. It was insane.

Also, Emacs is all about plain text - you can easily extract text from anything - from the browser, terminal, CLI apps, Slack, Jira, etc., and you can do that on your own terms - context can appear in a buffer, in your clipboard, become a file or series of API requests. That is really hard to beat.

I wonder what friction/maintenance he found with Tridactyl

For me the friction always comes when I try to use the internet without it

I am running Ubuntu as my desktop operating system. I would never do this without an LLM to do the work of keeping it functional for me. Today, Rise of Nations wouldn't launch. Never had that problem before. Seems the driver for 32-bit games and my Nvidia GPU weren't getting along after an update. Codex was called in and solved the problem for me in about 5 minutes. I just copied and pasted the Steam log and let it tell me what to do. Tadah.

I'm actually excited about the potential for a future where local agents help improve the operating system experience as I go by making changes based on my use case. All local, of course. I do not want to trust a cloud provider with my use cases/behavior on my computer so they can sell me more ads...

LLM discourse inspires me to do a cleaning of my browser tabs every hour.

Does anyone else not understand what people mean when they refer to the "friction" supposedly inherent to these power user tools? Almost none of the configs/scripts/etc I use for my heavily-customized and terminal-heavy setup get changed for years at a time.

> I don’t see a particularly clear winner between them

Because deep down they are incomparable categorically. Separate the tools from the foundational ideas and you see the very different value. Vim-model of text navigation is fantastic, practical, brilliant idea. Once you grok it - you can take it anywhere. You can use it in your editor, browser, terminal, WM. Emacs is rooted in another, even more brilliant idea of practical notation for lambda calculus. These ideas have no overlap. But understanding the philosophy of each (ideally both) could open so many different possibilities.

My vim muscle memory has paid off more for me than my emacs muscle memory. Emacs was the better editor, though. Anything that doesn't have Vimscript is an automatic winner IMO.

You may get good bang for your buck out of neovim. With only a very minimal set of plugins, it has replaced all other IDEs for me. (They're also making good progress Sherlocking their core plugins, so the future is bright for those of us who dislike plugins for core functionality.)

can you elaborate? Heavy vim user here, have considered using emacs in vim mode to quell a decades long nagging curiosity. Just need a compelling nudge.

When I still used Git, I used to have a minimized `magit-init.el` that essentially did:

    (setq user-emacs-directory (format "~/.emacs.d/magit/%s/" emacs-version))
    (setq custom-file (concat user-emacs-directory "custom.el"))
    (setq make-backup-files nil)
    (setq auto-save-default nil)
    (setq create-lockfiles nil)
    (setq inhibit-startup-screen t)
    (setq initial-scratch-message nil)

    (require 'magit)
    (defun setup-standalone-magit ()
      (magit-project-status)
      (delete-other-windows))
    (add-hook 'after-init-hook 'setup-standalone-magit)

    #!/bin/sh
    if [ "$(git rev-parse --is-inside-work-tree)" = "true" ]; then
        exec emacs -nw -q --no-splash -l "/path/to/magit-init.el"
    fi

Lazygit is the closest thing I've seen; it's what I use on remote hosts when TRAMP-ing into Magit would be too painful.

If you are on Linux/Gnome, try out Stage:

https://flathub.org/en/apps/io.github.aganzha.Stage

I was a loyal magit user for a decade. Now I use jujutsu from the command line. It's actually really nice.

>i split my time between IntelliJ and vscode

The IntelliJ git client is my favorite by far, I am curious what do you not like about it?

https://github.com/altsem/gitu

I tried Elfeed2 immediately after the announcement, well, it's nowhere near the experience of elfeed in Emacs. Elfeed2 doesn't load content for most of my feeds, elfeed does. I also integrated elfeed-tube, which shows previews of videos and their transcripts, making it no-brainer to get a summary without watching the whole video.

Yeah, I'm not gonna use anything vibe-coded, all those apps are total trash.

There's a nice built-in tutorial for actually editing text with it. Press control-h then t to launch it. But that's just for using the editor. For actually configuring it, I've found that Opus 4.6 (inside Droid) is exceptionally good at tweaking my init.el.

Yesterday I typed "Set the default YAML indentation to 2 spaces." It came up with

  (use-package yaml-mode
    :defer t
    :config
    (setq yaml-indent-offset 2))
  
  (add-hook 'yaml-ts-mode-hook
            (lambda ()
              (require 'yaml-mode)
              (setq-local indent-line-function #'yaml-indent-line)))

Don't try to "learn Emacs". Grok the foundational layer - Lisp. Emacs is not an editor - it's first and foremost Lisp interpreter with a built-in editor. You need to get two things: REPL (evaluating Lisp expressions in-place) and structural editing (moving, expanding, transposing expressions).

You can start with vanilla Emacs with zero config and Claude/Copilot/Codex/etc, running separately. Your first goal is to have the LLM running inside Emacs - ask the LLM how. It probably will recommend gptel - as one of the most popular and robust choices, go with it.

Once you get LLM tools to modify Emacs state from within, you can just go crazy. You can tell it to change colors, fonts, ask any stupid questions, whatever. It will do it without losing a beat - no restarts, no waiting, no copy pasting - just flow.

My advice is to use a base, vanilla Emacs for a little while to learn where its boundaries go, before installing a bunch of modes. That makes it easier to troubleshoot problems later.

My experience with wxWidgets based apps is that they tend to not handle DPI scaling well. Audacity is a good example, IIRC that's one of the reasons they're moving to Qt.

> llm allows for easier fragmentation..

I also suspect it allows easier consolidation. Moving from a deprecated lib to a new (and better) one for example.

Implementations will likely homogenize a bit as well, but on the other hand boy am I glad not to see an increasing amount of bizarre naïve hand-rolled implementations for some things.

Dang, your emacs config is older than me.

Lugaru (??) emacs (epsilon) on CP/M in the early 1980’s

Why? What makes Spacemacs so different/special that it requires some kind of distinct opinion that would be extremely valuable? Spacemacs is the same old Emacs with some out-of-the box customizations atop - there's nothing fundamentally different about it.

What is the future of software engineering in the age of LLMs?

Also from that post:

> Models you can run yourself are toys.

Now I may be old, but whenever we put a lot of faith in unaccountable megacorps it sure seems to have backfired a lot (remember when Amazon removed 1984 from people's libraries?). As long as a model running locally on a regular laptop bought from the supermarket isn't good enough I'm gonna remain sceptical about current AI.

There's also ethical and environmental considerations, but let's see if we can walk before we try to run.

It's not AI psychosis, you're interpreting what he said to the extreme.

Anyone who has actual corporate team lead or management experience understand AI as effectively a junior dev who doesn't have great persistent memory. These devs using AI are reviewing, guiding, and validating the work given to them by AI just as they would from a junior dev.

The inverse of your statement is more apt; it's distressing to see people so angsty about AI usage. There are going to be skilless vibecoders and then there are going to be experienced devs (like OP) who figured out their AI workflow to multiply their productivity 2-5x.

What the future holds for AI model pricing-- that is a valid concern. But I don't think that's what you intended.

I no longer write code myself

this is just like being promoted from developer to manager. some people like it some don't. with AI there is another dimenstion: some people like managing machines instead of people, some don't.

it's not for me. i don't want to stop writing code. i don't mind to manage people but i don't want to manage machines (at least not with an unprecise interface/outcome as AI provides). consequently AI may be fine for this person, but it is not for me.

> It's deeply distressing to watch people fall into AI psychosis.

It's unclear what you're saying here... Yes, AI-induced psychosis is a real problem and the frontier labs' mitigations are ineffective, to put it mildly. But using AI as a coding tool doesn't have anything to do with psychosis.

AI psychosis is to have a toxic relationship with a chatbot as if though it was a real person. It has nothing to do with engineering. You're muddying your own point by conflating all LLM use with some kind of delusion. There is a lot of nuance in this space and you're not doing yourself any favors by ignoring it if you're an engineer. There is no bubble pop, other than a straight up apocalypse, that is going to put this genie back in the bottle. Models are trained. Tools are built. There isn't a single industry that cares about artistry more than efficiency. It's here to stay, it's getting better, and if you don't know how to use it, you're going to have trouble finding work.

> Being smart, accomplished, or experienced is no defence.

Perhaps you're confusing "not using AI" with "not being dependent on AI", those are very different things.

The edge isn't from avoidance, it's from using AI as leverage on top of real skill. A strong developer + AI beats a strong developer alone, and massively beats a weak developer + AI. The edge doesn't come from avoiding a tool - it comes from being the kind of person who doesn't need it but uses it anyway. That's leverage. Refusing to use it is just leaving leverage on the table to make a philosophical point.

> After the bubble pops

People like Chris (who is enormously capable engineer) would just move onto different tools, different techniques and paradigms. That is the essence of being a software developer - many of us choose this path specifically because it forces you to learn something new, every single day. That is (I suspect) also another reason why Wellons decided to migrate away from Emacs - he just learned it so deeply, perhaps it's no longer giving him the satisfaction of learning. Which to be honest is hard to believe - Emacs is a boundless playground, there's always something new to learn there.

I just wonder how jobs like that won't replace their employees. Seems too good to last. In a few years OpenAI will just sell $1,000 per month Human-free Agent Coding for businesses.

Saying they have psychosis is a rude exaggeration.

A line? Enjoy the papers telling you otherwise. Not just the cognition it's down, LLM's degrade themselves on every iteration.

Not writing code isn't the same as vibe-coding. You can stay on top of AI, make it rewrite the things that look bad, make it refactor until you're happy with how things look, etc....

Maybe a lot of people who are doing that aren't admitting that they've stopped writing code, but when all you're ever doing is manually fixing a few lines, or moving blocks of code to more sensible places, fixing jumbled parameters in a call and such, you're not really writing code anymore. You're now a chef in a kitchen yelling at assistants and just touching things when dealing with communicating a correction to one of those dimwits is more frustrating than just doing it yourself.

You still have to be a cook to be a chef, though. But the reason I say that AI is dumb is because I tell it to do things, it does them in a dumb way, and I complain at it and tell it to write it in a sensible way. It screws that up, and I tell it to do it again, and not to screw it up. I'm still not coding. If it goes into a loop of nonsense, I touch things with the intention of doing just enough to knock it out of that loop (or rather keep the new context from falling into it.)

"After the bubble pops" we might see that a lot of new chefs can't actually afford assistants. But just as likely, the overbuilt (government-subsidized directly and through policy) capacity might end up getting written off, and at the cost of electricity and maintenance costs could stay reasonably good. Or algos improve. Or training methods improve.

No. AI is a must for software development. It's non-negotiable. The productivity gains are too great. The era of 100% human-written code is over. People will still do it as an idle curiosity, for personal projects only they intend to use. But even those open source projects with significant user bases that forbid the use of AI (like, afaik, NetBSD) will be eclipsed by those that support it in terms of features, capability, and security. And the commercial world? Forget it. You cannot keep pace with your employer's expectations unless you learn to use these tools well. This is not up for debate. It's reality.

Plenty of accomplished devs are getting good results and accomplishing tasks with unheard-of speed using AI, so if you're still not, that's a PEBKAC. You are not using the tools correctly. Figure it out before you complain.

I know this is the joke, and I know Evil is the jokey reply, but ... both sides of the joke carry a grain of truth, as good jokes do.

I know a lot of people become comfortable with the default editing tools in Emacs, and many of them are good, but on the whole, vanilla Emacs does not ship with a great editor.

The Vim family makes up amazingly well designed editors.

Evil is a Vim implementation in Emacs. It is the best of both worlds, and not just on paper. It actually works.

evil-mode