Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Is Not a Compiler

blog.exe.dev

Post reply on HN
Print view View original

81–90 of 174 posts

Re: Claude Is Not a Compiler

#81

Post by layer8 »

gritzko wrote: post #55

LLM-is-a-compiler is indeed a simplistic approach. I wrote a rebuttal to the yesterday's Cursor post, may reuse it here https://replicated.live/blog/follow-up The idea that a 835-page spec "just exists" and we run an LLM to implement it is completely flawed. Specs do not appear out of nowhere, they co-evolve with the code. If you have the code, why do you want to generate it again? Good software is made as a product…

The source code always was the result of that distillation, or at least a crucial part of the result. I’m unconvinced that natural-language specs can replace that role. Even long before LLMs, when writing specs I often resort to some form of formal language to precisely nail down certain parts of the specification. And some parts are always left open, where I know I’ll get to them when writing the code, because they are more effectively solved “in the code” than waterfall-like up front.

Re: Claude Is Not a Compiler

#82

Post by davidpapermill »

I've heard something along the lines of "Claude is like a compiler: source code is the new object code, you don't look at that anymore" many times.

And I don't really think this is true. Compilers are usually deterministic, and whilst we can find edge cases, it's nothing like an AI agent writing all the code for you.

I think you have two choices, given the Claude is a code generator and not a compiler: (a) you review most or all of code to make sure it makes sense, or (b) you trust but verify via a strong test suite, potentially also created by Claude.

The problem with (a) is that you lose a lot of the speed-up. The problem with (b) is that you have no human oversight and the code may be incomplete, badly designed, or plain wrong.

Currently we review all code because correctness is extremely important to what we do, but that comes at a cost.

I don't know what the answer is here, in general. Does trust build over time? Do the models just get so good we can trust them to make zero mistakes?

Re: Claude Is Not a Compiler

#83

Post by cobbal »

thomascgalvin wrote: post #35
armchairhacker wrote: post #22

A compiler is an algorithm and Claude isn't*. A compiler almost never produces a wrong output, even when compiling an extremely complicated program. But a compiler must be clearly defined and is limited to input/commands it's defined for. A compiler will "correctly" process input into unintuitive output, but that's not always what the user intended (e.g. omitting large sections of code that are undefined behavior). C…

> A compiler will "correctly" process input into unintuitive output, but that's not always what the user intended Importantly, this behavior is deterministic. If the compiler takes your code and spits out something you did not expect, it will always spit out that same result, given the same input. Once you figure out what went wrong, you've solved that problem. Generative AI is intentionally not deterministic, and th…

Determinism isn't the main hurdle. It would be a moderate effort to engineer a deterministic claude that would be no more useful than the current one.

The key characteristic of a compiler is that it takes a source language with a well-defined meaning to a target language with a well-defined meaning.

The reason claude fails to be a compiler is that its input language (english) can't be precisely defined. (And even if that were possible, it would very often fail to preserve the meaning when "compiling")

Re: Claude Is Not a Compiler

#84

Post by kloud »

gritzko wrote: post #55

LLM-is-a-compiler is indeed a simplistic approach. I wrote a rebuttal to the yesterday's Cursor post, may reuse it here https://replicated.live/blog/follow-up The idea that a 835-page spec "just exists" and we run an LLM to implement it is completely flawed. Specs do not appear out of nowhere, they co-evolve with the code. If you have the code, why do you want to generate it again? Good software is made as a product…

As a counter argument for the compiler perspective: what Cursor did is basically transpiling a project to another language, which is a form of compilation.

If you distill the feedback into a spec (probably a combination of both docs and tests) which comprehensively covers the functional requirements, then you could treat the code as cached materialization. The value of generating code again is targeting different non-functional requirements, like ability to run in different environments or catering to different performance characteristics.

Re: Claude Is Not a Compiler

#85

Post by sarchertech »

js8 wrote: post #75
sarchertech wrote: post #56

Earlier quoted context omitted.

Determinism is the wrong thing to worry about. As you say an LLM could theoretically be deterministic. Chaos (prompt instability) is the problem that isn’t solvable if you want to treat an LLM like a compiler by doing something like checking in the prompts and rebuilding the code each time. In general if you change a single line of source code, a compiler will not produce a completely different program. If you change…

