Slop is not necessarily the future • Hacker News Board

Re: Slop is not necessarily the future

#381

Post by nostrebored » Wed, Apr 01, 2026, 5:47 AM UTC

DesaiAshu wrote: post #300

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…

We crossed a threshold in the past couple months where I'm not sure I'd agree that "libraries other devs depend on" is the right cutoff for LLMs. In many cases, LLMs will write more concise, faster, and more accurate code. Not by one-shooting, but through a deeper search of possibility space - not dissimilar to how stockfish and other pre-llm search algorithms worked Modern harnesses are systems built with LLMs as on…

what types of problems are you seeing this for? i'm wondering if it's just a difference in domains, but this is not our experience at all. llms will write something, but the odds that it is efficient for any problem with deep complexity has been basically zero.

if it really were fuzzing and finding different candidate spaces, then I'd expect it to be good at things like dynamic programming, where I've only seen it fail. usually i see it get stuck in a bad solution and just thrashes around in that minima. these are problems where we can construct a verifiable test space, and it will eventually wind up with a solution, but one that is thousands of lines long and uses no structure of the problem space

Re: Slop is not necessarily the future

#382

Post by NateEag » Wed, Apr 01, 2026, 5:58 AM UTC

woeirua wrote: post #289

skillissue33 wrote: post #267

Earlier quoted context omitted.

Everyone who sucks at JavaScript says this. Same with CSS lol

The language itself is bad. Even the creator admitted it.

Crockford was not wrong that there are beautiful corners in JS.

It's at its best for functional programming.

If you don't know that style, then JS will be very unpleasant to use.

Re: Slop is not necessarily the future

#383

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

Ah, that'll be why Toyota is struggling. They spent too much effort making their cars reliable and not enough time making them look good.

Oh wait, they're the biggest car builder in the world.

Re: Slop is not necessarily the future

#384

Post by throw310822 » Wed, Apr 01, 2026, 6:14 AM 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…

There is also type 3, the worst kind: the developer who enjoys writing code to "get things done", no matter what the requirements are and the quality of the code. Produces tons of spaghetti code that barely works, without much thought about architecture or quality, and duly accompanied by tons of unit tests that test the exact implementation, bugs and all.

Re: Slop is not necessarily the future

#385

Post by _the_inflator » Wed, Apr 01, 2026, 6:20 AM UTC

nocman wrote: post #84

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. 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…

Is it really? I disagree strongly on all points, but know where you are coming from by an intuitive sense. I am a dev since the 80th and know how to make 64kb do wonders. It just took us years to find out.

You present no proof only touchy feely it must be so otherwise pseudo proof like software longevity is on the line.

Please first define software longevity quality in detailed terms: what is it exactly and how to you assess it regarsing quality and quantity?

Doom is judged by myself and by its versatility a masterpiece however, we all know and the Black Book is quite open about it the code itself is arguably not hitting modern standards as of today and there is a infamous WTF hardcoded value used to do speed code. So what? It inspired a whole generation. Second reality? A mindbender demo that accelerated quite a few finish developer careers has sadly forgotten after it was once considered for decades to be for the demo scene on PC what Doom was for the underground gamer scene. A nice match anyway.

Is Windows a masterpiece or not? Judging by its UX/UI definitely not, by its versatility and transposable potential I would rate it a masterpiece.

1000th of developers work on some code basis which change chipsets and compiler settings quite significantly - so there are ups and downs even in domains where a simple deadline and a requirement change suddenly makes technological prowess useless trash.

And the most heretical question ever: what if your so called number one quality software product might fool you and - could be way better done? You didn’t even consider that option which makes your point shaky to say the least.

Re: Slop is not necessarily the future

#386

Post by roncesvalles » Wed, Apr 01, 2026, 6:20 AM 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 a false dichotomy. Good code creates good products.

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

Disagree. Users tend to be very sensitive to quality, in software more than anything else. (Of course there isn't always perfect transmission from "user" to "purchaser" but most likely for an upstart product, your user will be your customer. You're not Oracle or Microsoft yet.)

In fact, quality matters now especially more than before because the barrier to entry has reduced. If you have a great idea, but executed it poorly, it attracts second movers like a magnet. Quality is intimidating. Quality is moat.

Good software engineers (your camp 2) can anticipate the ways in which bad code results in a poor quality product, or one that is difficult to debug and evolve. That is the crux of good code. Good code is not craftsmanship in the same sense as making a beautiful painting or making colorful notes.

Re: Slop is not necessarily the future

#387

Post by camgunz » Wed, Apr 01, 2026, 6:24 AM 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 binary is old and tired. It's possible to want to ship things and think LLMs make that harder. You don't engage with TFA at all, which is exploring this exact point: that the more slop that gets into prod the harder it will be to add features and fix bugs. If you like LLMs for coding and care about shipping long-term, this should be something you have an answer for.

Re: Slop is not necessarily the future

#388

Post by danielbln » Wed, Apr 01, 2026, 6:24 AM UTC

andersonpico wrote: post #363

yobbo wrote: post #162

Earlier quoted context omitted.

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

It goes from "llms can do everything as well or better to a human" to "quality doesn't really matter" really fast.

It also went real fast from "GPT hallucinated a library, literally useless" to "this agent has created this entire service up to spec, no notes".

Re: Slop is not necessarily the future

#389

Post by danielbln » Wed, Apr 01, 2026, 6:26 AM UTC

arnitdo wrote: post #371

pagecalm wrote: post #38

Agreed on the economics side. Clean code saves you time and money whether a human or AI wrote it. That part doesn't change. But I don't think the models are going to get there on their own. AI will generate a working mess all day long if you let it. The pressure to write good code has to come from the developer actually reviewing what comes out and pushing back. The incentive is there but it only matters if someone a…

> AI will generate a working mess all day long if you let it. The pressure to write good code has to come from the developer actually reviewing what comes out and pushing back You are reinventing the wheel again with yet another form of reinforcement learning. I don't use any form of LLM assistance for coding, but if I have to continually tell it what to do, how to do it, what not to do, what assumptions to make - I…

You don't have to continually tell it, you tell it once, persist it as convention and move on with your life.

Re: Slop is not necessarily the future

#390

Post by aryehof » Wed, Apr 01, 2026, 6:28 AM 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…

I feel like your missing a third alternative:-

You (are required to) treat your code as having to fulfill both functional requirements and declared non-functional requirements, including measures of maintainability, reliability, performance, and security and (regulatory/legal) compliance.