Considering it just pulls and remixes blocks, this is a very tall order for today's LLMs, and maybe a couple of generations as well.
Calling GCC/clang at the back and emitting ASM is both cheating and has no advantages whatsoever as well.
This isn't futurology, besides a few projects that already came up on Phoronix and around here, with Assembly generation, there are enough SIGPLAN papers on ML driven compilers already.
However, starting with LLMs directly generating machine code and moving to ML directed optimization passes, you're moving the whole stadium with a crawler-transporter, not only the goalposts.
Helping compiler in a well defined way, and working on IR or driving it repeatedly to optimize the output is one thing, generating machine code from a training set is other. Let's not mix them.
"Compiler 2.0: Building the Next Generation of Compilers with Machine Learning"
https://eecs.berkeley.edu/research/colloquium/compiler-2-0-b...
There are other researchers if you interest yourself on the matter.
Then the whole iPaaS agentic coding environments like Workato and Boomi, that even if they might generate 3GL as intermediate step, you don't get to see it.
https://github.com/zwang4/awesome-machine-learning-in-compil...
Using small, purpose built ML "things" to make things better makes sense. We use them everywhere. I never argued against it, as well.
If 3 GL code has to be generated, my option list won't certainly have Go on it.
In case you answer there don't fit the same purpose, there are tiny baggers that replace shovels altogether.
This demonstrates that you continue to misunderstand the analogy.
Let's speak plainly. Someone who attempts to use LLMs to generate assembly directly will be outcompeted by someone who uses LLMs to generate code in a high-level language, which then uses an ordinary compiler to generate assembly. The value of a high-level language is that it defines a more constrained abstract machine than the machine that a CPU represents, which both humans and LLMs alike benefit from.
Letting it generate machine code directly would be the opposite of that.
As for proven wrong,
"Frame was created over the past month largely via Claude Code. The Assembly code in all its glory can be found on GitHub."
Binary bloat is not just about size; it impacts startup time and icache. It’s basically the speed of light launch time.
So you’re telling me rust is not good for UNIX style tools.
However it kind of makes me feel like my professional life was wasted and I don't really know what kind of future I have. One of Go's main points was you can pick it up in a weekend. What career moat do people like us have?