Slop is not necessarily the future • Hacker News Board

Re: Slop is not necessarily the future

#491

Post by thesz » Wed, Apr 01, 2026, 5:58 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…

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

People make purchasing decisions on the availability of source code all the time, preferring source code available and be able to use it. It is safe to assume that they can perform purchase decisions on the quality of source code, given all is equal.

Re: Slop is not necessarily the future

#492

Post by zer00eyz » Wed, Apr 01, 2026, 6:14 PM UTC

paganel wrote: post #410

zer00eyz wrote: post #313

Earlier quoted context omitted.

> 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 quickly The assumption that people CARE about your product is the most Silicon Valley, Hacker News, forgot what the world out side of tech looks like thing ever. People CARE about their software as much as the CARE abo…

> People dont care (because we have also made a mockery of security as well) - They will start caring when a security bug on one of their phone's apps (or on the phone's software itself) empties their savings accounts. At that point the law officials/the Government might also start to care.

UHHH...

Mt. Gox, FTX, and an ocean of crypto wallet exploits.

This has already happened, and unlike traditional banks, there is no "customer service" to call with a shot at reversing a transaction.

It already happens to regular businesses, and on a regular basis: from credit card skimmers to major hacks, Home Depot springs to mind, along with numerous other ones that just dont even warrant the attention.

Meanwhile, yet another supply chain attack yesterday.

Security exists in most companies to protect management and give them a head to hang when the shit hits the fan (not IF, when). It's a cost center and is getting butchered right now in many orgs (we haven't had a problem why bother).

Re: Slop is not necessarily the future

#493

Post by advael » Wed, Apr 01, 2026, 6:17 PM UTC

nicbou wrote: post #413

advael wrote: post #379

At this point I can't help but conclude that to a certain class of writers, "economic incentives" are a form of benevolent god who will surely, inevitably make things better in directions they care about, and those who believe this also believe the overwhelming and constant evidence to the contrary of their position is just a temporary anomaly Whatever the hell economics was supposed to do, right now it seems to be c…

Economics is a natural force, but it does not specifically optimize for customer satisfaction.

Complex systems having meaningfully describable properties doesn't intrinsically make those properties natural laws

Re: Slop is not necessarily the future

#494

Post by ares623 » Wed, Apr 01, 2026, 7:18 PM UTC

danielbln wrote: post #391

ares623 wrote: post #139

Earlier quoted context omitted.

The irony is that "good" code and good documentation have top priority now in most orgs. For decades the best developers have been screaming about good code and documentation but leadership couldn't give a fuck. But now that their favorite nepobaby is here, now it's the most important thing all of a sudden.

What nepobaby are you talking about?

AI is the world's biggest nepo_hire_ (sorry, not nepobaby).

Re: Slop is not necessarily the future

#495

Post by username223 » Wed, Apr 01, 2026, 7:51 PM UTC

advael wrote: post #379

At this point I can't help but conclude that to a certain class of writers, "economic incentives" are a form of benevolent god who will surely, inevitably make things better in directions they care about, and those who believe this also believe the overwhelming and constant evidence to the contrary of their position is just a temporary anomaly Whatever the hell economics was supposed to do, right now it seems to be c…

"I want to argue that AI models will write good code because of economic incentives. Good code is cheaper to generate and maintain."

This is possibly the dumbest version of an "economic incentives" argument. Current code is the result of current economic incentives. It is a mystery to me why making code generation cheaper will make it more "good" in any way, instead of being either more of what we have now, or worse.

Re: Slop is not necessarily the future

#496

Post by dzhiurgis » Wed, Apr 01, 2026, 8:51 PM UTC

Planktonne wrote: post #418

dzhiurgis wrote: post #360

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. For now. We only call it slop when we notice it. Majority of AI text, music, images, videos and code is indistinguishable and you use…

> Majority of AI text, music, images, videos and code is indistinguishable and you use it every day. I really don't think this is true. If it was, we'd be able to point to countless examples of things assumed not to be AI that actually were, but there's a dearth of such examples.

Examples _are_ countless. Look around yourself - it's simply indistinguishable. Videos are still not quite there, the biggest telltale is how short they are, but we are very very close.

Re: Slop is not necessarily the future

#497

Post by skydhash » Wed, Apr 01, 2026, 8:54 PM UTC

bitwize wrote: post #490

skydhash wrote: post #348

Earlier quoted context omitted.

And the result was usually a complex system that no one needed and could maintain. Successful refinement is needed when you try to accomplish something from the ground up, refining it as you're adding features. Not locking yourself in the ivory tower drawing UML diagrams and drafting requirements. Doing and thinking go in pair, not separately.

