Live data from Hacker News

Human coders are still better than LLMs

antirez.com

641–650 of 762 posts

Re: Human coders are still better than LLMs

#641
post #618

Earlier quoted context omitted.

This doesn't surprise me, i find LLM's are really good at interpolating and translating. so if i made up a language and gave it the rules and asked it to translate i wouldn't expect it to be bad at it.

It shouldn't surprise anyone, but it is clear evidence against the claim I replied to, and clearly a lot of people still hold on to this irrational assumption that they can't produce anything new.

They're not producing anything new... If you give it the answer before asking the question, no wonder it can answer. Prompting is to find resonance in the patterns extracted from the training data, which is why it fails spectacularly for exotic programming languages.

Re: Human coders are still better than LLMs

#642
post #219

Earlier quoted context omitted.

It's trivial to demonstrate that it takes only a tiny LLM + a loop to a have a Turing complete system. The extension of that is that it is utterly crazy to think that the fact it is "a model designed to predict sequences of tokens" puts much of a limitation on what an LLM can achieve - any Turing complete system can by definition simulate any other. To the extent LLMs are limited, they are limited by training and com…

Language models with a loop absolutely aren't Turing complete. Assuming the model can even follow your instructions the output is probabilistic so in the limit you can guarantee failure. In reality though there are lots of instructions LLMs fail to follow. You don't notice it as much when you're using them normally but if you want to talk about computation you'll run into trivial failures all the time. The last time…

> Language models with a loop absolutely aren't Turing complete.

They absolutely are. It's trivial to test and verify that you can tell one to act as a suitably small Turing machine and give it instructions to use to manipulate the conversation as "the tape".

Anything else would be absolutely astounding given how simple it is to implement a minimal 2-state 3-symbol Turing machine.

> Assuming the model can even follow your instructions the output is probabilistic so in the limit you can guarantee failure.

The output is deterministic if you set the temperature to zero, at which point it is absolutely trivial to verify the correct output for each of the possible states of a minimal Turing machine.

Re: Human coders are still better than LLMs

#643
post #212
post #94

Earlier quoted context omitted.

First, how much of coding is really never done before? And secondly, what you say are false (at least if taken literally). I can create a new programming language, give the definition of it in the prompt, ask it to code something in my language, and expect something out. It might even work.

> I can create a new programming language, give the definition of it in the prompt, ask it to code something in my language, and expect something out. It might even work. I literally just pointed out the same time without having seen your comment. Second this. I've done this several times, and it can handle it well. Already GPT3.5 could easily reason about hypothetical languages given a grammar or a loose description…

If you give it the rules to generate something, why can't it generate it? That's what something like Mockaroo[0] does. It's just more formal. That's pretty much what LLM training does, extracting patterns from a huge corpus of text. Then it goes one to generate according to the patterns. It can not generate a new pattern that is not a combination of the previous one.

[0]: https://mockaroo.com/

Re: Human coders are still better than LLMs

#644
post #618

Earlier quoted context omitted.

It shouldn't surprise anyone, but it is clear evidence against the claim I replied to, and clearly a lot of people still hold on to this irrational assumption that they can't produce anything new.

They're not producing anything new... If you give it the answer before asking the question, no wonder it can answer. Prompting is to find resonance in the patterns extracted from the training data, which is why it fails spectacularly for exotic programming languages.

When you invent a language and tell it express something in that language, you've not given it the answer before asking the question.

That's an utterly bizarre notion. The answer in question never existed before.

By your definition humans never produce anything new either, because we always also extrapolate on patterns from our previous knowledge.

> it fails spectacularly for exotic programming languages.

My experience is that it not just succeeds for "exotic" languages, but for languages that didn't exist prior to the prompt.

In other words, they can code at least simple programs even with zero-shot by explaining semantics of a language without giving them even a single example of programs in that language.

Did you even read the comment you replied to above?

To quote myself: "Invent a programming language that does not exist."

I've had this work both for "from scratch" descriptions of languages by providing grammars, and for "combine feature A from language X, and feature B from language Y". In the latter case you might have at least an argument. In the former case you do not.

Most humans struggle with tasks like this - you're setting a bar for LLMs most humans would fail to meet.

Re: Human coders are still better than LLMs

#645

Earlier quoted context omitted.

> the conversational interface, for some reason, seems to turn off the natural skepticism that people have n=1 but after having chatgpt "lie" to me more than once i am very skeptical of it and always double check it, whereas something like tv or yt videos i still find myself being click-baited or grifted (iow less skeptical) much more easily still... any large studies about this would be very interesting...

I get irrationally frustrated when ChatGPT hallucinates npm packages / libraries that simply do not exist. This happens… weekly for me.

tell it that you won’t accept any new installed packages, use language features only. i have that in my coding prompt i made.

Re: Human coders are still better than LLMs

#646
post #131

