Speak for yourself..
Human coders are still better than LLMs
171–180 of 762 posts
Re: Human coders are still better than LLMs
#172There'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.
Carteling doesn't work bottom-up. When changes begin (like this one with AI), one of the things an individual can do is to change course as fast as they can. There are other strategies as well, not evolving is also one, but some strategies yield better results than others. Not keeping up just worsens the chances, I have found.
Re: Human coders are still better than LLMs
#173What do you mean "Still"? We've only had LLMs writing code for 1.5 years... at this rate it won't be long.
More like five years. It's been around for much longer than a lot of people feel it has for some reason.
Re: Human coders are still better than LLMs
#174LLMs will never be better than humans on the basis that LLMs are just a shitty copy of human code.
I think they can be an excellent copy of human code. Are they great at novel out-of-training-distribution tasks? Definitely not, they suck at them. Yet I'd argue that most problems aren't novel, at most they are some recombination of prior problems.
Re: Human coders are still better than LLMs
#175Earlier quoted context omitted.
Yet you are working on your own replacement, while your colleagues are taking the prudent approach.
Carteling doesn't work bottom-up. When changes begin (like this one with AI), one of the things an individual can do is to change course as fast as they can. There are other strategies as well, not evolving is also one, but some strategies yield better results than others. Not keeping up just worsens the chances, I have found.
It does when it is called unionizing, however for some reason software developers have a mental block towards the concept.
Re: Human coders are still better than LLMs
#176Earlier quoted context omitted.
The time where humans + computers in chess were better than just computers was not a long time. That era ended well over a decade ago. Might have been true for only 3-5 years.
Unrelated to the broader discussion, but that's an artifact of the time control. Humans add nothing to Stockfish in a 90+30 game, but correspondence chess, for instance, is played with modern engines and still has competitive interest.
It is not clear to me whether human input really matters in correspondence chess at this point either.
I mused about this several years ago and still haven't really gotten a clear answer one way or the other.
Re: Human coders are still better than LLMs
#177Earlier quoted context omitted.
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…
I think we're hoping for more than the 'infinite monkeys bashing out semantically correct code' approach.
Ok, define what means and make it. Then as soon as you do realize you run into Gödel’s understanding your machine doesn’t solve problems related to its own existence and needs outside help. So you need to generate that yet unseen solution that lacks context for understanding itself… repeat and see it’s exactly generating one yet unseen layer of logic after another.
Read the article; his younger self failed to see logic needed now. Add that onion peel. No such thing as perfect clairvoyance.
Even Yann LeCun’s energy based models driving robots have the same experience problem.
Make a computer that can observe all of the past and future.
Without perfect knowledge our robots will fail to predict some composition of space time before they can adapt.
So there’s no probe we can launch that’s forever and generally able to survive with our best guess when launched.
More people need to study physical experiments and physics and not the semantic rigor of academia. No matter how many ideas we imagine there is no violating physics.
Pop culture seems to have people feeling starship Enterprise is just about to launch from dry dock.
Re: Human coders are still better than LLMs
#178Earlier quoted context omitted.
> The hype cycle is real and setting expectations that get higher with _the less you know about how they work_. I imagine on HN, the expectations we're talking about are from fellow software developers who at least have a general idea on how LLM's work and their limitations.
Right below this is a comment > you will almost certainly be replaced by an llm in the next few years So... Maybe not. I agree that Hacker News does have a generally higher quality of contributors than many places on the internet, but it absolutely is not a universal for HNers. There are still quite a few posters here that have really bought into the hype for whatever reason
I wish we'd measure things less against how hyped they are. Either they are useful, or they are not. LLMs are clearly useful (to which extent and with what caveats is up to lively debate).
Re: Human coders are still better than LLMs
#179Earlier quoted context omitted.
> 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.
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 driver? Underlying I/O decisions are probably abstracted away already (think Netty vs Mina), and decisions on how to manage connections, protocol handling, bind variables, etc. are made by the library, while questions remain for things like which specific tables and columns should be referenced. This makes the library reusable for this task as long as you're fine with the underlying decisions.
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.
The devil is in the details (even if you know the insides of the devil aren't really any different).
Re: Human coders are still better than LLMs
#180There'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…
ChatGPT-4o is scary good at writing VHDL. Using it to prototype some low level controllers today, as a matter of fact!
It's better-than-senior at a some things, but worse-than-junior at a lot of things.