Research conducted by M. Bryce and Associates suggested that use of a structured systems analysis phase before programming began resulted in time and cost savings vs. just "hacking it together" like programmers want to do. Locking yourself in the ivory tower is an unfair way to characterize systems analysis. Systems analysts talk to people in the business to understand what the business requirements actually are, and…

> Programmers only come in when the automatable parts of the system need to be implemented, and work from a detailed and precise spec.

A lot of systems are complex enough that you can’t get to that stage (and if you think you do, think again). Mostly because of communication issues and time concerns. Which is where the agile manifesto comes in and recommends the talk-do-show in short cycle. It needs not to be hacked together and the showing helps with communication, the talking guides the doing, and the doing is what pays for everything.

Re: Slop is not necessarily the future

#498

Post by davnicwil » Thu, Apr 02, 2026, 12:05 AM UTC

carlosjobim wrote: post #441

davnicwil wrote: post #195

Earlier quoted context omitted.

I keep seeing this idea repeated, but I don't accept the dichotomy between those who care about 'crafting code' and those who care about 'building products' as though they are opposite points on a spectrum. To me, the entire point of crafting good code is building a product with care in the detail. They're inseparable. I don't think I've ever in my life met someone who cared a lot about code and technology who didn't…

Millions of companies work out of spreadsheets, which is incredibly low quality and inefficient code by programming standards (not Excel, but the spreadsheet itself). Would those companies be better off just using pen and paper? Because "craft code" programmers don't have time for this, and not all companies can pay for bespoke software. Well, maybe now they can, with AI "slop". Likewise, should people who don't have…

With respect I'm not sure what you're saying follows as a challenge to what I've said. Perhaps because I didn't phrase clearly enough.

I don't think that. In fact I spent years at a company whose product let people build software backed by spreadsheets so I'm at least a little acquainted with that corner of the world :-)

The thing I'm saying is that among those who want to engage in building software via coding, I don't accept that caring about coding craft and caring about building great products that solve problems for people are opposing points on a spectrum.

If anything I'd argue the opposite, that these qualities are correlated. Again, speaking about people who are interested in building software with code.

I think the thing of building useful software with software (like spreadsheets / AI builders) while deliberately not wanting to engage with coding is a discussion apart from this. There's apparent overlap because it's true to say that those people are concerned with building useful things and not necessarily concerned with coding. But the fact they're not concerned with coding by definition puts them out the scope of the first conversation, it's just a different thing.

Re: Slop is not necessarily the future

#499

Post by irishcoffee » Thu, Apr 02, 2026, 12:26 AM UTC

StevenWaterman wrote: post #196

irishcoffee wrote: post #24

Earlier quoted context omitted.

That isn't how safety factors work... The person you're responding to is correct. I encourage you to look it up!

Safety factors account for uncertainty. Uncertainty the quality of materials, of workmanship, of unaccounted-for sources of error. Uncertainty in whether the maximum load in the spec will actually be followed. Without a safety factor, that uncertainty means that, some of the time, some of your bridge will fall down

A safety factor of 1.0 means “the structural integrity of this construct will meet the expectations of intended use with no issues.”

A safety factor of 1.7 means “if this construct is used in a way that is 70% more abusive than anticipated, the structural integrity should remain in tact.”

You’re hand-waving enough here that you have the luxury of agreeing or disagreeing with me, well-played. Your initial response was glib and not terribly productive.

Re: Slop is not necessarily the future

#500

Post by StevenWaterman » Thu, Apr 02, 2026, 7:33 AM UTC

irishcoffee wrote: post #499

StevenWaterman wrote: post #196

Earlier quoted context omitted.

Safety factors account for uncertainty. Uncertainty the quality of materials, of workmanship, of unaccounted-for sources of error. Uncertainty in whether the maximum load in the spec will actually be followed. Without a safety factor, that uncertainty means that, some of the time, some of your bridge will fall down

A safety factor of 1.0 means “the structural integrity of this construct will meet the expectations of intended use with no issues.” A safety factor of 1.7 means “if this construct is used in a way that is 70% more abusive than anticipated, the structural integrity should remain in tact.” You’re hand-waving enough here that you have the luxury of agreeing or disagreeing with me, well-played. Your initial response was…

This thread started because of "the cheapest bridge that just barely won't fail"

My point was that safety factors are a part of this. A safety factor of 1.0, designing bridges so that they can perfectly withstand the expectations of intended use, means that some unacceptable % of those bridges will fall down in practice.

In other words, it's true that you can explain safety factors as:

> Assuming perfect construction, and no defects, under designed maximum load, make sure that this bridge really stays up by a wide margin

But that misses the point of why we use safety factors. Nobody is paying for a bridge to really stay up by a wide margin. Because there's no material difference between a bridge that stays up, and a bridge that really stays up, right up until the point that the weaker one falls down due to inevitable over-loading or defects in construction / materials.