For another, the case mentioned in this post is quite specific. It's more useful to ask "ok, so they can't design circuit boards; what can AI do?"

I think it's worth distinguishing 'LLM assistance' based on how much thought/effort went into the prompt.

e.g. It's popular to hate on "my colleague just copy-pasted my question into the LLM and copy-pasted the response". Because the colleague added nothing by copy-pasting. But if I'm unfamiliar with some system, I ask a question, and someone gives an LLM response prompted with the right key words, that's more useful than I could have gotten myself.

e.g. OP claims to hate using LLMs, but also said that he thought that by using LLMs he was able to get a tighter comment to post. -- I don't really see the problem with that? If you don't want to use the LLM, post the raw rant. If you care about the quality & think an LLM improved the result, then... well, I guess if he just copy-pasted the result without reading it, that'd be silly.

"Expectations of productivity went up" seems a reasonable response to the excitement of seeing how impressive LLM coding agents are at some tasks. But it'd be nice to pare it back after seeing evidence that the productivity hasn't really improved.

EDIT: my experience has been that LLM coding agents, although better than you'd think, aren't as good as you'd hope. "You don't have to put thought into it any more" doesn't match my experience. But, if you've achieved the ability to productively craft great software without thinking & without being involved in the process, I'd be curious to learn how.

Modal editing is quite prominent in vim and vim-flavoured tools. So, I don't think model editing's lack of popularity is due to people not knowing about it.. although it's definitely a power-user way to drive a tool.

I wonder if a whole external device is really necessary for the one-handed device for chords. I think with a customisable keyboard, you'd be able to chord.

Seems that the idea is to use the mouse to point at the noun, then use one-handed chord to drive actions? Interesting idea.. some use cases still benefit from one hand on keyboard and one on mouse.

Rhombus looks promising in terms of tooling.

On the other hand: LLMs are susceptible to incorrectly guessing "I think it should work this way".. I'd guess the powerful flexibility of metaprogramming could be more annoying than helpful. But, I'm curious.

You move weight around, later you move the same around a bit more (yay!), or move a heavier weigh around (yay!).

You get to really know what your body is capable of.

This isn't traditionally 'practical'. It's quicker to just install the package, compared to writing a declaration that says to make the package available. (And for ops, Docker images won out in terms of practicality).

Nix also quite a steep learning curve.. I expect a beginner just wants to learn how to write a package in Nix, and not learn about 'derivations', 'instantiation', etc.

Interesting to see LLM coding agents adjust that trade-off: significantly reducing the cost to "write something in Nix", so the benefits become much cheaper.

Using e.g. Claude code: I could see this as next step: "plain text editor" progresess to "with autocomplete"; using an LLM coding agent is then an abstraction over editing code.

Using e.g. LLM-based system: natural language is "higher level" than program code. -- The maximal reading of "LLMs are higher level abstraction and higher level wins" would be: in the future, we'll all be writing only with natural language, never running any compiled programs.

I can see "LLM based coding" as a lasting paradigm shift. But, I don't see "just give your text instructions to the markdown file" as something that will be the predominant way of programming.

Turns out that understanding the technical domain is important to getting good results, even if the LLM is more capable at producing output. -- It's still a case of "garbage in, garbage out".

I think for many newbies, they see the LLM is so good at programming and so figure they don't need to learn anything. Apparently not so.

There's a significant difference between (say) 20wpm and 100wpm. -- Your comment is 150-200 words; so that's the difference between spending two or three minutes vs ten (just typing it out, not counting the time it takes to think).

If you limited your typing throughput to 10wpm, how long of a comment are you really going to reply with? Probably not a long one. -- If someone types at 160 wpm, are they going to type a better comment than someone typing at 80 wpm? Maybe? Maybe not? Probably not twice as long / twice as good.

I still think "typing speed is about latency, not throughput" is the key perspective. (Followed by diminishing returns. I think around 80wpm is fine). -- There are some cases where I'm doing the activity so infrequently that the cost of improving outweighs any benefit I'll see.

If I'm getting paid for the work, I'm happy to leverage the LLMs so I can do more. If I'm paying for the work, I expect more from it.

For hobbyist stuff, where I'm not expecting to receive money? LLMs let me do things I otherwise wouldn't have done.

I've agreed with thoughts like "the LLM wrote the code, surely it's not worth sharing" or "I could just have the LLM write my own version of that". I'd also wondered about my own personal projects, surely "an LLM could have written all of this". -- But how I feel about that changes a bit based on how much it'd take the LLMs to get the same output.

I noticed that coding agents seemed to get pretty good around 2025 Oct/Nov.

If it's improved? My experience with Nickel-lang (probably as not-in-training-data as Elm) is coding agents have improved with this compared to last time I tried.

With coding agents, agents can produce code quicker. The same trade-off still applies.. but, the time it takes an LLM coding agent to write well organised code is still going to be quicker than the time it takes me to write scrappy code.

The problem is: quickly fixing problems (or preventing problems) benefits from having a good understanding of what the code is doing.

If you do have a suite of automated checks that's comprehensive enough that if it passes, no one will have any problems with the result, I think I'd agree. -- I don't think we're quite there at the point where "programming" is coming up with that suite of automated checks and then just not regarding the source code of the program itself.

devenv brings modularity to development shells.

For example, you could configure your devenv module for the shell you want (which env vars you want set, which packages you want available, etc.), and then re-use this module in other shells.

As such, one of the nice things devenv provides is modules with the compilers/lsp/etc. for different languages, so getting a rust environment is about as simple as `languages.rust.enable = true;`.

I haven't explored using the services/processes aspect of it, but it's got support for things like that to. -- I saw it put somewhere: "oh, like docker-compose, but you can compose the configuration".

I'd characterise it as the opposite:

A unique aspect of NixOS is that it avoids global state as much as possible (& prefers to symlink things). -- By conspicuously avoiding / preventing this global state, everything has to be declared as an input for the 'package'.

For example: the Nix package for "ruby 4.0.5 built with gcc 16.1" would be a different package than "ruby 4.0.5 built with gcc 16.0". -- That afforts a greater level of flexbility. e.g. allows easily having multiple concurrent shells which run different versions of the same program.

The linked StackExchange has it as:

> What character was used for what control code was mostly a matter of bitwise arithmetics. LF is ^J because J happens to be at the corresponding location in the corresponding column of the table (+ 64 in decimal)

The same 'j' as vi uses for 'hjkl'. https://vi.stackexchange.com/questions/42426/why-did-vi-use-...

I see it's because you need to click the "show more"/expand button to see that disclaimer. -- Seems silly design to hide the disclaimer like that.

I see their main point as: it should still be possible to (in some way) have access to what you pay for after servers shut down.

Some games an online requirement makes sense (like where you play online with other people), but in some cases the online requirement is for a single player only game, where the server shutdown makes the game unplayable. -- Cases like that seem absurd.

LLMs are powerful at dealing with text. And Emacs is highly extensible and typically text-oriented. Already I see people say that LLMs much Emacs much easier to use (since you can ask an LLM to come up with the elisp for you), but I reckon what Emacs provides ought to be useful the other way.

With Emacs, it's common to see people favour bringing various parts of the system all within Emacs. I'm reminded of that when I've seen how useful it can be to provide API access to logging/code/documentation when asking an LLM to troubleshoot.

With LLMs, there are several uses cases I see which are a natural fit for org-mode, and just imitated in markdown. -- e.g. org mode have TODO items, checklists, tables (including spreadsheet functionality), code blocks, tagging/properties.