A compiler translating high-level code to machine code is a predictable and repeatable process.

An LLM translating a prompt to to high-level code has a much lower degree of predictability. To say an LLM prompt is a comparable abstraction is unfair, though I admit it's getting very close.

▲

bluegatty a day ago | parent [-]

The LLM will never produce the same output each time, it doesn't have to do that to have very strong level of abstraction.

But yes, it has to fulfill some kind of contract defined by the absraction.

It's less a problem of the LLM, and more so how we use them, and the inherent tooling around it.

▲

beej71 21 hours ago | parent [-]

I don't get the use of "abstraction" in this context, I must admit.

Programming abstractions offer interfaces to functionality that are both simplified in use and restricted in capability. (e.g. any API or compiler.) I don't see how LLMs meet that definition.

It seems more like we're talking about offloading or delegation, here. And that's a valid business tactic, certainly, but it's not a software abstraction any more than a CTO is an abstraction of a tech lead, no?

> But yes, it has to fulfill some kind of contract defined by the absraction.

I don't follow. Is the contact here the design specification for the system? If so, again, I'd argue that's not an abstraction.

▲

bluegatty 20 hours ago | parent [-]

An abstraction could be a design requirement, expressed in some way.

That's definitely an abstraction.

IDLs are a form of abstraction, they're a requirement somewhat more formally described.

Remember UML? That was an attempt to go 1/2 layer above the code, that was an abstraction.

There were tons of tools like that.

APIs are an abstraction - maybe the best example. We write code to match exactly the behaviour defined by an APU - as long as it meets the requirement of that contract, then 'it's good'. And there could be many ways of doing that.

	▲	beej71 18 hours ago \| parent [-]
		[dead]