Earlier quoted context omitted.

We use libraries for SOME of the 'done frequently' code. But how much of enterprise programming is 'get some data from a database, show it on a Web page (or gui), store some data in the database', with variants? It makes sense that we have libraries for abstraction away some common things. But it also makes sense that we can't abstract away everything we do multiple times, because at some point it just becomes so abs…

> we can't abstract away everything we do multiple times I think there's a fundamental truth about any code that's written which is that it exists on some level of specificity, or to put it in other words, a set of decisions have been made about _how_ something should work (in the space of what _could_ work) while some decisions have been left open to the user. Every library that is used is essentially this. Database…

> Once you get to the question of _which specific data is shown on a page_ the decisions are closer to the human side of how we've arbitrarily chosen to organise things in this specific thousandth-iteration of an e-commerce application.

That's why communication is so important, because the requirements are the primary decision factors. A secondary factors is prior technical decisions.

Re: Human coders are still better than LLMs

#647
post #621

Earlier quoted context omitted.

> And there won't be a point when human curated reward models are not needed anymore. This doesn't follow at all. There's no reason why a model can not be made to produce reward models.

But reward models are always curated by humans. If you generate a reward model with an LLM, it will contain hallucinations that need to be corrected by humans. But that is what a reward model is for. To correct the hallucinations of LLMs. So yeah theoretically you could generate reward models with LLMs, but they won't be any good, unless they are curated by other reward models that are ultimately curated by humans.

> But reward models are always curated by humans.

There is no inherent reason why they need to be.

> So yeah theoretically you could generate reward models with LLMs, but they won't be any good, unless they are curated by other reward models that are ultimately curated by humans.

This reasoning is begging the question: The reasoning is true only if the conclusion is true. It's therefore a logically invalid argument.

There is no inherent reason why this needs to be the case.

Re: Human coders are still better than LLMs

#648

In many cases developers are a low expectation commodity. In those cases I strongly believe humans are entirely replaceable by AI and I am saying that as somebody with an exceptionally low opinion of LLMs. Honestly though, when that replacement comes there is no sympathy to be had. Many developers have brought this upon themselves. For roughly the 25 year period from 1995 to 2020 businesses have been trying to turn d…

But to job hop every 2 years is the best strategy to earn more money and experience.

Re: Human coders are still better than LLMs

#649

Human coders are necessary because writing code is a political act of deciding between different trade-offs. antirez's whole post is explaining to Gemini what the trade-offs even were in the first place. No analysis of a codebase in isolation (i.e. without talking to the original coders, and without comments in the code) can distinguish between intentional prioritization of certain trade-offs or whether behavior is u…

> LLMs will never be able to figure out for themselves what your project's politics are and what trade-offs are supposed to be made. I wouldn't declare that unsolvable. The intentions of a project and how they fit into user needs can be largely inferred from the code and associated docs/README, combined with good world knowledge. If you're shown a codebase of a GPU kernel for ML, then as a human you instantly know th…

> associated docs/README

Many (I would even argue most) professional codebases either do not have their documentation (including tutorials and architecture diagrams) in the codebase alongside the code, if there is even such formal documentation at all. It's axiomatic as well that documentation is frequently out-of-date, and in any case represents past political decisions, not future ones; human owners can and do change their minds about which trade-offs are required over the lifetime of a project.

A simple case may be to plot codebase complexity against required scale; early projects benefit from simpler implementations that will not scale, and only after usage and demand are proven does it make sense to make the project more complex in order to support additional scale. So if you are an LLM looking at a codebase in isolation, do you make changes to add complexity to support additional scale? Do you simplify the codebase? Do you completely rewrite it in a different language (say, TypeScript -> Go or Rust)? How could an LLM possibly know which of these are appropriate without additional sources of telemetry at the very least and probably also needing to converse with stakeholders (i.e. bordering on AGI)?

Re: Human coders are still better than LLMs

#650
post #248

There's some whistling past the graveyard in these comments. "You still need humans for the social element...", "LLMs are bad at debugging", "LLMs lead you astray". And yeah, there's lots of truth in those assertions, but since I started playing with LLMs to generate code a couple of years ago they've made huge strides. I suspect that over the next couple of years the improvements won't be quite as large (Pareto Prin…

Programmers derided programming languages (too inefficient, too inflexible, too dumbing-down) when assembly was still the default. That phenomenon is at the same time entirely to be expected but also says little about the actual qualities of the new technology.

If you have something that generated 20 lines of assembly that takes 100x times more than the 2 lines of clever instructions you know, you'd have the same stance even if the higher level was easier to use. Then those kind of performance tricks ceases to matter. But reliability still do. And the reasons we use higher and higher level of programming languages is because they increase reliability and simplicity (at the cost of performance, but we're happy to pay those).

LLMs output are unreliable and productivity is still not proven for an end to end engineering cycle.

Post reply on HN