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.
A naive hope is: you see that the LLM is so good at coding that all you need to do is supply a "yes/no" on what you want.
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 think the last time I tried was a year ago though, so I assume it has improved.
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.
Another consideration: written by hand, the trade-off of development velocity vs well organised code means that it can be worth taking some tech debt now in order to deliver some value now. (Especially when prototyping etc.).
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.
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".
> Also, NixOS is not very flexible. I prefer e. g. /Programs/Ruby/4.0.5/
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.
> I suppose you're saying ASCII 10 was chosen as newly because it aligns with the down arrow on keyboards of the time. Maybe.
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)
SKG aren't going for a maximalist "if you publish an online game, it must 100% work forever". Unfortunately, it seems it's not so easy to find a clear mission statement.
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.
I do wish that Emacs was more popular with LLM technologies.
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.
If the thing that you enjoy about programming is writing code, you can have the LLM write code in the style you like. If you enjoyed getting to explore and understand a system, an LLM can help you do that quicker, too.
"Use LLM without thinking" won't get you substantially useful results.
> But LLMs don’t seem particularly good at inventing new ways to code (or write, or…). It’s literally all derivative.
I think the key part is how much thought goes into something.
Optimistically, LLMs are good at taking unstructured input, and (probably) producing the intended output from that. -- This allows for an interesting new way of coding: a set of instructions don't need to be as rigorous as a shell script, but can be natural language.
That part surely extends creativity. An LLM will be familiar with domain ideas I'm not, even if an LLM is completely disinterested in doing things.
Pessimistically, I think it's still not clear what the right way of interacting online with all of this is (other than clear expectations of "no AI")... in some sense LLM output is worthless to share, in the sense that I'm just as capable of asking the LLM to output something as anyone else is.
Seems to me LLMs have changed some things. I'm not sure how it's best put, but it used to be:
- Seeing code (or a blogpost or whatever) was a result from effort where thought had gone into it. The writer paid effort so the reader didn't have to.
- There'd be some level of attachment to what you've put effort into.
With LLMs, that's undermined: it's easy to produce thoughtless imitations. Code or comments where thought didn't go into it. So, seeing some result isn't an indication of skill, but also not even an indication thought went into it.
I guess there's still something lost if someone isn't going to share code they've put thought into. -- But on the other hand, if it's just for me & I don't have to share it with a wider audience, getting LLMs to write out code isn't so expensive.. so code itself isn't necessarily something to value so much.
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.