This article is confusing because the author is too close to the problem, and it needs to be explained from an outsider’s point of view before diving into the details. But it looks like the information is there.
It sounds to me like they ended up with an encapsulation layer between language-specific build systems and the continuous build systems that kick them off.
A comparison might be with something like Bazel, which does everything, but full adoption requires going all-in on using their build language to replace language-specific build systems, often including moving source files to make it work. This feels foreign compared to using a language’s own build system, but it might seem natural for C programmers, where the language doesn’t have its own build system. Similarly, Java went through several unfortunate build systems before unfortunately settling on Gradle.
Language-specific build systems end up not doing everything because each language has its own conventions and ecosystem. Modern ones don’t try, they know what they’re good at and stick to it.
So, the tool that actually knows about multiple languages and their artifacts is often a shell script, makefile, docker file, or the continuous build itself. Or even doing it by hand. That’s the layer they’re trying to improve.
I don’t have a clear idea what their fundamental insight is that makes their way of doing it better, though.