I've always been a Kubernetes Maximalist, but recently I've been thinking about the secondary effects of API and technical decisions.
The argument goes, developers don't need to know how to use Kubernetes. Data scientists shouldn't need to know how to build a container.
Both can be true. Infrastructure standardization, but at the same time limited API surface for the end-user.
One interesting example of this is an open-source tool for data analysts called dbt. Don't be thrown off by the relatively small numbers of GitHub stars or issues – this is a widely used tool amongst data analysts – they just aren't always on GitHub.
dbt is successful for many reasons, but the one I find most interesting is that it is mainly a SQL + YAML tool. This reduces the API surface, and most importantly, the skills needed by an end-user drastically. It's much easier to find a data analyst that only knows SQL than it is a data scientist who knows Python or a data engineer who deals with infrastructure.
Configuration, environment setup, and testing could have been done in Python (the language the tool is written in), but instead is done in YAML.
Where else can you intentionally scope the API to tailor it towards a specific kind of technical user?
Bash/Pulumi+YAML for DevOps Engineers / SREs
With some scripting plus YAML, DevOps engineers can orchestrate cloud infrastructure without being fundamental programmers. Still controversial, but if companies can save money by accessing a much larger talent pool, they will. Take a look at this Reddit thread, DevOps becomes "no-code"?
Markup languages (HTML, CSS, Markdown) / JavaScript -> Technical Writers / Frontend Engineer
Harder to see this one play out as most of the markup is moving towards JavaScript rather than away from it (CSS-in-JavaScript, JSX instead of HTML), but this might be a better abstraction for no-code website builders than learning new paradigms.
In fact, you might even argue that static site builders (Gatsby, Hugo, etc.) do something like this by having HTML, CSS, and a templating engine like Handlebars.
Templating or configuration files as mechanisms for removing scope. This can be enabling for complicated workflows that might otherwise require multiple skills that are difficult (and expensive) to find in the real world. This is the version of low-code that makes the most sense to me: removing unnecessary "skill sprawl" that's embedded into many of our tools today.