Modern search engines and LLMs have no trouble distinguishing between different things with the same name. Google Trends will even show you something is a product, a service, a book, whatever. If you ask a LLM "what is this tofu infrastructure as code tool I keep hearing about?" it will 100% tell you about the tool and not the food.

nothing is 100% with LLMs

Search is also struggling more and more each day to surface the actually relevant results. It's part of why people are reaching to LLMs for things they used to search.

> go straight to the APIs for definitions

Do you really think no-one has tried that?

The API definitions (even the good ones, like Azure) do not contain sufficient information to be able to build a declarative tool. Google seem to view their internal annotations about what is mutable or not as some kind of competitive advantage (bizarre). The AWS API is wildly poorly specified for building anything except 1-1 API wrappers. (Cloud Control improves it, but covers few important resources).

Everything has gaps that need to be filled, the main point is that the object I send is the same shape and schema as the API, same for their responses and the data in the system.

TF under the hood is using these APIs through an abstraction. I say "go to the APIs" as (1) bypassing abstractions (2) in CUE, we can import the existing TF resource schemas from the Go types, or from the OpenAPI schemas. There are 2 camps in CUE about how to approach the CUE/TF/Helm/k8s intersection (one for each way)

CUE actually offers a really great space to enrich the APIs with the needed information.

CUE or any other configuration language is orthogonal to whether or not a meaningful declarative provider (whether TF, Pulumi or anything else!) can be generated from a cloud provider API specification.

The only cloud that offers a really declarative API at all is Azure, via Resource Manager.

For AWS, since most APIs are request-response focused (AttachENI, DetachVolume and so forth), something has to tie all that together to make a resource-focused API.

> CUE or any other configuration language is orthogonal to whether or not a meaningful declarative provider

100% agreement

What CUE potentially makes great is going from what the API spec has available to what we need by keeping the enrichments by us in the same space, so we merge or unify into a single space, without having to write code in the imperative sense. You get to stay in a logical space that will ensure what you write remains self consistent. It will catch the gaps and issues earlier.

I'm not aware of any config language or other technology that looks to make this processes as good as CUE can, except maybe sprinkling some of that magic LLM dust on the problem too, which CUE will help in double checking as well