[irjustin]

For now, I can imagine a not too distant future where this is largely untrue.

LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs?

At some point you stopped needing to understand the layer down because the layer you were on became so good. Yes there are always corner cases, but for the vast majority of developers/engineers out there, staying at your layer was enough to make a career out of it once your layer hit a certain maturity.

[palmotea]

> LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs?

People keep trying to make that analogy, but it doesn't really work because LLMs aren't deterministic like compilers and assemblers.

[maccard]

They don’t need to be dererministic, only reproducible.

They’re not reproducible, nor are they even reliable right now.

[bloppe]

I don't think there's a meaningful difference between "deterministic" and "reproducible" the way you just used them. How can something be reproducible if you can't accurately predict what it will do?

Regardless, you can make them deterministic by turning the temperature down to zero. Just nobody likes doing that for whatever reason. I guess it ruins some sort of illusion people seem to like.

[Izkata]

Also to be a compiler-type next-level-up abstraction we'd have to be at the point where we commit the prompts and throw away the code.

(Which is pretty much what determinism would get us, but in these conversations way too many people seem not to understand what determinism is, so describing it in terms of actions the developer takes might work better?)

[jonfw]

It is not obvious to me that determinism is a requirement for an abstraction

[Toutouxc]

IMO delegation isn't abstraction.

I work at a certain level, like Ruby code. That's what I write, debug and maintain. I don't really care about the internals of the interpreter or about the source code of Linux, because these layers are taken care of, they're reliable and they're being developed by competent people. I [think I] know what Ruby code should look like in order to remain [reasonably] fast, maintainable and reliable, and it's my job to build a product out of that kind of code. If I keep writing code like that, I know for sure that I'll be able to keep building the product, because the layers underneath are deterministic. It's like the certificate chain of trust, but with "surely these people are not idiots". And that's simply not the case with LLMs.

Not only can the LLM be a massive idiot, but also an unpredictable one. I can try to warn it, steer it, police it or review as much as you ask me to, but ultimately you're asking me to delegate my job and my responsibilities to an intermediate whose reasoning I don't understand, who has no loyalty, no sense of pride, no sense of ethics, can't be taught and can't be fired.

[palmotea]

> It is not obvious to me that determinism is a requirement for an abstraction

But it is a requirement for them to be an "abstraction just like" assemblers or compilers, which is what was being claimed.

[theshrike79]

If the result looks like a duck, walks like a duck and quacks like a duck every time, isn't it deterministic enough?

[skydhash]

> LLMs are an abstraction just like machine code -> assembly -> C/JVM -> some lang -> LLMs

The what is the semantic mapping between <some lang> and LLMs?

I know the semantic mapping between maching code and assembly (some light weight syntax manipulation and macros). I know the one between assembly and C (the C abstract machine, which is mostly about the stack and whatever call/ret instructions pair). I know the one between C and something like python (not so much different than the one between C and assembly in mechanism).

Please talk about how you go from A LLM prompt to a piece of code in Python and guarantee the intent remains unchanged.

[tibbar]

The non-determinism is one of the relevant features of this layer of abstraction! And one can learn to validate that the translation is being done properly. Some of the tools you have include writing extremely detailed specs, generating visualizations of the internals of the tool, or (perhaps) reading the code, though that becomes less feasible with volume.

Basically it turns out that code is full of incidental details and what you really want is to verify the important parts, while receiving a guarantee that the vast tail of incidentals is handled "reasonably."

[bitwize]

LLMs will still blithely ignore the specs and steering documents, apologize profusely for doing so after the fact, and tell you "I'll do better next time" which they might do once or twice. But after the context is cleared or a new session opened, the Dixie Flatline gets reset and it doesn't remember it screwed up, or that you told it not to.

This happened to a coworker of mine. Generally the response from one-shotted devs is a shrug of the shoulders and "wellp, them's the breaks! As long as it looks sensible from 10,000 feet up it's still a huge productivity win." But the devil, as they say, is in the details.

