Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slop is not necessarily the future

greptile.com

Post reply on HN
Print view View original

271–280 of 512 posts

Re: Slop is not necessarily the future

#271

Post by hn_acc1 »

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…

I'm in neither camp. I write code to make our product work, which we can then sell as a unit to the end user.

If I do a bad job, I get a bunch of bug reports, I get called out for writing bugs, etc. We've been pushed to use AI, and it's hurt more than it's helped with our code base.

Re: Slop is not necessarily the future

#274

Post by zozbot234 »

pron wrote: post #254
zozbot234 wrote: post #239

Earlier quoted context omitted.

> The program wants to depend on some invariant, say that a particular list is always sorted, and the code maintains it by always inserting elements in the right place in the list. Invariants must be documented as part of defining the data or program module, and ideally they should be restated at any place they're being relied upon. If you fail to do so, that's a major failure of modularity and it's completely forese…

Right, except even when the invariants are documented agents get into trouble. Virtually every week I see the agent write strange code with multiple paths. It knows that the invariant _should_ hold, but it still writes a workaround for cases it doesn't. Something I see even more frequently is where the agent knows a certain exception shouldn't occur, but it does, so half the time it will choose to investigate and hal…

Agents don't really know the whole codebase when they're writing the code, their context is way too tiny for that; and trying to grow context numbers doesn't really work well (most of it gets ignored). So they're always working piece-meal and these failures are entirely expected unless the codebase is rigorously built for modularity and the agent is told to work "in the small" and keep to the existing constraints.

Re: Slop is not necessarily the future

#275

Post by layer8 »

bit-anarchist wrote: post #235
latexr wrote: post #134

Earlier quoted context omitted.

> You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work. Exactly, thank you for putting it like that. So far it’s been my observation that it’s only the people who think like the OP who put the situation in the terms they did. It’s a false dichotomy whi…

That example doesn't work well. All regulations come at the cost of freedom, and every freedom comes at the cost of regulations. While it isn't a strict binary (either 100% freedom or 100% regulation), enacting regulations do interfere with freedom. So this isn't just framing, it demonstrates a relationship between the two concepts, which may become relevant down in the discussion, if it already hasn't.

Regulation can cause freedom to be balanced differently between parties. For example, regulating smartphone manufacturers can result in more freedom for users. It’s not true that regulation necessarily reduces freedom overall (to the extent that that can even be graded). Just like rights, freedoms aren’t absolute, and one’s freedom often impinges on someone else’s freedom.

Re: Slop is not necessarily the future

#276

Post by icedchai »

woeirua wrote: post #258

None of this is true. Pretty much all JavaScript code is slop because the language is god awful. It’s so bad that we spent the last 20 years trying to code around the severe limitations of the language itself. Despite everyone knowing that JS sucks, no one has been able to displace it. Slop wins. Typically because of first mover advantage.

30 years. I remember when Netscape 2.0 was released.

Re: Slop is not necessarily the future

#277

Post by eagerpace »

Slop code is like an early neural net. Path of least resistance. Except we cna see it and compare it to how it’s replacing something we’ve traditionally done instead of a neural net being opaque. As they write more code the path and concern for how it gets there will be approach zero.

Re: Slop is not necessarily the future

#278

Post by 9dev »

Animats wrote: post #35

Meanwhile, the complexity of the average piece of software is drastically increasing. ... The stats suggest that devs are shipping more code with coding agents. The consequences may already be visible: analysis of vendor status pages [3] shows outages have steadily increased since 2022, suggesting software is becoming more brittle. We've already seen a large-scale AWS outage because of this. It could get much worse.…

While I also view this development critically, why do you assume AI will be unable to fix the issues eventually?

Re: Slop is not necessarily the future

#279

Post by layer8 »

delbronski wrote: post #216
nocman wrote: post #84

Earlier quoted context omitted.

> No one has ever made a purchasing decision based on how good your code is. absolutely false. > The general public does not care about anything other than the capabilities and limitations of your product. also false. People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work qu…

Garbage software that is slow as a dog has been winning. While we’ve been obsessing over our craft and arguing about what makes software beautiful, slow crappy software has taken over the world. Quality of code is just not that important of a concept anymore for the average web developer building some saas tool. React code was always crap anyways. Unless you are building critical systems like software that powers a p…

The question is whether it has to be that way. Developers who are against slop don’t believe that the current state of software is the best possible world.

Re: Slop is not necessarily the future

#280

Post by efromvt »

bigstrat2003 wrote: post #126
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…

> No one has ever made a purchasing decision based on how good your code is. The general public does not care about anything other than the capabilities and limitations of your product. The capabilities and limitations of your product are defined in part by how good the code is. If you write a buggy mess (whether you write it yourself or vibe code it), people aren't going to tolerate that unless your software has no…

I think this is exactly the point though (maybe more of the link than of this comment) - a sufficiently good product by all external quality metrics is fine even if the code is written on one line in a giant file or some other monstrosity. As long as one black box behaves the same way as another in all dimensions, they are competitive. You can argue that internal details often point to an external deficiency, but if they don’t, then there is no competitive pressure.
Post reply on HN