It is clear that LLMs are the new generation of PL, the biggest SWE revolution since assembly→3GLs.
The parallels & differences are fascinating.
Take interpreted vs compiled. Previously a property of the *language*, now a property of the *program*.
1. Interpreted = Store prompt, re-run each time (non-deterministic)
2. Compiled = Use the LLM to generate a 4GL program (deterministic)
Some use cases call for 1, others for 2, others for a hybrid. Choosing well will become a core SWE skill.
[1/3]
@leaverou I don't understand why you've decided to side with the technofascists in their systematic war against the free & open web. To say I'm disappointed in this is a *tremendous* understatement.
It pains me to see you on the wrong side of this war. I guess handcrafted coders simply can't assume anyone who has contributed to the web platform in the past is going to have their back.
Shame.
@jaredwhite I have not sided with anyone. My opinions are my own and I do not subscribe to the trend towards extreme polarization on this.
You are free to be disappointed, of course. I’ve also been disappointed in how many people I respect see threat where I see huge potential.
Thankfully, I have the maturity to disagree with people and continue respecting them.
Also, not sure what you mean with the present perfect there, unless your definition of "the past" encompasses "last week". 😅
@leaverou This isn't about disagreement. Tabs vs. spaces is a disagreement. JavaScript vs. TypeScript is a disagreement.
LLMs created by the tech equivalent of Big Tabacco, Big Oil, Big [Insert Bad Actor Here], which only “work“ due to industrial-scale theft and are inherently anti-labor in nature—along with a wide-ranging host of other global ethical ills—being promoted as the future of software development? Sorry, that's not something we can simply agree to disagree on.
@leaverou I simply cannot take your own statements at face value. You say:
"I do not subscribe to the trend towards extreme polarization on this”
Yet you also say this:
https://front-end.social/@leaverou/115991930255217767
Saying “it's a fascinating time to be alive!” because “almost certainly” we will get to the point where nobody has to look at code again because Big Tech LLMs have somehow abstracted it all away is an *extreme* viewpoint. I see no moderation in that sentiment whatsoever.
@jaredwhite The viewpoint may be extreme, but not in the way you think.
I did my PhD on end-user programming.
It was before AI. The field centered around:
1. Designing more learnable & highly abstracted PLs
2. Designing UIs to allow novices to compose or understand code.
It was very incremental. Any syntax (1) excludes many. UIs were limited/ing (2).
The vision of most EUP researchers was close to what is "vibe coding" today. Hard not to be excited it arrived so much sooner than we thought!
@leaverou If you were to ask me if I think we need higher-level, more abstracted programming languages, I would say yes!
My favorite language for the most part is Ruby. Some people have described it as the most English-like mainstream language, with very little syntax "noise" compared to others. And yet, I've argued it's still too low-level for some use cases. I'd like to write in something which "compiles to Ruby" as it were.
That doesn't mean I believe vibe coding is the answer. Not at all!
@leaverou I'm disappointed that you're ignoring all of the practical and ethical problems with LLMs. For starters, LLMs cannot be the future because they are driving increased fossil fuel use, which will destroy our biosphere and the civilization that operates LLMs. https://www.theguardian.com/environment/2026/jan/29/gas-power-ai-climate
LLMs are a self-terminating technology: either we get rid of them, or they get rid of us. Either way they cease to exist.
@skyfaller I cannot think of a single historical precedent where tech that added significant value to humans' lives was terminated because it was too resource intensive / costly.
OTOH, there is a ton of precedent where new tech starts off as incredibly resource intensive / costly and humanity eventually finds ways to make it economical.
If anything, the acceleration of the pace of innovation that AI enables may help us get there faster!
@leaverou This framing is incorrect in so many ways that I don't know how we reach a meaningful conversation from here. Some issues:
1. The climate crisis is urgent, we don't have time for "eventually". Gradual decarbonization means defeat and the collapse of civilization and the biosphere. "AI" increasing emissions at a time where we must immediately zero out emissions is unconscionable. The longer we wait to take action, the more difficult it will be to avoid catastrophic global warming.
@skyfaller Also, proportionality matters. Data centers are 1-2% of global emissions, and LLMs only a subset of that. Even if AI adoption is driving energy demand sharply upward, it seems unlikely that number will get to the double digits.
Even rapid AI growth is not in the same emissions category as cement, steel, transport, agriculture, etc.
@skyfaller Not all emissions are equivalent. The relevant question is "does this increase net emissions over time?" That must be measured, not assumed.
LLMs are infrastructure, not just consumption. Their climate relevance depends on what they substitute for, e.g. replacing travel with remote coordination.
And there's also the question of what innovations do they enable, e.g. accelerating materials discovery or grid optimization.
[1/n]
@leaverou
2. Efficiency gains do not mean reduced resource/energy use, due to the Jevons Paradox aka the rebound effect. When a technology becomes more efficient and therefore more "economical" to use, people simply use it more to get more "value" for the same price. It's counterintuitive, but increased efficiency generally means more emissions and environmental damage, in the absence of policies/systems to prevent that result, aka degrowth.
https://solar.lowtechmagazine.com/2018/01/bedazzled-by-energy-efficiency/
https://en.wikipedia.org/wiki/Jevons_paradox
@skyfaller I suspect that the underlying philosophical disagreement is actually about growth vs degrowth.
If someone believes that economic growth itself must stop to avoid collapse then any expanding compute infrastructure is morally unacceptable.
If someone believes that decarbonization + innovation can preserve prosperity, then AI becomes a tool whose value depends on how it’s integrated into a decarbonized system.
That is a worldview disagreement, not a data-center efficiency debate.
@skyfaller Jevons is not a physical law, it’s an economic pattern under specific conditions.
Jevons historically applied to physical resources. LLMs provide cognitive labor. It is not clear whether it still does.
First, local efficiency gains can increase local consumption, but system-level outcomes depend on price elasticity, substitution effects, and policy.
Second, there are also practical limits to how much we can utilize a resource, even if were free and infinitely efficient.
@leaverou
3. There are notable examples of tech being terminated because it was too costly, like CFCs which damaged the ozone layer, and leaded gasoline. Those may have been affordable on the individual level, but were costly to human health (and the health of everything else, but humans are often self-centered).
https://en.wikipedia.org/wiki/Ozone_depletion
https://en.wikipedia.org/wiki/Tetraethyllead
It is true that they generally were replaced with similar tech, we didn't get rid of refrigerators or (sadly) gasoline.
@skyfaller CFCs are not a good analogy *at all*.
1. I asked about precedent that added tangible value to human lives. CFCs did not — their only benefit was being more economic for the companies that manufactured certain things.
2. CFCs had clear substitutes. AI added value to the everyday lives of regular people in a unique, unprecedented way. Even human labor cannot always replace all tasks that AI can do, e.g. due to limits in cross-cutting domain expertise.
I know of at least one tech that added significant value to human's lives and was terminated because the environmental cost: CFC.
They were cheaper, more efficient, more practical. But they were killing the ozone layer, so they got totally banned, with an exception for medical uses.
There are a ton of pesticides and chemicals to add to that list.
About tech that starts resource intensive or costly, and never got anywhere, there are many; but nobody remembers them.
Most of innovators have real trouble finding investors to make their inventions reach the profitability stage, so their inventions get thrashed.
Remember: electrical vehicles were invented more than a century ago, but burning petroleum was much cheaper and electricity was still not so available, so they were ditched until a time where we found fuel too costly in many ways to continue using it.
I gave you a bunch of examples, and you ditch them all because you didn't like the first one.
Ok, I'll bite, but I see what you are doing here.
CFCs were cheaper, of course, but they were by far a better solution for many things, too. Spray cans, for example, are much, much more bulky and weight more nowadays because we still don't have anything nearly as good as CFCs were. I perfectly remember those cans, and I remember many people complaining about how they were selling less than half the product in a bulkier can for a bigger price. Myself included, until someone explained it to me.
@jgg What I’m saying is there is a fundamental difference between "can do X better" (for some definition of better) and "can do X that was not possible before". All of your examples around chemicals are the former.
Re:tech innovation, if the invention never got anywhere it had not yet added value to human lives, so it's not a valid answer to my question. I wasn't asking about potential value, I was asking about actual, realized value.
[2/3]
But nearly every argument against LLM-assisted programming has appeared before.
Assembly programmers in the 50s said the same things about 3GLs:
“Real programmers write assembly” they’d cry.
High-level languages were “inefficient, buggy, and produced slower, bloated code” compared to hand-optimized assembly code.
“You can’t trust what you didn’t write!”
And they were not wrong — at first. Early compilers did produce worse code, and debugging machine-generated output was miserable.
[3/3]
The turning point was when compilers became so good, you almost never had to *look* at the generated code at all. You could entirely live in this new level of abstraction.
We’re not quite there yet with LLMs, which explains the current resistance from experienced SWEs. But if history is any guide, we almost certainly will get there, soon.
What a fascinating time to be alive!
@leaverou There is a huge difference between compilers and LLMs : Most compiler were open source while LLMs are mostly owned by fascist.
@leaverou I think what bothers me is the "interpreted" generation, where it's generating a bunch of code by wizardry from a prompt, and that prompt can be very high level; "build an app that does X, Y, Z".
I don't like that the LLM's source data is an internet that is already bloated and somewhat broken, insecure and inaccessible, as that's what they spit out too.
If it eventually becomes another level of programming language, and we can be precise with it, and get safe output, fine with me.
@sarajw @leaverou I think the difference that stands out to me is that a high-level language (from C on upwards) produces machine code that’s deterministic. For a given input, a compiler will always produce the same machine code output. (Barring things like optimisation settings, but those are deterministic too.)
Whereas an LLM will produce code that’s approximately the same, in a high-level sense, but not literally the same. Even just running the same query twice might produce two different versions. That seems like it has several downsides and it would be a long time before it would be reliable enough just to treat it like a compiler, if ever.
@benjamineskola @sarajw Determinism is not a requirement, it's pattern matching based on the current status quo. The actual goal is quality and (as you mention) reliability.
Determinism is a proxy, and a very tedious one at that: because we don't trust LLMs to produce quality and to be reliable, we want determinism so we can manually check the result. The goal is not control however, it's to get to a point where we can trust the result.
@leaverou @sarajw Yes, that’s fair, determinism is just a means to an end.
But I do think that it’s going to be a long while before we can abandon that as a metric, and all of the hype I’ve seen around LLM-driven programming seems to underestimate that or not consider it at all.
My impression is that there has been more of a shift towards reproducibility in recent years anyway, because of concerns like supply chain attacks and so on. It’s desirable to be able to reproduce a compiled binary precisely and get identical output, to ensure that the source is what it’s meant to be. LLMs would seem to require a new techniques being developed in order to do so.
@sarajw how does the former differ from the latter? Both are using your natural language input to generate code. The more precise you are, the more control you have over it.
@leaverou from the experience of the person doing the inputting, there's probably very little difference, especially if you don't look at the generated or compiled code and just check the end result.
I do find it interesting and I'm not here to fight - as I've had this train of thought too (though you've obvs done the research).
From the energy use and IP theft side of things, very different, though. I actively feel some guilt when I go ahead and use an LLM.
@leaverou I don't think any of them can really get the nuance and precision sometimes needed on the front end.
People find it difficult - hence already existent is the abstraction built upon abstraction UI libraries (that I also don't like!), the better ones at least bake in some level of accessibility and keep to web standards underneath it all.
Someone still has to build those libraries. Maybe in the end it'll all come out in the wash with LLMs, but it's so very hard to wash off the ick.
@sarajw I’m conflicted on the IP theft issue, and don’t feel I have enough data for an informed opinion. Here’s my current thinking: When a human reads a book and that influences the way they think or write, we don’t think they’re stealing IP, right? Of course there’s a threshold; if they get *too* close then it is stealing. But the training is not IP theft by itself.
however, your first post highlights one of the key differences—determinism. When ASM programmers (yes, I'm of an ASM-coding vintage 👴) ceded to compilers, it was because compilers not only produced more efficient code, but the output was deterministic and verifiable. Same input→same output, reliably.
LLMs fail at reliable determinism by their very nature, incorporating randomness/"temperature" as a *feature*, so what worked yesterday, might fail catastrophically today because of a random-number generator.
