Hacker News Reader

Comment by tux1968 | Hacker News Reader

tux1968

It seems like you're doing a lot of work to miss the actual point. Focusing on the minutiae of the analogy is a distraction from the over arching and obvious point. It has nothing to do with how you feel, it has to do with how you will compete in a world with others who feel differently.

There were carpenters who refused to use power tools, some still do. They are probably happy -- and that's great, all the power to them. But they're statistically irrelevant, just as artisanal hand-crafted computer coding will be. There was a time when coders rejected high level languages, because the only way they felt good about their code is if they handcrafted the binary codes, and keyed them directly into the computer without an assembler. Times change.

View on HN

In my opinion, it is far too early to claim that developers developing like it was maybe three years ago are statistically irrelevant. Microsoft has gone in on AI tooling in a big way and they just nominated a "software quality czar".

I used the future tense. Maybe it will be one hundred years from now, who knows; but the main point still stands. It would just be nice to move the conversation beyond "but I enjoy coding!".

I don’t think it’s correct to claim that AI generated code is just next level of abstraction.

All previously mentioned levels produce deterministic results. Same input, same output.

AI-generation is not deterministic. It’s not even predictable. And example of big software companies clearly show what mass adoption of AI tools will look like in terms of software quality. I dread if using AI will ever be an expectation, this will be level of enshittification never before imagined.

You're not wrong. But your same objection was made against compilers. That they are opaque, have differences from one to another, and can introduce bugs, they're not actually deterministic if you upgrade the compiler, etc. They separate the programmer from the code the computer eventually executes.

In any case, clinging to the fact that this technology is different in some ways, continues to ignore the many ways it's exactly the same. People continue to cling to what they know, and find ways to argue against what's new. But the writing is plainly on the wall, regardless of how much we struggle to emotionally separate ourselves from it.

They may not be wrong per se but that argument is essentially a strawman argument.

If these tools are non-deterministic then how did someone at Anthropic spend the equivalent of $20,000 of Anthropic compute and end up with a C compiler that can compile the Linux kernel (one of the largest bodies of C code out there).

There is clearly something that completely missies the point about the but-muh-non-determinism argument. See my direct response: https://news.ycombinator.com/item?id=46936586

You'll notice this objection comes up each time a "OpenClaw changed my life" or conversely "Agentic Coding ain't it fam" article swings by.

To be frank, the C compilers source code were probably multiply times in its learning material, it just had to translate to Rust.

This aside, one success story doesn’t mean much, doesn’t even touch determinism question. Anthropic with every ad like this should have posted all the prompts they used.

People on here keep trotting out this "AI-generation is not deterministic." (more properly speaking, non-deterministic) argument on here …

And my retort to you (and them) is, "Oh yeah, and so?"

What about me asking Claude Code to generate a factorial function in C or Python or Rust or insert-your-language-of-choice-here is non-deterministic?

