Hacker News Reader

Comment by Silhouette | Hacker News Reader

But you never heard someone say "you should still code in assembly so you can understand what your compiler is doing".

Would I routinely code in assembly today? Not for (almost) any new project.

Can I understand assembly and have I used that skill to understand performance problems or debug unexpected behaviour (including some that really did turn out to be caused by bugs in popular compilers)? Absolutely.

I'm not generally a fan of the comparison between what LLMs do and what compilers do. Compilers might vary in their output for given source code but they still follow (hopefully) well-defined specifications. Their behaviour is deterministic and the behaviour of their output is deterministic. With sufficient understanding you can reason about that output or diagnose faults in the compiler behaviour if you ever need to. None of this is true for LLMs.

View on HN

How does it differ other than that people aren't currently choosing to write clear, well-defined high-level specs and feeding that into their agent?

> Their behaviour is deterministic This isn't true for LLM generated code!

Neither are compilers? But you still trust your JIT compiler. Determinism is unimportant, likelihood of correctness is what matters. Plus agents are deterministic, no?

Was about to point that out. Reproducible builds are possible, but - depending on your stack - not easy to achieve.

Even if we accept your premise that the likelihood of correctness of more important I still don't think that the two scenarios are similar. I have seen more incorrect outputs from LLMs in the past week than I have seen incorrect outputs due to compiler bugs in my entire career. And without determinism there is no way to be sure that ratio will ever change.

I'm not sure. That is also my experience, but I'm not completely sure that isn't my fault and the compiler comparison would be totally valid if I just used the tool better. When I actually write fully fleshed out specifications and have the LLM handle the implementation, I rarely encounter bugs.

I don't think I've seen a Sol 5.6 or later model fail at a task with a verifiable outcome.

It's when I try to do too little of the defining that I get LLM bugs. In which case maybe programming hasn't changed that much, LLMs really can be reliable compilers, and we're all just being lazy.

You can debug a compiler. If an LLM writes code you don't like, how would you debug that? You wouldn't. You'd just ask again and hope it does a better job.

Not 1 in 1000 software engineers has the ability to debug a compiler. And you can absolutely debug agent failures, but similarly almost no does. In both cases for the mast majority of engineers, they are black boxes.

Could you go into more detail about how you'd debug LLM output?

I don't really care about what "most engineers" do. I did phrase it lazily but I am trying to point out something fundamental about LLMs and compilers.

You look at the inputs to the model at the trace level to root cause context construction vs model deficiency. You collect examples of the failure cases, build eval sets, and run ablations. That's black box debugging, but systematic debugging nonetheless.

I mean debugging within the model, not the harness. Harnesses are software like any other.

The model itself is more or less a black box - if tokens come out that you don't like, it seems like there's no equivalent to "this LLVM release fixed a code generation issue on platform X relating to situation Y".

I'm not sure why people are so motivated to say these are the same thing when they are clearly not.

And yes, rigorous approaches can be taken to systems built on and with LLMs, as you say. That doesn't make them the same as compilers.

Why is an LLVM release any different than a frontier model release? Well known, concrete issues get identified, evaluated against, RLVR'd on, and a new release comes out that doesn't have that issue. Or you can do that process yourself on an open-source model if you have the resources.

LLMs are not magic things that are out of your control, they are simply complicated. But there are concrete issues that are identified, people sit down and decide to fix it, build evals, run ablations, and they produce a model without that deficiency. It happens every day.

Would you reject the characterisation of model weights as a black box then?

I suppose if LLVM's source code has a similar size in bytes then it would be similarly difficult to work with. However, it would still remain source code readable by a human, not binary data with no semantic content when examined plainly.

Because coding agents are not idea compilers, they are idea upscalers.

https://www.linkedin.com/pulse/coding-agents-idea-compilers-...

Reply on news.ycombinator.com