Live data from Hacker News

Human coders are still better than LLMs

antirez.com

121–130 of 762 posts

Re: Human coders are still better than LLMs

#121
post #95

Unrelated to the LLM discussion, but a hash function function is the wrong construction for the accumulator solution. The hashing part increases the probability that A and B have a collision that leads to a false negative here. Instead, you want a random invertible mapping, which guarantees that no two pointers will "hash" to the same value, while distributing the bits. Splitmix64 is a nice one, and I believe the mur…

Any Feistel Network has the property you stated actually, and this was one of the approaches I was thinking using as I can have the seed as part of the non linear transformation of the Feistel Network. However I'm not sure that this actually decreases the probability of A xor B xor C xor D being accidentally zero, bacause the problem with pointers is that they may change only for a small part. When you using hashing…

You can guarantee that the probability is the theoretical minimum with a bijection. I think that would be 2^-N since it's just the case where everything's on a maximum length cycle, but I haven't thought about it hard enough to be completely certain.

A good hash function intentionally won't hit that level, but it should be close enough not to matter with 64 bit pointers. 32 bits is small enough that I'd have concerns at scale.

Re: Human coders are still better than LLMs

#122

The thing everyone forgets when talking about LLMs replacing coders is that there is much more to software engineering than writing code, in fact that's probably one of the smaller aspects of the job. One major aspect of software engineering is social, requirements analysis and figuring out what the customer actually wants, they often don't know. If a human engineer struggles to figure out what a customer wants and a…

Yea, this is why I dont buy the "all developers will disappear". Will I write a lot less code in 5 years (maybe almost none)? Sure, I already type a lot less now than a year ago. But that is just a small part of the process.

No. the scope will just increase to occupy the space left by LLMs. We will never be allowed to retire.

Re: Human coders are still better than LLMs

#123
post #46

Earlier quoted context omitted.

LLMs will still be this way 10 years from now. But IDK if somebody won't create something new that gets better. But there is no reason at all to extrapolate our current AIs into something that solves programing. Whatever constraints that new thing will have will be completely unrelated to the current ones.

Stating this without any arguments is not very convincing. Perhaps you remember that language models were completely useless at coding some years ago, and now they can do quite a lot of things, even if they are not perfect. That is progress, and that does give reason to extrapolate. Unless of course you mean something very special with "solving programming".

> Perhaps you remember that language models were completely useless at coding some years ago

no i don't remember that. They are doing similar things now that they did 3 yrs ago. They were still a decent rubber duck 3 yrs ago.

Re: Human coders are still better than LLMs

#124
post #55

Earlier quoted context omitted.

That was also one of the challenges during the offshoring craze in the 00s. The offshore teams did not have the power, or knowledge to push back on things and just built and built and built. Sounds very similar to AI right? Probably going to have the same outcome.

The difference is that when AI exhibits behavior like that, you can refine the AI or add more AI layers to correct it. For example, you might create a supervisor AI that evaluates when more requirements are needed before continuing to build, and a code review AI that triggers refinements automatically.

Question is, how autonomous decision making works, nobody argues that llm can finish any sentence, but can it push a red button?

Re: Human coders are still better than LLMs

#125

“Better” is always task-dependent. LLMs are already far better than me (and most devs I’d imagine) at rote things like getting CSS syntax right for a desired effect, or remembering the right way to invoke a popular library (e.g. fetch) These little side quests used to eat a lot of my time and I’m happy to have a tool that can do these almost instantly.

I have found it to be good at things I am not very strong at (SQL) but terrible at the things I know well (CSS).

Telling, isn't it?

Re: Human coders are still better than LLMs

#126
post #94

Earlier quoted context omitted.

Why state the same arguments everybody has been repeating for ages? LLMs can only give you code that somebody has wrote before. This is inherent. This is useful for a bunch of stuff, but that bunch won't change if OpenAI decides to spend the GDP of Germany training one instead of Costa Rica.

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.

> how much of coding is really never done before?

A lot because we use libraries for 'done frequently before' code. i don't generate a database driver for my webapp with llm.

Re: Human coders are still better than LLMs

#127
post #72

Earlier quoted context omitted.

It's a damning assertive duck, completely out of proportion to its competence. I've seen enough people led astray by talking to it.

I would argue that they are never led astray by chatting, but rather by accepting the projection of their own prompt passed through the model as some kind of truth. When talking with reasonable people, they have an intuition of what you want even if you don't say it, because there is a lot of non-verbal context. LLMs lack the ability to understand the person, but behave as if they had it.

Most of the times, people are led astray by following average advice on exceptional circumstances.

People with a minimum amount of expertise stop asking for advice for average circumstances very quickly.

Re: Human coders are still better than LLMs

#128

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…

Yet you are working on your own replacement, while your colleagues are taking the prudent approach.

Ahh, the “don’t disturb the status quo” argument. See, we are all working on our replacement, newer versions, products, services and knowledge always make the older obsolete. It is wise to work on your replacement, and even wiser to be in charge of and operate the replacement.

Re: Human coders are still better than LLMs

#130
post #46

Earlier quoted context omitted.

Stating this without any arguments is not very convincing. Perhaps you remember that language models were completely useless at coding some years ago, and now they can do quite a lot of things, even if they are not perfect. That is progress, and that does give reason to extrapolate. Unless of course you mean something very special with "solving programming".

Why state the same arguments everybody has been repeating for ages? LLMs can only give you code that somebody has wrote before. This is inherent. This is useful for a bunch of stuff, but that bunch won't change if OpenAI decides to spend the GDP of Germany training one instead of Costa Rica.

Generating unseen code is not hard.

Set rules on what’s valid, which most languages already do; omit generation of known code; generate everything else

The computer does the work, programmers don’t have to think it up.

A typed language example to explain; generate valid func sigs

func f(int1, int2) return int{}

If that’s our only func sig in our starting set then it makes it obvious

Well relative to our tiny starter set func f(int1, int2, int3) return int{} is novel

This Redis post is about fixing a prior decision of a random programmer. A linguistics decision.

That’s why LLMs seem worse than programmers because we make linguistics decisions that fit social idioms.

If we just want to generate all the never before seen in this model code we don’t need a programmer. If we need to abide laws of a flexible language nature, that’s what a programmer is for; compose not just code by compliance with ground truth.

That antirez is good at Redis is a bias since he has context unseen by the LLM. Curious how well antirez would do with an entirely machine generated Redis-clone that was merely guided by experts. Would his intuition for Redis’ implementation be useful to a completely unknown implementation?

He’d make a lot of newb errors and need mentorship, I’m guessing.

Post reply on HN