Live data from Hacker News

Slop is not necessarily the future

greptile.com

161–170 of 512 posts

Re: Slop is not necessarily the future

#161

The economic angle is not as clear cut as the authors seem to think. There is an abundance of mediocre and even awful code in products that are not failing because of it. The worst thing about poorly designed software architecture is that it tends to freeze and accumulate more and more technical debt. This is not always a competitive issue, and with enough money you can maintain pretty much any codebases.

Even with enough money, you may not be able to attract/keep talented engineers who are willing to put up with such a work environment (the codebase itself, and probably the culture that led to its state) and who want to ship well built/designed software but are slowed down by the mess.

Re: Slop is not necessarily the future

#162

People are not emotionally ready to accept that certain layers of abstraction don’t need as much care and effort if they can be automated. We are at the point where a single class can be dirty but the API of the classes should be clean. There’s no point reviewing the internals of a class anymore. I’m more or less sure that they would work as intended. Next step is that of a micro service itself. The api of that micro…

"The only reason people disagree with me is because they are emotionally deficient."

Re: Slop is not necessarily the future

#163
"AI will write good code because it is economically advantageous to do so. Per our definition of good code, good code is easy to understand and modify from the reduced complexity."

---------

This doesn't necessarily follow. Yes, there might be economic pressure for AI to produce "good" code, but that doesn't necessarily mean efforts to make this so will succeed. LLM's might never become proficient at producing "good" code for the same reasons that LLM's perform poorly when trained on their own output. A heuristic prediction of what "good" code for a given solution looks like is likely always going to be less "good" than code produced by skilled and deliberate human design.

Just as there is a place for fast and dirty human code, there will be a place for slop code. Likely the same sort of place. However, we may still need humans to produce "good" code that AI can be trained on as well as for solutions that actually need to be "good". AI might not be able to do that for us anytime soon, no matter what the economic imperatives are.

Re: Slop is not necessarily the future

#164

I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…

> With that said, I do have respect for people in the latter camp.

Well, you certainly should. Those people made AI based coding a possibility in the first place.

Re: Slop is not necessarily the future

#165

I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…

>No one has ever made a purchasing decision based on how good your code is.

That's however what makes for stable systems, deep knowledgable engineers, and structurally building the basis for the future.

If all you care about is getting money for your product slop, it's not different than late night marketed crap, or fast fashion...

Re: Slop is not necessarily the future

#166
post #163

"AI will write good code because it is economically advantageous to do so. Per our definition of good code, good code is easy to understand and modify from the reduced complexity." --------- This doesn't necessarily follow. Yes, there might be economic pressure for AI to produce "good" code, but that doesn't necessarily mean efforts to make this so will succeed. LLM's might never become proficient at producing "good"…

The economic force is the LLMs themselves are worse at maintaining slop than good good.

Everything fundamental that makes good easier for humans to maintain also makes it easier for LLMs to maintain. Full stop.

Re: Slop is not necessarily the future

#167

Earlier quoted context omitted.

> The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks. Exactly. A lot of devs optimizing for whether the feature is going to take a day or an hour, but not contemplating that it's going to…

> but not contemplating that it's going to be out in the wild for 10 years either way I think there are a lot of developers working in repos where it's almost guaranteed that their code will _not_ still be there in 10 years, or 5 years, or even 1 year.

>I think there are a lot of developers working in repos where it's almost guaranteed that their code will _not_ still be there in 10 years, or 5 years, or even 1 year.

And in almost all of those cases, they'd be wrong.

Re: Slop is not necessarily the future

#168

Earlier quoted context omitted.

Engineers don't build the cheapest bridge that just barely won't fail. They build the cheapest bridge that satisfies thousands of pages of regulatory requirements maintained and enforced by dozens of different government entities. Those regulations range from safety, to aesthetic, to environmental, to economic, to arcane. Left to their own devices, engineers would build the cheapest bridge they could sell that hopefu…

> Left to their own devices, engineers would build the cheapest bridge they could sell that hopefully won't collapse. I don't know any real (i.e. non-software) engineers, but I would love to ask them whether what you said is true. For years now, I've been convinced that we should've stuck with calling ourselves "software developers", rather than trying to crib the respectability of engineering without understanding w…

Civil engineers are licensed and carry insurance. When software developers have similar requirements, then I'll call them engineers. In some fields like avionics, the certification regime is a good proxy for licensing -- I think we could extend the "engineer" title to those developers too.

Such a world still has room for unlicensed developers too -- I'd certainly be among them.

Re: Slop is not necessarily the future

#169

I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…

I think this is a false dichotomy. If you're passionate about your craft, you will make a higher quality product. The real division is between those who measure the success of a project in:

- revenue/man-hour, features shipped/man-hour, etc.

- ms response time, GB/s throughput, number of bugs actually shipped to customers, etc.

People in the second camp use AI, but it's a lot more limited and targeted. And yes, you can always cut corners and ship software faster, but it's not going to be higher quality by any objective metric.

Re: Slop is not necessarily the future

#170

I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…

How about the type of developer who comes up with statistics and made up "camps" as if enjoying the craft itself makes you, out of necessity of the false premise, unable to enjoy the fact that what you made is useful enough to people that they choose your product because you are obsessed with making a good work?

John Carmack has talked about it in a podcast a few years ago, and he's the closest popular programmer that I can think of who was simply obsessed with milking every tiny ounce of GPU performance, yet none of his effort would matter if Doom and Quake weren't fun games.

Post reply on HN