Elon Musk is predicting this will happen by EOY 2026 (but it's Musk so we're doubling the timeline to give him a chance)
"Elon Musk predicts that AI will bypass coding entirely by the end of 2026 - just creates the binary directly AI can create a much more efficient binary than can be done by any compiler So just say, "Create optimized binary for this particular outcome," and you actually bypass even traditional coding Current: Code → Compiler → Binary → Execute Future: Prompt → AI-generated Binary → Execute Grok Code is going to be state-of-the-art in 2–3 months Software development is about to fundamentally change" see https://x.com/XFreeze/status/2021699619927781842
Resolves to YES if AI generally does as Elon Musk predicts - creating binary is more common than creating traditional code - by EOY 2027.
Resolves to NO if this is not the case.
If the answer is unclear, I will defer to a 3-judge panel of the most advanced models from OpenAI, Google and Anthropic, by quoting them the question as worded here and asking how it should be evaluated, providing no other context. I expect this to be necessary in less than 10% of cases.
1,000"EOY 2026" version, since that's what Elon actually predicted: https://manifold.markets/musteval/ai-bypass-coding-entirely-by-eoy-20-h9ytqdgCqP
It seems plausible agents may want to sometimes optimize at the assembly level (maybe if tokens get cheap enough companies will have huge agent swarms carefully inspecting every performance-critical program?) but probably they could just write a code-gen tool or improve a compiler or something when that's needed and it would be much more maintainable and efficient. Maybe a few custom assembly functions / libraries will get written but no way it's "more common than creating traditional code" by 2027
@eapache no, it's just a very inefficient way to produce good binaries. Why would an ai agent "manually" generate the binary when it could write a compiler (or improve an existing one) that does it for a fraction of compute?
We're going to care about token efficiency more than binary code efficiency. Software will be run fewer times on average, with more of it bespoke. Languages that reward efficiency of tokens will matter. I expect that means high level languages. And we're already seeing our first new ones: the plan files Claude Code generates.
Who knows, maybe we can finally benchmark for real whether funky things like Haskell are better than Python for the developer, and see that binary is worse than asm is worse than higher level stuff. It'll all be confounded by training data, but wiring it up to a compiler in training might level the playing field if anyone decides they care.
Maybe we learn that the best languages are the ones with the best error messages, or that can do the best character by character online error checking with fine-grained highlighting. That last is probably not where the bottleneck is, but "best training data from the compiler" might be real in some fashion.
@bens My intuition here is that any performance tricks that AIs can discover will just be integrated into conventional compilers, at which point there's not much reason to have the AI emit binary directly vs writing things in a more token-efficient higher-level language and letting compilers run on cheap CPUs to translate that into machine code.
There's a bit of ambiguity here. Two loopholes I have in mind:
What constitutes a generated binary? Does a .jar count or does it need to be true machine code running directly on the CPU with no interpreter? (If a .jar counts then why shouldn't a .py or .js? There's no hard line separating an interpreter from a virtual machine.)
What counts as "AI" or a "compiler?" Nothing stops me from referring to LLVM as "AI" (this is consistent with historical usage of "AI" as referring to "anything we didn't know how to do last year") or referring to ChatGPT as a "compiler" (it just happens to take natural language as its input language and be nondeterministic).
Assuming neither of those loopholes applies, I'd buy NO at 2%.
@musteval (A third loophole is that you could have a CPU that directly executes JavaScript, lisp-machine-style, but I think it's very unlikely that such CPUs will be widespread by EOY 2027.)