I think you're correct, I'll just point out that compilers are also chaotic today and it is often accepted. A small change to source program can lead to big change in performance. It's especially apparent in high-level and declarative languages - SQL or anything with GC.

With respect to performance that’s true. But I’ve probably spent thousands of hours in my career on performance issues caused by small SQL changes.

And LLM chaos is unimaginably worse. A single white space can result in a program that has zero overlap with the original.

Re: Claude Is Not a Compiler

#87

Post by armchairhacker »

js8 wrote: post #75
sarchertech wrote: post #56

Earlier quoted context omitted.

Determinism is the wrong thing to worry about. As you say an LLM could theoretically be deterministic. Chaos (prompt instability) is the problem that isn’t solvable if you want to treat an LLM like a compiler by doing something like checking in the prompts and rebuilding the code each time. In general if you change a single line of source code, a compiler will not produce a completely different program. If you change…

I think you're correct, I'll just point out that compilers are also chaotic today and it is often accepted. A small change to source program can lead to big change in performance. It's especially apparent in high-level and declarative languages - SQL or anything with GC.

They can guarantee that certain small changes won't create a big change in performance (provably, verified through tests, or trivially). An LLM can't.

Re: Claude Is Not a Compiler

#88

Post by skydhash »

kloud wrote: post #62

Specs might become one solution for coping with the need to review increased volume of code. A spec is a higher level of abstraction than code, which is a higher level of abstraction than machine code. The industry made the transition to higher-level once, paradigm is changing so it might happen again. The workflow I imagine is either deriving specs from the conversation or reverse engineering the code to spec, revie…

> A spec is a higher level of abstraction than code, which is a higher level of abstraction than machine code

No it’s not.

Just like a quick doodle is not an higher level representation of the Mona Lisa. Sure for someones that knows the latter, it can suggest it. Or for someone that doesn’t know it, it may provide some basis of conversation. But it’s not the real thing. You can’t provide a doodle of something and expect an artist that hasn’t seen it to paint it.

Doodling’s value is that it lets you iterate on ideas without the accidental constraints that comes with the implementation (choosing paints, finding references materials, deciding colors,…). Some necessary choices are kept for later, while you decide on the most important ones.

So a spec is useful in designing software, but it’s severely lacking in implementing it. And the decisions made in implementation are as important as the ones made in the design. Even more after a while in production.

Re: Claude Is Not a Compiler

#89

Post by layer8 »

kettlecorn wrote: post #78
armchairhacker wrote: post #22

A compiler is an algorithm and Claude isn't*. A compiler almost never produces a wrong output, even when compiling an extremely complicated program. But a compiler must be clearly defined and is limited to input/commands it's defined for. A compiler will "correctly" process input into unintuitive output, but that's not always what the user intended (e.g. omitting large sections of code that are undefined behavior). C…

If you pair LLMs/AIs like Claude with a formal verification framework you essentially have a new sort of compiler.

That’s technically correct, but it still means that someone has to write the formal specs that Claude’s output is verified against, and someone has to design the formal languages the specs are written in. And once you have formal specs that truly covers all aspects that you ever will care about, it’s unclear if you couldn’t instead build a non-LLM mechanism that efficiently and deterministically spits out an implementation of such a spec.

Re: Claude Is Not a Compiler

#90

Post by all2 »

chubot wrote: post #74
atomicnumber3 wrote: post #70

Earlier quoted context omitted.

Something I have always (even pre-LLMs) found funny to think about is - all code possible to run on a computer already exists. It's some permutation of all the bits of available memory. It's in there somewhere. So, suppose you want a specific program. 1. Some huge % of those possible programs are obviously not the one you want (most don't even compile). 2. Remaining programs might look similar to the one you want, bu…

all code possible to run on a computer already exists. It's some permutation of all the bits of available memory. It's in there somewhere This seems either mathematically impossible or vacuous, depending on what you mean ...

It's the same mindset some artists have when considering raw stone for a statue: there's a Greek god in there somewhere, you just have to find him.

It's a way of thinking, not some deep metaphysical mystery. Unless it is actually a deep metaphysical mystery, but I'd rather not go there.

Post reply on HN