While I might agree with your standpoint, how is this different from also influencing?

I've seen a lot of influencers suggest "100% assembly", "JavaScript only", "no SQL", which seem quite similar.

Technically yes, and I've caught myself in a bit of a paradoxal conundrum :)

Think there is a curve of "reason" to apply when someone is advocating something like this, especially about technology and abstractions.

While in most places adding abstractions to core technology makes sense since "it makes it easier to use/manage/deploy" and it is reasonable to use it, LLM's are a quite different case than usual.

Because usually going downstream makes it harder (i.e. going 100% assembly or 100% JS is a harder thing), but going 100% pure LLM is an easier thing - you don't have to learn new frameworks, no need to learn new abstractions, it is shareable, easy to manage and readable by everyone.

In this case, going upstream is what makes it harder, turns it into code management, makes it harder to reason about and adds inevitable complexity.

If you add a new person on your team and they see that you are using 100% assembly, they have to onboard to it, learn how it works, learn why this was done this way etc etc.

If you add a new person to your team and you see that they are using all these tools and abstractions on top of LLMs its the same.

But if you are just using the core tech, they can immediately understand what is going on. No wrapped prompts, magic symbols, weird abstractions - "oh this is an agent but this is a chain while this is a retriever which is also an agent but it can only be chained to a non-retriever that uses UTCP to call it".

So as always, it is subjective and any advocacy needs to be applied to a curve of reason - in the end, does it make sense?