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.
Slop is not necessarily the future
161–170 of 512 posts
Re: Slop is not necessarily the future
#162People 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…
Re: Slop is not necessarily the future
#163---------
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
#164I 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…
Well, you certainly should. Those people made AI based coding a possibility in the first place.
Re: Slop is not necessarily the future
#165I 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…
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"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"…
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
#167Earlier 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.
And in almost all of those cases, they'd be wrong.
Re: Slop is not necessarily the future
#168Earlier 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…
Such a world still has room for unlicensed developers too -- I'd certainly be among them.
Re: Slop is not necessarily the future
#169I 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…
- 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
#170I 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…
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.