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.
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.
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.
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.