Hacker News Reader

Comment by applfanboysbgon | Hacker News Reader

This kills the crab.

Compilation time will be a genuine bottleneck for slop coding if this becomes the standard generation rate over the next few years. Go, Zig or even C99 with TCC for dev builds, any language that can get you systems-level performance (or close to it) in a dev environment where you can iterate in ms rather than minutes is going to be immensely more appealing than generating a potential prototype in 10 seconds and waiting 15 minutes for it to compile.

View on HN

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

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.

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.

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.

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).

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.

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...

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.

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.

I think it's pretty obvious that, in that world, the AIs will simply be tasked with making the compilers faster. It's already happening with their own stack, after all.

Speed is independent of quality. LLMs are currently completely incapable of producing a good compiler. I'm not convinced that's going to change (and if it does change, we're all unemployed).

They don't have produce a good compiler. They just have to take the ones that already exist go much faster. That's likely much easier, and you can validate using existing test suites.

This. Its almost always easier to fix something than to create it from scratch.

Look at the employed person

Reply on news.ycombinator.com