Live data from Hacker News

What we lost the last time code got cheap

poppastring.com

71–80 of 126 posts

Re: What we lost the last time code got cheap

#71

> The code they [LLMs] produce is often fine. It works. It passes tests. It might ship as-is. I don't disagree, but I've been thinking about this a bit: a lot of _human_ written code was/is less-than-fine. And a lot of human devs didn't understand the context when they wrote it. I'm not advocating that we fire devs, or evangelizing that LLms are awesome. But I do wish there was a slightly more honest take on the pre-…

> a lot of _human_ written code was/is less-than-fine. And a lot of human devs didn't understand the context when they wrote it.

I don't think anyone truly disputes this, but I don't think it's a good argument.

If we already had a sort of poor quality output when humans were at the helm, then what can we expect from AI steered by the sort of humans that produced poor quality code?

My guess would be even more poor quality code, at much higher volumes than before. It is impossible for me to see this as an improvement over "some people always made poor quality code"

Re: What we lost the last time code got cheap

#72
post #21

Reads at least partially like LLM writing, for example: > When code production gets cheap, the cost doesn't disappear. It migrates. > It was true then. It is unavoidably true now.

Maybe it's just because I grew up spending way too much time on the internet, but I write like that and have since well before LLMs. As much as people like to attribute that style to AI, I don't think it's the dead giveaway that people act like it is.

[dead]

Re: What we lost the last time code got cheap

#73
post #21

Reads at least partially like LLM writing, for example: > When code production gets cheap, the cost doesn't disappear. It migrates. > It was true then. It is unavoidably true now.

Comment reads at least partially like human writing, for it is terse and does not try to make a point.

Re: What we lost the last time code got cheap

#74
I do not understand why this is so unpopular today? I feel like everyone now thinks that basically all of SW engineering is outdated. We are supposed to forget all lessons learned and let agents to go through this? My opinion is to not care who did the job. But we should apply the same standard to human and AI output. I do not buy "we should not look at code". If we should not look at it what we should check instead to have the same control over final product? Because not having control over final product is so stupid right now.

Re: What we lost the last time code got cheap

#75

> The code they [LLMs] produce is often fine. It works. It passes tests. It might ship as-is. I don't disagree, but I've been thinking about this a bit: a lot of _human_ written code was/is less-than-fine. And a lot of human devs didn't understand the context when they wrote it. I'm not advocating that we fire devs, or evangelizing that LLms are awesome. But I do wish there was a slightly more honest take on the pre-…

[deleted]

Re: What we lost the last time code got cheap

#76
post #44

Earlier quoted context omitted.

It matters whether something is written using an LLM even if we put aside the ethical aspects. Firstly, if your text is deadly boring to read, your point might not get across optimally and one might not just be interesting reading slop. Secondly, you might just been reading the LLM's opinion, and I'm just not interested neither. Thirdly, even if you are just using the LLM as an assistant, we know that your opinion it…

I mostly agree with everything you said. Do you feel the same way about code written by an LLM?

I'm fortunate enough not to have been knowingly exposed to LLM generated code of big enough size yet, and haven't run into studies about this (to be fair, I'm not actively looking for them although I'd be quite interested). I imagine the stakes are quite different for code, it's not really opinions. On the topic of boringness I'm afraid I don't have the required experience to know how LLM generated / assisted code feels when reading it.

In particular, I have never had the curiosity of going to one of those vibe coded weekend projects' repository and peek at the code. Now that I think about it, maybe I should! Thanks for making me reflect on this.

I am concerned that one day I'll run into a PR that superficially looks good but that's badly structured in non immediately obvious ways or that has subtle errors due to the author not knowing well what they are doing. And on the longer term, that a code base with too many such contributions ends up being fragile and difficult to work with.

In any case I suppose I'll be looking for places to work where LLMs are not or little tolerated if they keep being a notable thing in the longer term.

Re: What we lost the last time code got cheap

#77

> The code they [LLMs] produce is often fine. It works. It passes tests. It might ship as-is. I don't disagree, but I've been thinking about this a bit: a lot of _human_ written code was/is less-than-fine. And a lot of human devs didn't understand the context when they wrote it. I'm not advocating that we fire devs, or evangelizing that LLms are awesome. But I do wish there was a slightly more honest take on the pre-…

> it's not just about cost reduction, it's about solving some long-term structural deficiencies of industry.

You know, I hate that this is a world where I have to ask myself if this is LLM written because it is one of those patterns.

But that is besides the point of what I wanted to say anyway. Those deficiencies aren't going to be solved by LLMs I recon. In fact, they likely will make things worse. As you said, a lot of human devs didn't understand the context when they wrote code previously. True, but LLMs are even worse at context in many areas and still need human prompting for input.

The only thing I really see happening is that the blast radius of people not fully grasping the context and still producing something is going to be larger. More specifically, it is already larger. Previously incompetence limited the damage people could do, now that is less of a factor.

Re: What we lost the last time code got cheap

#78

Earlier quoted context omitted.

Maybe it's just because I grew up spending way too much time on the internet, but I write like that and have since well before LLMs. As much as people like to attribute that style to AI, I don't think it's the dead giveaway that people act like it is.

Exactly. HN darling Paul Graham writes this way. I find the constant critique of punchy style a bit tiring. It would be more productive for the grandparent to think about the content and state an opinion.

I find the constant use of punchy style tiring.

Sometimes a "punch in the face" is useful. Makes you re-evaluate things. Being punched in the face all day, every day, is just tiring.

Re: What we lost the last time code got cheap

#79

> The code they [LLMs] produce is often fine. It works. It passes tests. It might ship as-is. I don't disagree, but I've been thinking about this a bit: a lot of _human_ written code was/is less-than-fine. And a lot of human devs didn't understand the context when they wrote it. I'm not advocating that we fire devs, or evangelizing that LLms are awesome. But I do wish there was a slightly more honest take on the pre-…

> a lot of _human_ written code was/is less-than-fine. And a lot of human devs didn't understand the context when they wrote it. I don't think anyone truly disputes this, but I don't think it's a good argument. If we already had a sort of poor quality output when humans were at the helm, then what can we expect from AI steered by the sort of humans that produced poor quality code? My guess would be even more poor qua…

> then what can we expect from AI steered by the sort of humans that produced poor quality code.

Great point, and I think that's my argument: above-average engineers can now produce more above average code. We don't need as many (any?) below-average developers moving forward.

Re: What we lost the last time code got cheap

#80
post #2

Personally I've found one of the biggest gains with coding agents is in helping me read code. Actually - that's a lie. I don't read the code. Mostly (unless my spidey-sense goes off) I ask the LLM to read the code and tell me what it does. And then I make a decision based on that. I guess I'm wondering if the article is missing half the picture. Yes - AI is wrong some of the time (and that % varies based on a host of…

The "It’s harder to read code than to write it" was always silly. The example spolsky gives to support it is basically "devs like to rewrite other devs code, therefore reading is hard" which is obviously bunch of nonsense. That's like saying reading poetry is harder than writing poetry because poets keep writing new poems despite the fact that Shakespeare already wrote it. Now that you can recruit LLM to explain any…

This isn't a great analogy. The thing about code is it is part of a whole. While often code can be read in smaller pieces and understood, quite often you have to understand a very large part, if not all the work to really see what is going on.

This is why things like SAST are topical. They miss all kinds of exploits because they don't understand the program. The more in depth you try to scan the more the memory requirements explode.

Now LLMs are much better at this, but between context windows and costs you can bankrupt yourself pretty quick putting code bases in context memory.

Post reply on HN