Live data from Hacker News

Slop is not necessarily the future

greptile.com

121–130 of 512 posts

Re: Slop is not necessarily the future

#121

Why build each new airplane with the care and precision of a Rolls-Royce? In the early 1970s, Kelly Johnson and I [Ben Rich] had dinner in Los Angeles with the great Soviet aerodynamicist Alexander Tupolev, designer of their backfire Bear bomber. 'You Americans build airplanes like a Rolex watch,' he told us. 'Knock it off the night table and it stops ticking. We build airplanes like a cheap alarm clock. But knock it…

That's an interesting story, but not a great analogy for software.

If a technology to build airplanes quickly and cheaply existed and was made available to everyone, even to people with no aeronautical engineering experience, flying would be a much scarier ordeal than it already is.

There are good reasons for the strict safety and maintenance standards of the aviation industry. We've seen what can happen if they're not followed.

The fact that the software industry doesn't have similar guardrails is not something to celebrate. Unleashing technology that allows anyone to create software without understanding or even caring about good development practices and conventions is fundamentally a bad idea.

Re: Slop is not necessarily the future

#122

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 generally fall into the first camp, too, but the code that AI produces is problematic because it's code that will stop working in an unrecoverable way after some number of changes. That's what happened in the Anthropic C compiler experiment (they ended up with a codebase that wasn't working and couldn't be fixed), and that's what happens once every 3-5 changes I see Codex making in my own codebase. I think, if I had let that code in, the project would have been destroyed in another 10 or so changes, in the sense that it would be impossible to fix a bug without creating another. We're not talking style or elegance here. We're talking ticking time bombs.

I think that the real two camps here are those who haven't carefully - and I mean really carefully - reviewed the code the agents write and haven't put their process under some real stress test vs those who have. Obviously, people who don't look for the time bombs naturally think everything is fine. That's how time bombs work.

I can make this more concrete. 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. Other code that needs to search for an element depends on that invariant. Then it turns out that under some conditions - due to concurrency, say - an element is inserted in the wrong place and the list isn't sorted, so one of the places that tries to find an element in the list fails to find it. At that point, it's a coin toss of whether the agent will fix the insertion or the search. If it fixes the search, the bug is still there for all the other consumers of the list, but the testing didn't catch that. Then what happens is that, with further changes, depending on their scope, you find that some new code depends on the intended invariant and some doesn't. After several such splits and several failed invariants, the program ends up in a place that nothing can be done to fix a bug. If the project is "done" before that happens - you're in luck; if not, you're in deep, deep trouble. But right up until that point, unless you very carefully review the code (because the agents are really good at making code seem reasonable under cursory scrutiny), you think everything is fine. Unless you go looking for cracks, every building seems stable until some catastrophic failure, and AI-generated code is full of cracks that are just waiting for the right weight distribution to break open and collapse.

So it sounds to me that the people you think are in the first camp not only just care how the building is built as long as it doesn't collapse, but also believe that if it hasn't collapsed yet it must be stable. The first part is, indeed, a matter of perspective, but the second part is just wrong (not just in principle but also when you actually see the AI's full-of-cracks code).

Re: Slop is not necessarily the future

#123
post #88
post #9

If "good code" == "useful code", then yes. People forget that good engineering isn't "the strongest bridge", but the cheapest bridge that just barely won't fail under conditions.

Um, ackshually, real civil/structural engineers—at least, those in the global north—design bridges, roads, and buildings with huge tolerances (multiple times the expected loads) because unexpected shit happens and you don't want to suffer catastrophic failure when conditions are just outside of your typical use case and have a Tacoma Narrows Bridge type situation on your hands.

We might be arguing semantics, but safety margins aren't considered 'overbuilding' but part of the bare minimum requirements for a bridge to stand. They aren't there "just in case" they are there because it is known for a fact that bridges in the real world will experience degradation and overloading.

If you build a bridge that is rated to carry 100k lbs of weight, and you build it to hold 100k lbs, you didn't build it to barely meet spec -- you under built it -- because overloading is a known condition that does happen to bridges.

Re: Slop is not necessarily the future

#124

My prediction is that we'll start to see a whole new layer of abstraction to help us write high quality code with LLMs - meaning new programming languages, new toolchains, stricter typechecking, in-built feedback loops etc. The slop we're seeing today comes primarily from the fact that LLMs are writing code with tools meant for human users.

[deleted]

Re: Slop is not necessarily the future

#125

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…

[deleted]

Re: Slop is not necessarily the future

#126

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 competitors doing better. People very much do care about the results that good code provides, even if they don't care about the code as an end in itself.

Re: Slop is not necessarily the future

#127
post #84

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…

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

> absolutely false.

Actually, you are both correct.

Nobody makes a purchasing decision based on code quality.

But they may later regret a purchasing decision based on code quality.

Re: Slop is not necessarily the future

#128
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 disagree, Electron showed the world that good code can be magnetic ... I'll see myself out

It's a joke? (I'm not in the electron/js world and I don't get it)

Re: Slop is not necessarily the future

#129

Earlier quoted context omitted.

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…

> the quality really does matter. If this level of quality/rigor does matter for something like a game, do you think the market will enforce this? If low rigor leads to a poor product, won't it sell less than a good product in this market? Shouldn't the market just naturally weed out the AI slop over time, assuming it's true that "quality really does matter"? Or were you thinking about "matter" in some other sense th…

Yes, I think the market will enforce this. A bit. Eventually. But the time horizon is long, and crummy software with a strong business moat can out-compete great software.

Look at Windows. It's objectively not been a good product for a long time. Its usage is almost entirely down to its moat.

Re: Slop is not necessarily the future

#130
The authors updated their title so I've updated it here too. Previous title was "Good code will still win" - but it was leading to too much superficial discussion based entirely on the phrase "good code" in the title. It's amazing how titles do that!

(Confession: "good code will still win" was my suggestion- IIRC they originally had "Is AI slop the future?". You win some you lose some.)

Post reply on HN