Live data from Hacker News

Programmer salaries in the age of LLMs

milkyeggs.com

121–130 of 163 posts

Re: Programmer salaries in the age of LLMs

#121
post #78

There is research [1] that suggests using GPS navigation could impact your brain function negatively. I wonder how this code generation “assistant” will impact the coding skills of its users in long term. As for the LLMs, stochastic parroting (hallucination), which is inherent to its design, makes it untrustworthy for precision work. Maybe some other architecture will prove more useful. LLMs can generate BS authorita…

I just tried ChatGPT today after weeks of hype on Twitter, and I was surprised to NOT be impressed? First I tried it on a bunch of programming topics -- it definitely gets in the right ballpark, but then the details are frequently wrong. I asked which languages have the F# |> operator, and it told me that OCaml, Elixir, Haskell and Scala do. 2 of them are correct, and 2 appeared wrong, so I googled it. After Googling…

I hate the AI hype. It ruins the fun. People always respond in the same way.

Re: Programmer salaries in the age of LLMs

#122

Comment here seem to largely miss the point of the article, which isn't saying that nobody will employ software engineers. It is saying that instead of the current model of: 1 very highly compensated staff+ engineer 4 highly compensated senior engineers 4 pretty well-compensated mid-level engineers 2 decently compensated junior engineers The future might look like: 1 yet-more-highly-compensated staff+ engineer who sp…

Industries need the hierarchical treadmill of juniors moving up to mid moving up to senior and so on in order to populate the top level. People can't just start there. The idea of 1 staff+ engineer and 10 juniors will only work if businesses are happy with people moving from junior straight to staff+. That seems unlikely to me.

Re: Programmer salaries in the age of LLMs

#123
A funny thing I noticed when googling whether melamine was microwave-safe: I got a lot of clickbaity articles from sketchy sites. Some said melamine is microwave safe, some said it is not, and some seemed to contradict each other.

An Asimov story called "Liar!" concerns a robot which has the ability to read minds. When asked to tell what's going on in another person's mind (does so-and-so have a crush on me? is my boss planning to give me a promotion?) the robot, following its First Law directive not to allow humans to come to harm (including emotional harm), tells the querent what they would like to hear based on the robot's reading of the querent's mind, instead of the truth because the truth can hurt. When the robot is shown that its actions hurt humans anyway, it promptly shuts down and refuses to function.

These language models seem like that robot. The articles on melamine suggest to me that the AIs which generated them are producing output that their statistical models suggest the querent wants to hear, rather than output with correct answers. In light of this, it seems that using these models for assistance in coding would be like having an obsequious but shitty coworker, whose output you must carefully review and vet because even money it's not a solution to your problem, just a guess at what you want to see based on a vast statistical soup built up of thousands of programmers' efforts on millions of tasks. Which means any effort you saved up now will be paid for with extra effort later, as every programmer knows it's much easier and more fun to wrote new code than to review and debug someone else's code, especially if it's shitty, especially^2 if it's subtly shitty. It really is like Teitelman's DWIM evolved, with correspondingly magnified lossage in its failure modes!

Re: Programmer salaries in the age of LLMs

#124

"Note that querying LLMs and making the outputted code conform to specifications is probably a lot easier than writing the code yourself" This overestimates the time developers spend typing text and underestimates the time spent thinking about problems, verification and locating bugs/code, etc. Just because the output of a model is text doesn't mean it is a replacement. You would need extraordinary "single shot" func…

Only yesterday, I worked on a ticket for few hours, inspecting several Mongo collections in QE and prod. And then had to make 4 to 5 lines of changes across 3/4 python scripts. And then manually run them to patch the mongo collections. Which was the root cause of the bug. I don't see GPT doing this kind of stuff anytime soon.

And yes, very less percentage of the time, do we right chunks of fresh code, in which this could help. But that again to an extent. It can generate functions. But the glue code is still complicated. So it can definitely be a better Stack Overflow replacement, perhaps.

Re: Programmer salaries in the age of LLMs

#126

"Note that querying LLMs and making the outputted code conform to specifications is probably a lot easier than writing the code yourself" This overestimates the time developers spend typing text and underestimates the time spent thinking about problems, verification and locating bugs/code, etc. Just because the output of a model is text doesn't mean it is a replacement. You would need extraordinary "single shot" func…

The smaller the problem the easier it is to use AI. Which makes the window where it's useful very small.

Its easier to understand and test code that you wrote than code you just read. If you ask it to write a 100k line program you're going to have to trace through everything and read it countless times over to fix any issues.

