Maybe then LLM's will switch to outputting raw machine code?

▲ Topfi 6 hours ago | parent | next [-]

A great future for us all to look forward to. Human readability gone, any changes must go through a providers API so cost+restrictions are a constant and we'll need far more tokens for even simple operations. Call me old fashioned, still like to understand the code I merge, especially since I've seen Fable and Sol make sometimes utterly egregious mistakes in simple, well scoped requests that erode any trust I can muster...

	▲	vatsachak 5 minutes ago \| parent [-]
		Yeah and sometimes even worse, they do things correctly but in most spaghetti way. I've had to rewrite my whole codebase. It's just the thrill of getting things done quick. Not getting things done right.

▲ applfanboysbgon 6 hours ago | parent | prev | next [-]

No. This conveys a fundamental misunderstanding of how anything pertaining to programming works. This will never happen, ever. For example, take...

  printf("Hello, world");

vs. a plausible illustration of how it might be compiled down to machine code...

  48 65 6C 6C 6F 2C 20 77 6F 72 6C 64
  48 83 EC 28
  48 8D 0D F5 0F 00 00
  E8 F0 00 00 00
  33 C0
  48 83 C4 28
  C3

The latter now takes up 10x as many tokens (= 10x the cost/time, + context penalties), and is now architecture-specific, impossible to apply non-brittle program-wide optimizations to, etc. There is absolutely zero reason to ever have the LLM act as a compiler no matter how fast it is. Even if you believe LLMs will reach a state where they can actually generate good code at this level, you would be better off having them generate the compiler they would use.

▲

evmaki 5 hours ago | parent | next [-]

For what it's worth, this theoretical LLM-based compiler would probably generate LLVM or some other intermediate representation rather than platform-specific machine code.

▲

bakies 6 hours ago | parent | prev [-]

I mean you're right, but what about a different tokenizer and some guardrails... trained on compiled code... I just learned that gpt-5.6 will talk to you in base64 without tool calls so maybe it's possible.

	▲	Topfi 6 hours ago \| parent \| next [-]
		Still, what'd be the advantage? There is a lot, a massive delta, a chasm still to improve before there is even a theoretical potential re. performance. GPT-5.6-Sol still writes JS in inefficient and roundabout ways that leave a lot on the table and even if we got to a point were models provide the highest performance output possible, there are hundreds of languages far more performant before machine code should be considered. Rust, C, Assembly if need be (at which point performance vs binary is, unless I am mistaken, pretty much moot). All machine code would gain us is lock in and no auditability.
	▲	yetihehe 5 hours ago \| parent \| prev [-]
		It's good enough at decoding hex from some packet dumps. And I was doing that even with 5.5. And it was good at decompiling some code (with tools) and searching for offsets of buffers and commands. Found viable exploit that allowed me to rescue broken update system in devices I was maintaining for my company (it was broken by chatgpt forgetting -v in hexdump, heh).

▲ imtringued 5 hours ago | parent | prev [-]

That still requires a specification language to constrain the generated code even if the implementation is produced directly.

Why? Because you are defining the implementation based on its observable behaviour rather than as a rule set to be followed.