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.