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

51–60 of 174 posts

Re: Claude Is Not a Compiler

#51

Post by qudat »

> I’d say that, in all the ways that matter, I understand the code. Sure, if I had to hand-edit it now, there’d be a serious learning curve. But I won't have to.

Famous last words, but point is taken.

The non deterministic nature of an llm breaks the metaphor that they are like a compiler.

However, it’s not foreign to compilers to receive feedback from the running program (PGOs), so there are still parallels to the feedback we provide LLMs that guide their “optimization”.

I think even calling LLMs a non-deterministic compiler isn’t accurate either so ultimately I agree the metaphor doesn’t quite work.

I do think LLMs are like compilers in terms of how they changed how we build programs from a historical context. But that’s about it.

Re: Claude Is Not a Compiler

#52

Post by trjordan »

> Claude wasn’t just a compiler here. I never handed off a task and let an agent make a bunch of decisions in order to reduce it to practice.

> I’d say that, in all the ways that matter, I understand the code.

I think the dissonance here is really important, and not a bad thing at all. A lot of the decision _were_ handed off the the AI, but they weren't the decisions the author cared about. This is a big selling point of AI! If something is doable with a computer, it’ll figure it out. 30 minutes and 200m tokens later, it’ll take any idea and declare “the feature is fully implemented.”

The hard part is figuring out where to inject that friction, so you can see where it's making decisions for you that matter. The author approached this by incrementally building the thing, reviewing and poking and prodding at every step. A week of attention following a bunch of design discussions is fast, but that's still not trivially cheap.

I want to see us talk more about the decision exhaust of agents, because the better the models get, the more decisions we'll want them to make.

I wrote a bit more here: https://tern.sh/blog/compiler-never-says-no/

Re: Claude Is Not a Compiler

#53

Post by indigodaddy »

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…

“Generative AI is intentionally not deterministic, and that means you're going to solve the same issues -- hallucinations, primarily -- over and over again.”

I see it differently. Sure there are still some hallucinations (but less and less as we progress on), but I see the AI-is-not-deterministic characteristic as a good thing, in the same way that humans and human designers not being deterministic is a good thing. Imagine giving a project/task to a human, and it was completed exactly in the same way with exactly the same outputs as another human that the project was tasked to. Would that be better than each human having varying outcomes of the project? I think most would agree the answer is no.

Re: Claude Is Not a Compiler

#54

Post by varenc »

eigencoder wrote: post #6

I really like what exe.dev is doing. And their philosophy of how cloud services could work is amazing. I have a monthly subscription and it's really cool to just vibe code a little website with Shelley and have it running in minutes. I feel like I have so much fun using their service, and spend so much less time thinking about what things will cost, or what cloud service to use. It's just so much simpler and the fric…

Agreed. Big love for exe.dev. For quick low stakes projects, using their Shelly assistant is the simplest way to give an LLM a fully persistent VM with web services I've found.

Re: Claude Is Not a Compiler

#55

Post by gritzko »

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 of numerous feedback loops and LLMs let you operate those loops faster. They do not supplement the entire process though.

In the end, a good product is a barrel of distilled feedback.

Re: Claude Is Not a Compiler

#56

Post by sarchertech »

armchairhacker wrote: post #47
thomascgalvin wrote: post #35

Earlier quoted context omitted.

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

AI could be deterministic, only it requires sacrificing performance and nobody cares enough. Although algorithms are more predictable , and you can follow an algorithm's steps (even a complex algorithm can be broken into large sequences of steps, which may be broken further).

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 a single word in a prompt, you will get output that likely doesn’t match a single line of the original output.

Chaos is what leads to unpredictability, and there’s no solution to this on the horizon.

Re: Claude Is Not a Compiler

#57

Post by doug_durham »

couchand wrote: post #5

The argument being made here is really incredible when you unpack it. 1) The construction of the Empire State Building was particularly effective due to the depth of human-to-human collaboration. 2) Isn't it great that we can burn a bunch of dinosaur blood to convince ourselves that we don't need other humans?

The whole resource argument against AI is quickly becoming obsolete. Time to move on to a new argument.

Re: Claude Is Not a Compiler

#58

Post by luckydata »

couchand wrote: post #5

The argument being made here is really incredible when you unpack it. 1) The construction of the Empire State Building was particularly effective due to the depth of human-to-human collaboration. 2) Isn't it great that we can burn a bunch of dinosaur blood to convince ourselves that we don't need other humans?

not in any way that matters, no. this is a strawman and a really bad one too.

Re: Claude Is Not a Compiler

#60

Post by dataviz1000 »

Claude is more like a Probabilistic Turing Machine. [0] It's correctness isn't deterministic but rather a distribution. It is predictable.

There are lots of places in computer science that determinism isn't necessarily the best.

- UDP video calls let packets vanish or arrive corrupted, because waiting for retransmissions would freeze the picture.

- Stochastic gradient descent picks a random mini-batch of training data and treats it as the whole dataset, because computing the true gradient on every step would make training infeasible.

- Speculative execution in modern CPUs guesses which branch a program will take and rolls back when wrong, because waiting for the real answer would leave half the silicon idle.

What we want is something like a Las Vegas algorithm, a probabilistic machine with a cheap verifier.

[0] https://en.wikipedia.org/wiki/Probabilistic_Turing_machine

Post reply on HN