If you're referring to the fact that for a given input LLMs (or whatever) because of certain controls (temperature controls?) don't give the same outputs for the same inputs. Yeah, okay. If we're talking about conversational language that makes a meaningful difference to whether it sounds like an ELISA robots or more like a human. But ask an LLM to output some code then that code has to adhere to functional requirements independent of, muh, non-determinism. And what's to stop you (if you're so sceptical/scared) writing test-cases to make sure the code that is magically whisked out of nowhere performs as you so desire? Nothing. What's to stop you getting one agent to write the test-suite (and for you to review to the test-suite for correctness and for another agent to the write the code and self-correct based off of checking its code against the test-suite? Nothing

I would advise anyone encountering this but-they're-non-deterministic argument on HN to really think through what the proponents of this argument are implying. I mean, aren't humans non-deterministic. (I should have thought so.) So how is it, <extra sarcasm mode activated>pray tell</extra sarcasm mode activated> humans manage to write correct software in the first place?

I personally have jested many times I picked my career because the logical soundness of programming is comforting to me. A one is always a one; you don’t measure it and find it off by some error; you can’t measure it a second time and get a different value.

I’ve also said code is prose for me.

I am not some autistic programmer either, even if these statements out of context make me sound like one.

The non-determinism has nothing to do with temperature; it has everything to do with that fact that even at temp equal to zero, a single meaningless change can produce a different result. It has to do with there being no way to predict what will happen when you run the model on your prompt.

Coding with LLMs is not the same job. How could it be the same to write a mathematical proof compared to asking an LLM to generate that proof for you? These are different tasks that use different parts of the brain.

> A one is always a one; you don’t measure it and find it off by some error; you can’t measure it a second time and get a different value.

Linus Torvalds famously only uses ECC memory in his dev machines. Why? Because every now and again either a cosmic ray or some electronic glitch will flip a bit from a zero to a one or from a one to a zero in his RAM. So no, a one is not always a one. A zero is not always a zero. In fact, you can measure it and find it off by some error. You can measure it a second time and get a different value. And because of this ever-so-slight glitchiness we invented ECC memory. Error correction codes are a thing because of this fundamental glitchiness. https://en.wikipedia.org/wiki/ECC_memory

We understand when and how things can go wrong and we correct for that. Same goes for LLMs. In fact I would go so far as to say that someone doesn't even really think like how a software/hardware engineer ought to think if this is not nearly immediately obvious.

Besides the but-they're-not-deterministic crowd there's also the oh-you-find-coding-painful-do-you crowd. Both are engaging in this sort of real men write code with their bare hands nonsense -- if that were the case then why aren't we still flipping bits using toggle switches? We automate stuff, do we not? How is this not a step-change in automation? For the first time in my life my ideas aren't constrained by how much code I can manually crank out and it's liberating. It's not like when I ask my coding agent to provide me with a factorial function in Haskell it draws a tomato. It will, statistically speaking, give me a factorial function in Haskell. Even if I have never written a line of Haskell in my life. That's astounding. I can now write in Haskell if I want. Or Rust. Or you-name-it.

Aren't there projects you wanted to embark on but the sheer amount of time you'd need just to crank out the code prevented you from even taking the first step? Now you can! Do you ever go back to a project and spend hours re-familiarising yourself with your own code. Now it's a two minute "what was I doing here?" away from you.

> The non-determinism has nothing to do with temperature; it has everything to do with that fact that even at temp equal to zero, a single meaningless change can produce a different result. It has to do with there being no way to predict what will happen when you run the model on your prompt.

I never meant to imply that the only factor involved was temperature. For our purposes this is a pedantic correction.

> Coding with LLMs is not the same job. How could it be the same to write a mathematical proof compared to asking an LLM to generate that proof for you?

Correct, it's not the same. Nobody is arguing that it's the same. And it's wrong that it's different, it's just different that it's different.

> These are different tasks that use different parts of the brain.

Yes. And so what's your point?

You’re making quite long and angry sounding comments.

If you’re making code in language you don’t know, then this code is as good as a magical black box. It will never be properly supported, it’s a dead code in the project that may do what it says it does or may not (a 100%).

I think you should refrain from replying to me until you're able to respond to the actual points of my counter-arguments to you -- and until you are able to do so I'm going to operate under the assumption that you have no valid or useful response.

> That's astounding. I can now write in Haskell if I want. Or Rust. Or you-name-it.

You're responsible for what you ship using it. If you don't know what you're reading, especially if it's a language like C or Rust, be careful shipping that code to production. Your work colleague might get annoyed with you if you ask them to review too many PRs with the subtle, hard-to-detect kind of errors that LLMs generate. They will probably get mad if you submit useless security reports like the ones that flood bug bounty boards. Be wary.

IMO the only way to avoid these problems is expertise and that comes from experience and learning. There's only one way to do that and there's no royal road or shortcut.

Non-determinism means here that with same inputs, same prompts we are not guaranteed the same results.

This turns writing code this way into a tedious procedure that may not even work exactly the same way every time.

You should ask yourself, too: if you already have to spend so much time to prepare various tests (can’t trust LLM to make them, or have to describe it so many details), so much time describing what you need, then hand holding the model, all to get mediocre code that you may not be able to reproduce with the same model tomorrow - what’s the point?

No one is using Gen AI to determine if a number is odd at runtime - they are testing the deterministic code that it generates

I don't think he's missing the point at all. A band saw is an immutable object with a fixed, deterministic capability--in other words, a tool. An LLM is a slot machine. You can pull keep pulling the lever, but you'll get different results every time. A slot machine is technically a machine that can produce money, but nobody would ever say it's a tool for producing money.

People keep trotting this argument out. But a band saw is not deterministic either, it can snap in the middle of a cut and destroy what you're working on. The point is, we only treat it like it's deterministic, because most of the time it's reliable enough that it just does what we want. AI technology will definitely get to the same level eventually. Clinging on to the fact that it isn't yet at that level today, is just cope, not a principled argument.

I feel like we're both in similar minds of opposite sides, so perhaps you can answer me this: How is a deterministic AI any different from a search engine?

In other words, if you and me always get the same results back for the same prompt (definition of determinism,) isn't that just really, really power hungry Google?

I'm not sure pure determinism is actually a desirable goal. I mean, if you ask the best programmer in the world the same question every day, you're likely to eventually get a new answer at some point. But if you ask him, or I ask him, hopefully he gives the same good answer, to us both. In any case, he's not just a power hungry Google, because he can contextualize our question, and understand us when we ask in very obscured ways; maybe without us even understanding what we're actually looking for.

So instead of determinism being a binary you consider it a binomial distribution with p extremely close but not strictly equal to 1.

I think this is a distinction without a difference, we all know what we mean when way say deterministic here.

I think the distinction without a difference is a tool being deterministic or not. Fundamentally, its nature doesn't matter, if in actual practice it outperforms everything else.

Be that as it may, moving the goalpost aside. For me personally this fundamentally does matter. Programming is about giving instructions for a machine (or something mechanical) to follow. It matters a great deal to me that the machine reliably follows the instructions I give it. And compiler authors of the past have gone to great lengths to make their compilers produce robust (meaning deterministic) output, as have language authors tried to make their standards as rigorous (meaning minimize undefined behavior) as possible.

And for that matter, going back to the band saw analogy, a measure of a quality of a great band saw is, in fact, that the blade won’t snap in half in the middle of a cut. If a band saw manufacturer produces a band saw with a really low binomial p-value (meaning it is less deterministic/more stochastic) that is a pretty lousy band saw, and good carpenters will know to stay away from that brand of band saws.

To me this paints a picture of a distinction that does indeed have a difference. A pretty important difference for that matter.

There’s a theory of neural networks that states:

For every real valued function and every epsilon greater than zero, there’s a neural network (size unbounded) which approximates the function with precision epsilon.

It sounds impressive and, as I understand it, is the basis for the argument that algorithms based on NN’s such as LLM’s will be able to put perform humans at tasks such as programming.

But this theorem contains an ambiguous term that makes it less impressive when you remove it.

Which for me, makes such tools… interesting I guess for some applications but it’s not nearly as impressive as to remove the need for programmers or to replace their labour entirely with automation that we need to concern ourselves with writing markdown files and wasting tokens asking the algorithm to try again.

So this whole argument that, “you better learn to use them or be displaced in the labour market,” is a relying on a weak argument.

Reply on news.ycombinator.com