Slop is not necessarily the future • Hacker News Board

Re: Slop is not necessarily the future

#61

Post by iamcalledrob » Tue, Mar 31, 2026, 6:26 PM UTC

seamossfet wrote: post #31

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…

Sloppy technical design ends up manifesting in bugs, experiential jank, and instability.

There are some types of software (e.g. websites especially), where a bit of jank and is generally acceptable. Sessions are relatively short, and your users can reload the webpage if things stop working. The technical rigor of these codebases tends to be poor, but it's generally fine.

Then there's software which is very sensitive to issues (e.g. a multi-player game server, a driver, or anything that's highly concurrent). The technical rigor here needs to be very high, because a single mistake can be devastating. This type of software attracts people who want to take pride in their code, because the quality really does matter.

I think these people are feeling threatened by LLMs. Not so much because an LLM is going to outperform them, but because an LLM will (currently) make poor technical design decisions that will eventually add up to the ruin of high-rigor software.

Re: Slop is not necessarily the future

#62

Post by NitpickLawyer » Tue, Mar 31, 2026, 6:26 PM UTC

dcchambers wrote: post #30

simianwords wrote: post #29

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…

Does performance not matter? What if your AI uses an O(n) algorithm in a function when an O(log n) implementation exists? The output would still be "correct"

> Does performance not matter?

Performance can be a direct target in a feedback loop and optimised away. That's the easy part. Taking an idea and poof-ing a working implementation is the hard part.

Re: Slop is not necessarily the future

#63

Post by deathanatos » Tue, Mar 31, 2026, 6:31 PM UTC

vb-8448 wrote: post #3

Good code wasn't winning even before the ai slop era! The pattern was always: ship fast, fix/document later, but when "later" comes "don't touch what is working". To date nothing changed yet, I bet it won't change even in the future.

& I have thus far made a large portion of my living off of fixing bad code "later".

… but lately, the rate at which some dev with an LLM can just churn out new bad code has just shot through the roof. I can still be struggling to pick apart the last piece of slop, trying to figure out "okay, if someone with a brain had written this, what would the inputs & outputs be?" and "what is it that production actually needs and relies on, and what causes problems, and how can we get the code from point A to point B without more outages"; but in the meantime, someone has spit out 8 more modules of the same "quality".

So sure, the basic tenants haven't changed, but these days I feel like I'm drowning in outages & bugs.

Re: Slop is not necessarily the future

#64

Post by [deleted] » Tue, Mar 31, 2026, 6:32 PM UTC

jstanley wrote: post #56

clan wrote: post #51

Earlier quoted context omitted.

I respect your opinion and especially your honesty. And at the same time I hope that you will some day be forced to maintain a project written by someone else with that mindset. Cruel, yes. But unfortunately schadenfreude is a real thing - I must be honest too. I have gotten to old for ship now, ask questions later projects.

I'm in camp 1 too. I've maintained projects developed with that mindset. It's fine! Your job is to make the thing work, not take on its quality as part of your personal identity. If it's harder to work with, it's harder to work with, it's not the end of the world. At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies. I think camp 2 would rather see one beautiful thing than ten use…

[deleted]

Re: Slop is not necessarily the future

#65

Post by slopinthebag » Tue, Mar 31, 2026, 6:32 PM UTC

seamossfet wrote: post #47

packetlost wrote: post #42

Earlier quoted context omitted.

I agree on the software dev camps. > The general public does not care about anything other than the capabilities and limitations of your product. It's absolutely asinine to say the general public doesn't care about the quality and experience of using software. People care enough that Microsoft's Windows director sent out a very tail-between-legs apology letter due to the backlash. It's as it always has been, balancin…

The public doesn't care about the code itself, they absolutely care about the quality and experience of using the software. But you can have an extremely well designed product that functions flawlessly from the perspective of the user, but under the hood it's all spaghetti code. My point was that consuming software as a user of the product can be quite different from the experience of writing that software. Facebook…

Facebook.com is a monstrosity though, and their mobile apps as well are slow and often broken. And the younger generations are using other networks, Facebook is in trouble.

Re: Slop is not necessarily the future

#66

Post by ambicapter » Tue, Mar 31, 2026, 6:33 PM UTC

seamossfet wrote: post #31

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…

This is like when people decided that everyone was either "introvert" or "extrovert" and then everyone started making decisions about how to live their life based on this extremely reductive dichotomy.

There are products that are made better when the code itself is better. I would argue that the vast majority of products are expected to be reliable, so it would make sense that reliable code makes for better product. That's not being a code craftsman, it's being a good product designer and depending on your industry, sometimes even being a good businessman. Or, again, depending on your industry, not being callous about destroying people's lives in the various ways that bad code can.

Re: Slop is not necessarily the future

#67

Post by slopinthebag » Tue, Mar 31, 2026, 6:33 PM UTC

seamossfet wrote: post #31

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…

This is just cope to avoid feeling any shame for shipping slop to users.

Re: Slop is not necessarily the future

#68

Post by ambicapter » Tue, Mar 31, 2026, 6:34 PM UTC

jstanley wrote: post #56

clan wrote: post #51

Earlier quoted context omitted.

I respect your opinion and especially your honesty. And at the same time I hope that you will some day be forced to maintain a project written by someone else with that mindset. Cruel, yes. But unfortunately schadenfreude is a real thing - I must be honest too. I have gotten to old for ship now, ask questions later projects.

I'm in camp 1 too. I've maintained projects developed with that mindset. It's fine! Your job is to make the thing work, not take on its quality as part of your personal identity. If it's harder to work with, it's harder to work with, it's not the end of the world. At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies. I think camp 2 would rather see one beautiful thing than ten use…

> At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies.

Ah yes, if you aren't shitting code out the door as fast as possible, you're probably not shipping anything at all.

Re: Slop is not necessarily the future

#69

Post by logicchains » Tue, Mar 31, 2026, 6:34 PM UTC

seamossfet wrote: post #31

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…

It's perfectly possible to write very clean code with AI, it just takes a lot more time and prompting.

Re: Slop is not necessarily the future

#70

Post by renewiltord » Tue, Mar 31, 2026, 6:35 PM UTC

ambicapter wrote: post #66

seamossfet wrote: post #31

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…

This is like when people decided that everyone was either "introvert" or "extrovert" and then everyone started making decisions about how to live their life based on this extremely reductive dichotomy. There are products that are made better when the code itself is better. I would argue that the vast majority of products are expected to be reliable, so it would make sense that reliable code makes for better product.…

I’m an introvert. I make sure that all my “welcome to the company” presentations are in green. I am also an extrovert in that I add more green than required.