[lenkite]

Writing Specs that are thousands of lines wrong without formalism, type and correctness checking is a major PITA. Wish we had a..compiler that can check our code..err I mean spec.

[duskdozer]

Oh, are you still handwriting your specs? How Q2 2026. Handcrafted artisan specs are obsolete and you will be left behind in the dust if you still insist on them.

[weakfish]

Poe’s law displayed beautifully here

[Izkata]

In which direction? It wasn't long ago having the agent generate a plan before acting on it was a "best practice".

[bcrosby95]

Writing specs validates the translation is being done properly? Was this written by an LLM?

[tibbar]

Writing detailed specs is an important tool to help the LLM translate the idea in your head to code. The spec is an intermediate artifact.

[bloppe]

If this is true, then at some point we will stop committing source code to repositories, and instead commit prompts. The LLM would be a "compiler" that can reliably turn a vast collection of natural-language prompts into a complete system.

I just don't see that, not least of all because natural language is inherently ambiguous, whereas all the other rungs in your latter ("machine code -> assembly -> C/JVM -> some lang") are completely unambiguous by design. Consider "I saw the man with the binoculars". Does that mean "I used binoculars to look at the man", or "The man I looked at was holding binoculars"? This is the kind of inherent ambiguity that Lojban was invented to mitigate. Maybe some day we'll write "natural" language prompts in Lojban that can be unambiguously translated by an LLM, but that sounds a lot like just using a "some lang".

[weakfish]

IMO English as a programming language is a fools errand. Part of the reason why we _have_ programming languages is because it turns out human language is too ambiguous.

[alightsoul]

There's an increasing amount of jobs where the job role is analyst but you're just feeding the ai with whatever the task assigned to you was. These are not software jobs but are business jobs. Like User acceptance testing quality assurance aka bureaucracy

[archagon]

LLMs are as much an "abstraction" as outsourcing your app to a bunch of contractors: a silly dilution of the word to the point of meaninglessness.

[glouwbug]

They aren't because we're not committing prompts. The analogous would be compiling to and then committing unmaintainable assembly when the higher level language, which is a deterministic compiler, already exists

[chii]

> not committing prompts.

nothing prevents people from committing their prompts. I've started seeing prompts being committed into repos, or at least as part of the commit message.

In any case, if in the future there's a prompt specific language, it would be committed. I dont think we've reached there yet, but i dont doubt this is on the path to the future.

[Toutouxc]

> if in the future there's a prompt specific language, it would be committed. I dont think we've reached there yet, but i dont doubt this is on the path to the future

You mean, like a ... programming language? Honestly I can't tell these days what is satire and what isn't.

[alightsoul]

I posted a while ago about connecting an LLM directly to an assembler and people thought it was a bad idea. Now we're going in exactly that direction

[kbelder]

But at every point, your product was better if you still understood the lower level. Your Python is better if you understand Assembly.

[woodpanel]

There is a always going to be the gap of what you can do with LLMs if you know how to code vs if you don’t

[lowbloodsugar]

This is only true if it plateaus. What you are saying is “I don’t think LLMs will achieve superintelligence.” Which is a fine opinion to have, but it’s an opinion.

[woodpanel]

once, if ever, the plateauing happens. Until then there is going to be this gap.

In other words, superintelligence often referred to as AGI might either be months away or just VC-Money induced cult-speak many fall victim to.

It doesn’t matter because the only certainty is that it’s not here now, and neither tomorrow etc.

[sfn42]

To me it looks like they've been pretty plateaued for a good while already? Sure they do marginally better on benchmarks or whatever, but to me as a user there's really not much difference between chatgpt today and chatgpt a couple years ago. Main difference is just added capabilities like web search, image recognition etc.

For coding you still need to be in control if you want a good result.

[simg]

AGI is human level intelligence. superintelligence is ASI