The library is two text files (code) that are processed by an LLM (interpreter) to generate code of another type. This is not that new in terms of workflow.
I think what makes this the worst is the fact that the author admits that you can’t be sure the library will work until you generate the code and test it. Even then you cannot guarantee the security of the generated code and as you do not understand the code you also cannot give support or patch it.
I’ve tried explaining how LLMs are not equatable to compilers/interpreters in the past, and it’s usually to people who aren’t in software roles. What it usually comes down to when I try to explain it is determinism. A compiler or interpreter deterministically produces code with some kind of behavior (defined by the source code). They often are developed to a spec, and the output doing the wrong thing is a bug. LLMs producing the wrong output is a feature. It’s not something you try to fix, and something you often can’t fix.
This, of course, ignores a lot of “lower level” optimizations someone can make about specific algorithms or data structures. I use “lower level” in quotes, of course, because those are some of the most important decisions you can make while writing code, but turning off your brain and letting a LLM do it for you “abstracts” those decisions away to a random number generator.


I’m not following. Which part of this is nondeterministic?
The language being complicated to write and the compiler being confusing to use isn’t an indicator of determinism. If GCC were truly nondeterministic, that’d be a pretty major bug.
Also, note that I mentioned that the output behavior is deterministic. I’m not referring to reproducible builds, just that it always produces code that does what the source specifies (in this case according to a spec).