If you ask it to write a small 10 line snippet that you need to test you might as well do it yourself.

Re: Programmer salaries in the age of LLMs

#127

"Note that querying LLMs and making the outputted code conform to specifications is probably a lot easier than writing the code yourself" This overestimates the time developers spend typing text and underestimates the time spent thinking about problems, verification and locating bugs/code, etc. Just because the output of a model is text doesn't mean it is a replacement. You would need extraordinary "single shot" func…

[dead]

Re: Programmer salaries in the age of LLMs

#128

"Note that querying LLMs and making the outputted code conform to specifications is probably a lot easier than writing the code yourself" This overestimates the time developers spend typing text and underestimates the time spent thinking about problems, verification and locating bugs/code, etc. Just because the output of a model is text doesn't mean it is a replacement. You would need extraordinary "single shot" func…

Much like the adage that you need to be smarter to debug code than to write code, you need to be smarter to "touch up" AI generated code than to write it yourself.

The problem with AI generated code is that it contains mistakes and because of the nature of how it works, those mistakes may be entirely unlike the kind of mistakes a human would make or may be completely undetectable unless you know what the code should be doing.

The best use case for AI code generation is auto-complete. Depending on the complexity of the code, that can be sufficient to do 90% of the work of writing code, but it's very different from "solving problems" which tends to be the tricky part. It also requires the AI user to already know the code they want the AI to generate before it does it.

An interesting application of AI outside of simple code generation however is what GitHub is currently experimenting with as "code brushes", i.e. "touching up" existing code, trying to fix bugs or apply refactorings. This fits in the gap of "single shot functionality" but operates on existing code rather than requiring a blank slate.

But at the end of the day I think AI will fail to kill programming just like other attempts like WYSIWYG UI builders and COBOL have and for the same reason: competence as a programmer is not about the ability to write code but the ability to understand programs and systems, both at scale and in depth. A beginner will not write bad code simply because they lack experience in using the language, they will write bad code because they lack understanding of what the code does and how it interacts with its environment (and how that environment interacts with it in turn, e.g. UX).

Re: Programmer salaries in the age of LLMs

#129
post #56

There is research [1] that suggests using GPS navigation could impact your brain function negatively. I wonder how this code generation “assistant” will impact the coding skills of its users in long term. As for the LLMs, stochastic parroting (hallucination), which is inherent to its design, makes it untrustworthy for precision work. Maybe some other architecture will prove more useful. LLMs can generate BS authorita…

I wonder how this code generation “assistant” will impact the coding skills of its users in long term. My brain is already negatively impacted having to juggle 3 separate package managers, know the syntax and inputs for 17+ different dotfiles in a repo and then actively context switch between at least 3-4 languages on a daily basis. I counted it up recently and I've built products in at least 20 languages over the pa…

I didn’t mean just any negative impact like getting tired from context switching or feeling exhausted because the workload is high.

What I meant was: Will you lose it if you don’t use it?

Maybe you won’t, I am not certain. Or maybe you will and you don’t see it now because the “net win for syntax recall just by giving it gentle nudges towards intent” relies on your hard earned ability to understand the code which is gained partly through exercise. You’ve already done your exercise.

I wouldn’t form an opinion just yet. For now we can ask the questions.

Edit: wording of the first sentence for clarity

Re: Programmer salaries in the age of LLMs

#130

Earlier quoted context omitted.

> The experienced engineer also gets an LLM though Say experienced engineer Edna was working on a project and the new grad Nelson replaced her because he was cheaper and about as good if both have LLMs, i.e., Edna + LLM ≈ Nelson + LLM even though Edna >> Nelson. So Edna needs to find a project to work on where LLMs don't equalize her arbitrage, i.e., Edna + LLM >> Nelson + LLM and Nelson needs one where Nelson + LLM…

My contention is "how do you determine if someone was 'as good'?" Very likely the people in the position to make a decision will not be qualified enough to even make that decision. IF (and really only if) such a determination is possible, then sure, I agree, find harder problems etc, but I assert that people will not make that determination (which is close to impossible to make) well, if at all because that wasn't th…

Project succeeds = good.

Project fails = bad.

If a bunch of projects given to NG + LLM fail, the company will say at some point "this is no good, let's not do that anymore". If they mostly succeed, they'll do it more.

From a middle manager's perspective, where they're funding 10-20 projects, this kind of measurement is feasible and carries at least some signal. So I don't agree it's difficult to measure.

Post reply on HN