Not the parent poster, but I'm curious why you think this? the comment seems reasonable and makes sense, your LLM detector might be more finely tuned then mine...
I've proposed this a few times, as someone whose second language is English, I can see people learning English with AI, same with teens in school. I used spellcheck in Firefox (back in the mid 2000s) to teach myself how to spell more words instead of just relying on it and forgetting about the corrections.
We are and will reach a point where more and more people speak like, and sound like AI talks. The assumptions that something is AI are going to become really useless without further evidence.
"Here is the X part", a commonly generated attention catcher these days, combined with an expert level fact, compacted into casual tone. Note it does not state opinion or reports subjective experience, which alltogether makes it a somewhat unfailable "Did you know?" addition.
It is easy to mass generate such commentary and you can frequently find it on Twitter, too.
I find it hard to believe that a human would after reading this article make the stated observation, and then write this exact comment.
Some people have AI fatigue, I have "this is AI" when nothing says it is fatigue, that and "this is slop!" without looking at it and judging it by the output fatigue.
The problem is that we can no longer trust whether something we're reading is an actual thought that someone had, or if it's copy-pasted garbage that's put there for internet points. The extra effort that comes from that decision is what causes the fatigue.
The internet was low-trust before, and now it's zero-trust.
That's the thing though, you say copy pasted garbage based on what? What if its impeccable code, some of the best you've ever read, has zero bugs, but then you find out just before downloading it, that AI was used for it. Do you throw it all away as slop? You don't even know how much was done by AI by this point mind you, what if it was very little, what about half? What if all of it was AI, 100% of it, but you didn't even notice before, so where's the bar? Are we after quality or just "a human must have spent hours for me to use the code" which is it? Because for me it's just is it reasonable quality? Then I'll use it. In fact, I use things I "vibe coded" for myself everyday, rarely finding bugs.
If i didn't notice, that's great! If it were all of such high quality, then people wouldn't have nearly the objection to it. The problem is, especially with long-form prose, that the AI output looks plausible enough, but I've put a lot of effort into reading it before discovering that it's garbage. The cost is entirely too high.
With code, that problem is worse, because code is generally much harder to read then it is to write. Plausible looking code is great until it leaks personal information, damages equipment, or destroys work.
How perfect does it need to be though? Code by humans is anything but. My problem is I see "THIS IS JUST SLOP" style comments, and it seems obvious they didn't even bother looking at the code, or testing it, they just wrote it off. Imagine if we wrote off software for discovering the developer used auto-complete (which can give you bad code too if you have no idea what he method or property you actually need is!).
For the record I agree with you, and probably most people upset with Slop, but the bar seems unclear and I think this is a bigger problem because having built all sorts of things with AI I find it unfair especially knowing how much effort it takes to do so. If you read one of the Claude focused subreddits there's people like myself who've replaced playing video games with using Claude deep into the midnight hours to hand-craft software with Claude.
It's not about being perfect (or even good!), it's just that the value of some artifact is much higher if there's any evidence that some real effort was put into its creation.
BEAM threads are kinda magicsauce tho, instructions have a cost and after a certain cost total (quantums) the scheduler can divert to another virt thread to guarantee forward progress. Also the immutability rules etc make it easier to optimize this switching.
Eh, reduction counting isn't magic. Golang manages similar preemption semantics without counting that many operations (some tight loops do have barriers inserted every so often, but that's the exception and not the rule). And reduction counting has some serious costs! It slows the runtime down a shitload (and the BEAM is already in the bottom half of interpreted language runtimes by speed) and makes lots of JIT-flavored runtime optimizations slower or harder to implement.
I like immutability too; I wish Java and Golang did more of it. It costs a lot in terms of unexpected copies in the BEAM though, there's less copy-elision optimization than you'd think. That especially bites if you're doing a ton of message passing, because of how process heaps are implemented and how garbage collection (traditional or ETS/ThreadProgress-based) works.
I think what I want is something like Golang but with goroutine-based ownership semantics (or Rust with the Go runtime and goroutines): en excellent scheduler for extremely light-weight green threads, no refcounting or reduction counting, and all the clever optimizations around channel sending and copy elision--but no ability to use a value after it's sent to a channel, and only channel-based access to shared global state. That'd get most of the benefits of process-local heaps but without the (copying, cache/memory fragmentation) drawbacks.
These are all true and I have recognized those as innate limitations of the BEAM VM. For now I am OK with those but I am already skirting at the limit and I am starting to want to jump to Golang and Rust again.
Obviously. But it's really nice to have the option, and none of us knows the future. I've been bitten by those "0.1% chance" things much more times than I would be not-embarrassed to admit, and I know I a not alone.
Good, thanks for the grounding. I'll have to reevaluate at one point then.
As I just posted in another comment (https://news.ycombinator.com/item?id=48384622), I'd probably drop Erlang/Elixir due to difficulties of employment and contracting -- if the more popular languages get those STM / share-nothing runtimes.
Clojure is about its rigorous and pragmatic "immutability first" paradigm that you simply don't get from other PLs.
LISP is much more than just a runtime syntax, such as its distinct evaluation model and metalinguistic core.
The JVM was chosen for Clojure because of its reach and vast ecosystem. People have ported Clojure to other runtimes, even Beam (Clojerl), where it enjoys decent success, too.
Clojure on JVM with virtual-threads (green threads) and communicating only via core.async channels (CSP inspired) using immutable data structures is pretty neat, FWIW.
Erlang is weird in this regard. It has very strong guarantees when it comes to per-process heap that make GC much simpler: no escape hatches for mutability when most immutable languages do include them! But on the other hand inter-process communication is a form of mutability (using another process as a global mutable variable is trivial) and ETS etc. present a mutable interface.
Not sure this type of response helps and referring to someone who is active in the Clojure community and tries to build some cutting edge stuff as 'this guy'. (Did some digging and hyperfiddle looks pretty cool).
I think it would help to understand why he is talking about this 'every two months' and then try to address his concerns.
Would be a shame to lose people who are active in the community but not heard.
Of course. But for people not in the know and looking outside in, they don't know what's going, i.e. why is someone who's been using Clojure for years and building a business with it making these points every few months as you say?
To counteract FUD it would be useful to give a few more details.
Might be some personal beef, but I don't know really and don't care enough. He makes these authorative claims mixed with personal sentiment and then doesn't back them up.
Thanks for that. These details are important for newcomers, because it seems the original commenter isn't happy with the core team's process and 'feels like it's falling apart' is hyperbole and subjective.
For future readers: Clojure is known to be extremely stable and backwards compatible. It doesn't suffer from the same churn, fatigue and breaking changes that the JavaScript ecosystems experiences for example. To get to that backwards compatibility it requires a different process.
Indeed. Generated code is also harder to read because it violates all semantic expectations that rely on the mental model of a human author. A generated piece of code is linguistically plausible but often unknowingly imitates common idioms so incoherently that the actual bug may be accidentally disguised in a way no sane human (even a bad programmer) could have come up with.
Since LLMs have no internal evaluation, as a reviewer one has to account for it and evaluate line by line, rebuild from scratch any hidden rationale and tacit knowledge the LLM didn't have in the first place - only to be mislead into non concerns draining costly hours.
At this point, the investment is often deeper than writing from scratch.
I tried to capture some of my feelings on this on a recent personal blog post/rant. The easiest phrase is that LLMs are "legacy code as a service". They are trained on other people's legacy code. (No one is intentionally feeding LLMs their best proprietary code.) They produce output that is "Day 1 Legacy Code" in the sense that there's no human code owner to take responsibility and you might be able to ask the LLM that built it questions, but it is easier to accept is as the LLM that wrote it is no longer at the company (between context/memory limitations and regular model upgrades/retrainings, etc).
But also, yeah, it starts to get worse than classic legacy code because you could try to build a theory of mind about the legacy code author(s). There were skills in trying to "mind read" a past generation. To find clues in poetry words more than the poetry form. (The variable names and whatever comments may have survived including commit logs; things written for humans to help explain the whys/hows, not just the whats.)
"legacy code as a service" - that's apt. But would they be better if they trained exclusively on 'good code'? I know I don't know the answer to that question and I get the feeling that few people actually understand how they work enough to feel comfortable with asserting that to be true.
Yeah, I still wouldn't trust them if they were training on more good code, either. I think I understand enough of how they work to believe that even given plenty of good code they won't be able to learn the parts that make good code truly good. That's where I start into poetry metaphors and that the best code is not just concerned with poetry forms (the rhythm and meter required by the language) nor the literal meaning (the compiler output) but also the human elements of the poem such as the creative storytelling and multiple levels of metaphors. I cannot see the current technology getting good at those human parts of the poetry, no matter how good they get at the literal and the form.
The problem there is the _large_ language model part, the density and the reinforcement of the weights. There's far less good code in the world. ;) These things emit code as well as I do, such as they do, only because they've inhaled essentially the totality of "code in general", not artisanal code.
> A generated piece of code is linguistically plausible but often unknowingly imitates common idioms so incoherently that the actual bug may be accidentally disguised in a way no sane human (even a bad programmer) could have come up with.
Came here to say this, but you said it for me. When you are an infinite code generator and your only parlour trick, your only hammer, is generation, and every nail is a problem of as-yet-insufficient generation, then generate you shall.
But the cognitive burden of metabolising this ultra-verbose, circuitous, often brute-force excreta is quite a bit higher than thumbing through a (competent) human's relatively terse approach.
They are just trying to peddle their "It's alive" headlines.
Text generators mostly generate the text their are trained and asked to generate, and asking it to run a vending machine, having it write blog posts under fictional living computer identity, or now calling it "Mythos" - its all just marketing.
I believe (correct me if I’m wrong), their point is that with time, we’re writing less code ourselves and more through LLMs. This can make people disconnected from the “joy” of using certain programming languages over others. I’ve only used cl for toy projects and use elisp to configure my editor. As models get better (they’re already very good), the cost of trashing code spirals downwards. The nuances of one language being aesthetically better than other will matter less over time.
FWIW, I also think performant languages like rust will gain way more prominence. Their main downside is that they’re more “involved” to write. But they’re fast and have good type systems. If humans aren’t writing code directly anymore, would a language being simpler or cleverer to read and write ultimately matter? Why would you ask a model to write your project in python, for instance? If only a model will ever interact with code, choice of language will be purely functional. I know we’re not fully there yet but latest models like opus 4.6 are extremely good at reasoning and often one-shotting solutions.
Going back to lower level languages isn’t completely out of the picture, but models have to get way better and require way less intervention for that to happen.
I used to appreciate Lisp for the enhanced effectiveness it granted to the unaided human programmer. It used to be one of the main reasons I used the language.
But a programmer+LLM is going to be far more effective in any language than an unaided programmer is in Lisp—and a programmer+LLM is going to be more effective in a popular language with a large training set, such as Java, TypeScript, Kotlin, or Rust, than in Lisp. So in a world with LLMs, the main practical reason to choose Lisp disappears.
And no, LLMs are doing more than just generating text, spewing nonsense into the void. They are solving problems. Try spending some time with Claude Opus 4.6 or ChatGPT 5.3. Give it a real problem to chew on. Watch it explain what's going on and spit out the answer.
> But a programmer+LLM is going to be far more effective in any language than an unaided programmer is in Lisp—and a programmer+LLM is going to be more effective in a popular language with a large training set, such as Java, TypeScript, Kotlin, or Rust, than in Lisp. So in a world with LLMs, the main practical reason to choose Lisp disappears.
You are working on the assumption that humans don't need to even look at the code ever again. At this point it in time, it is not true.
The trajectory over the last 3 years do not lead me to believe that it will be true in the future.
But, lets assume that in some future, it is true: If that is the case, then Lisp is a better representation than those other languages for LLMs to program in; after all, why have the LLMs write in Javascript (or Java, or Rust, or whatever), which a compiler backend lowers into an AST, which then gets lowered into machine code.
Much better to program in the AST itself.
IOW, why program in the intermediate language like JS, Java, Rust, etc when you can program in the lowered language?
For humans, using the JS, Java or Rust lets us verbosely describe whatever the AST is in terms humans can understand, however the more compact AST is unarguably better for the way LLMs work (token prediction).
So, in a world where all code is written by LLMs, using an intermediate verbose language is not going to happen unless the prompter specifically forcibly selects a language.
> The trajectory over the last 3 years do not lead me to believe that it will be true in the future.
Everything changed in November of 2025 with Opus 4.5 and GPT 5.2 a short time later. StrongDM is now building out complex systems with zero human intervention. Again, stop and actually use these models first, then engage in discussion about what they can and can't do.
> But, lets assume that in some future, it is true: If that is the case, then Lisp is a better representation than those other languages for LLMs to program in; after all, why have the LLMs write in Javascript (or Java, or Rust, or whatever), which a compiler backend lowers into an AST, which then gets lowered into machine code.
That's your human brain thinking it knows better. The "bitter lesson" of AI is that more data=better performance and even if you try to build a system that encapsulates human-brain common sense, it will be trounced by a system simply trained on more data.
There is vastly, vastly more training data for JavaScript, Java, and Rust than there is for Lisp. So, in the real world, LLMs perform better with those. Unlike us, they don't give a shit about notation. All forms of token streams look alike to them, whether they involve a lot of () or a lot of {;}.
> That's your human brain thinking it knows better. The "bitter lesson" of AI is that more data=better performance and even if you try to build a system that encapsulates human-brain common sense, it will be trounced by a system simply trained on more data.
I feel you glossed over what I was saying.
Let me try to rephrase: if we ever get to a future where humans are not needed to look at or maintain code again, all the training data would be LLM generated.
In that case, the ideal language for representing logic in programming is still going to be a Lisp-like one.
The difference between the programming tools available before and LLM-based programming tools is the difference between your hammer and that of Fix-it Felix, which magically "fixes" anything it strikes. We are living in that future, now. Actually try it with frontier models and agentic development loops before you opine.
Assuming that everybody disagreeing with such takes simply can't have tried the latest generator is quite telling. Consider, that maybe, I'm not as easily impressed?
reply