LLMs bring new nature of abstraction – up and sideways

Here's a summary of the themes expressed in the Hacker News discussion about the article, focusing on the role and nature of LLMs in programming:

LLMs as a New "Activity" vs. an Abstraction

A core debate revolves around whether LLMs represent a fundamentally new type of activity in computing, distinct from traditional programming, or if they are merely a new layer of abstraction over existing processes.

oytis questions the premise entirely, stating, "He admits himself that it's not an abstraction over previous activity as it was with HLLs, but rather a new activity altogether - that is prompting LLMs for non-deterministic outputs." They further ask, "Even if we assume there is value in it, why should it replace (even if in part) the previous activity of reliably making computers do exactly what we want?"
felineflock clarifies this distinction by saying, "It is a new nature of abstraction, not a new level."
UP articulates the potential of this new activity: "It lets us state intent in plain language, specs, or examples. We can ask the model to invent code, tests, docs, diagrams—tasks that previously needed human translation from intention to syntax."

The Value Proposition: Solving Harder Problems Unreliably

A significant point of contention is whether the ability of LLMs to tackle more complex or underspecified problems, even unreliably, outweighs the predictability of traditional programming for simpler tasks.

dist-epoch argues for the utility of LLMs in this context: "Because unreliably solving a harder problem with LLMs is much more valuable than reliably solving an easier problem without."
When asked about these "harder problems," dist-epoch posits, "Anything which requires 'common sense'." They offer an example: "there are only 100 MB of disk space left, but 1 GB of logs to write. LLM discards 900 MB of logs and keeps only the most important lines." This is characterized as handling "edge case handling that LLMs can 'do something resonable' that before required hard coding and special casing."
dist-epoch further elaborates on the trade-off: "you can solve unreliably 100% of the problem with LLMs, or solve reliably only 80% of the problem. So you trade reliability to get to that extra 20% of hard cases."

Concerns About Unreliability and Catastrophic Failures

Many participants express deep skepticism about relying on LLMs for tasks where failure can have significant consequences, fearing emergent or cascading negative behaviors.

sarchertech counters the example of log truncation, noting that simpler, deterministic solutions "had some percent chance of solving 100% of the problem." They then express a strong preference for failure: "I’d much rather the system just fail so that someone will fix it."
The potential for widespread LLM-driven decision-making is painted negatively: "Imagine a world where at every level instead of failing and halting, everything error just got bubbled up to an LLM that tried to do something reasonable. Talk about emergent behavior, or more likely catastrophic cascading failures."
sarchertech critically evaluates the "do something reasonable 90% of the time, but do something insane the other 10% of the time" paradigm: "My point is there aren’t many scenarios where 'do something reasonable 90% of the time, but do something insane the other 10% of the time' is better than do nothing."
Another user notes their personal experience: "I’ve been using LLMs at work and my gut feeling saying I’m getting some productivity boost, but I’m not even certain of that because I have also spent time chasing subtle bugs that I wouldn’t have introduced myself."

LLM Unreliability vs. Human Unreliability and Guardrails

The discussion touches upon whether LLM errors are comparable to human programmer errors and if existing software engineering practices can mitigate LLM-induced issues.

pydry posits that LLM unreliabilities can be managed similarly to human ones: "LLM unreliabilities seem to align quite closely with ours so the same guardrails that protect against human programmers' tendencies to fuck up (mostly tests and types) work pretty well for LLMs too." They also frame programming as building defenses against inherent human unreliability.

The Nature of LLM Determinism and Reproducibility

A technical facet of the discussion concerns the actual determinism of LLM outputs, with users debating whether controls like seeds and temperature settings guarantee reproducibility.

UP highlights the "BUT SIDEWAYS" aspect of LLMs: "Generation is a probability distribution over tokens. Outputs vary with sampling temperature, seed, context length, and even with identical prompts."
dcminter questions this to some extent: "Surely given an identical prompt with a clean context and the same seed the outputs will _not_ vary?"
diggan clarifies that while setting temperature to 0.0 aims for reproducibility, it's not always guaranteed due to model implementations and architectures. They also note the sensitivity of LLMs to prompt phrasing, which differs from human expectations: "we tend to think that prompts with similar semantic meaning will give the same outputs (like a human), while LLMs can give vastly different outputs if you have one spelling mistake for example, or used '!' instead of '?', the effect varies greatly per model."
diggan further explains that even with static seeds and temperature set to zero, reproducibility isn't always achieved, and hosted models often only offer "mostly deterministic" outputs.
furyofantares introduces a distinction between "technical determinism" (making outputs technically reproducible) and "practical determinism" (an author's ability to predict results). They note that their ability to reason about LLM results from prompt changes is "fuzzy," lacking the precision of reasoning about code.

Critiques of Fowler's Past Influence and Consulting Role

A significant portion of the thread diverges to critique Martin Fowler's past contributions, particularly his Object-Oriented Programming (OOP) evangelism and his role as a consultant, questioning the applicability of his current views on LLMs.

kookamamie expresses a negative sentiment: "Funny, I dismiss the opinion based on the author in question." When pressed, they cited "damage was caused by their OOP evangelism back in the day."
kookamamie further criticizes specific concepts: "advocating things like Singleton as anything beyond a gloriefied global variable is pretty high on my BS list."
diggan defends Fowler by shifting blame to followers: "Don't get me wrong, I feel like Fowler is wrong about some things too, and wouldn't follow what he says as dogma, but I don't think I'd attribute companies going after the latest fad as his fault." They also argue that Fowler's perspectives are often contextualized for improving legacy code.
alganet frames Fowler as a consultant whose work is influenced by his role: "Mr. Fowler works for a consultancy. LLMs sound great for consultants. A messy hyped technology that you can charge to pretend to fix? Jackpot." They suggest a "consultancified" version of real-world experience.
alganet quotes Fowler's "aboutMe" page to support their point: "I don't come up with original ideas, but do a pretty good job of recognizing and packaging the ideas of others... I see my main role as helping my colleagues to capture and promulgate what we've learned about software development..."
Disposal8433 offers a mixed review: "His Refactoring book was a good thing at the time. But it ends there, he should have tried to program instead of writing all the other books that made no sense."
dtagames criticizes those who comment without understanding current tools: "I respect Martin Fowler greatly but those who, by their own admission, have not used current AI coding tools really don't have much to add regarding how they affect our work as developers."

LLMs as Productivity Boosters or Sources of Subtle Bugs

User experiences with LLMs in their own workflows are mixed, with some seeing potential productivity gains tempered by the introduction of new kinds of errors.

furyofantares states that LLMs "just solve problems I can solve much, much faster," suggesting this speeds up delivery of higher-level business solutions rather than purely technical problems. They also differentiate using LLMs to program from producing software that utilizes LLMs.
dist-epoch counters by framing LLMs as a way to "outsourc[e] 'business logic' to an LLM instead of trying to express it in code."
As previously mentioned, sarchertech noted personal uncertainty about productivity gains due to time spent fixing subtle bugs introduced by LLMs.

LLMs as Tools for Bridging Skill Gaps

One perspective suggests LLMs can help individuals tackle problems that would otherwise be out of reach due to skill limitations, even if the process is less direct than traditional coding.

dist-epoch uses the example of a web development novice wanting to create a web app: "If you've never done web-dev, and want to create an web-app, where does that fall? In principle you could learn web-dev in 1 week/month, so technically you could do it." This implies LLMs as a shortcut to achieving a desired outcome without full mastery of the underlying process.