I read "out of box" as meaning "has sensible defaults, can be used 'out of the box' without configuration".

I've never seen it used to mean "preinstalled on most systems". Although e.g. people like vi keybindings because vi is preinstalled on most systems.

Either way, I think you can argue for workstations, it's worth configuring software to your liking, and worth installing software that helps you be productive.

Though, the only software I've seen people excuse for having 'bad defaults' have been things like vim, emacs, tmux.

My first instinct reading an article (especially one about LLMs) is to scroll down to see the structure..

Anyway.

Do people get the impression that LLMs are worse at frontend than not? I'd think it's same with other LLM uses: you benefit from having a good understanding of what you're trying to do; and it's probably decent for making a prototype quickly.

I like the quote about how different programming languages give you tools to think in different ways.

I get the impression languages like k are a good example of this. (That C code looks as dense/concise as k).

OP's post features he wants "that isn't absolutely crowded that I could meaningfully contribute to."

I could read that as: wanting to do something interesting that others would benefit from.

Though, I don't really think that's a good reason to filter out things to be enthusiastic about.

I reckon if you asked fountain pen enthusiasts whether they'd prefer to type or to use a cheap ballpoint pen, I bet they'd agree with your assessment.

> Then there's "Flakes" which I never quite understood

Flakes do 2 things:

1. Declaration of the inputs and outputs of some Nix codebase. 2. Pinning the versions of this input sources.

The dependency pinning is similar to package.json/package.lock etc. which are common in language-specific package managers.

For a single machine? Yeah, NixOS' cost surely outweighs the benefits if you're not familiar with Nix.

Using Nix for per-project development dependencies is quite good. It's nice to be able to return to a project & not have to fuss over which tools/libraries need to be installed.

> nix is superior in every single way.

My experience using NixOS on desktop is that it's 95% wonderful, 5% very painful.

If you run into friction with NixOS, you may need to have a wider/deeper understanding of what you're trying to do, compared to the more typical Linux OSs which can be beaten into shape.

With NixOS, you pay all the complexity up front.

Such a pity that the article didnt touch on running rust nightly or the sometimes statefull nature of user configs of some programs. The 5% painful part was just around the corner.

Fair point but I've stopped trying to declaratively manage stuff in nix that has its own idiosyncratic state management. That way youre just using nix to run an installer.

devenv lets you express shells as modules.

Modules let you express the system in smaller, composable, reusable parts rather than express everything in one big file. (There are other popular tools which support modules: NixOS, home-manager, flake-parts).

That devenv also provides "batteries included" modules for popular languages (including linters, LSPs) is also a benefit.

May be splitting hairs, but I don't think it's the terminal-native part that's relevant, so much as that both LLMs and emacs/vim are text oriented in ways which e.g. VSCode isn't. (Or perhaps just the text-oriented nature is a result from initial constraint from being terminal-native).

As the author points out, that Emacs is a highly extensible 'operating system' which makes it relatively easy to bring different tasks together. -- This ought to be a natural parallel to what the agentic tools are trying to do (use MCPs and skills etc. to bring different functionality to the LLM execution environment).

That LLMs can help users extend emacs ought to lower the difficulty curve.

Still. It's silly to wish that Emacs could be the LLM's best friend, rather than demonstrating how it is.

RE: "what if in the future all coding skills are irrelevant". My experience has been that good results from LLMs come from putting good thought into its usage. They're quite far from a magic "push the button and get the result you want" where the skill doesn't matter.

Not totally related to your point BUT I’d like to tack on that lisps and generally repl-friendly languages are in an interesting spot in the LLM-enabled world.

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!

I don't let it execute emacs lisp itself, but elisp generated in org mode babel blocks which is instantly executable is a fine way to have gptel improve itself.

( See "meta tooling" in https://poyo.co/note/20260202T150723/ )

This is super exciting. Emacs already treats UI as just more Elisp to eval. The AI could sculpt the entire editor to whatever you need in the moment. No plugin to install, no config to maintain. Just describe what you need and the editor becomes it.