Live data from Hacker News

Slop is not necessarily the future

greptile.com

51–60 of 512 posts

Re: Slop is not necessarily the future

#51

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

Re: Slop is not necessarily the future

#52
post #36

Earlier quoted context omitted.

Look up Roman concrete. There are 2000 year old bridges and aqueducts still in use. We only recently figured out how to reproduce Roman concrete. We’d have more but a lot were blown up during WWII.

There is nothing special about roman concrete compared to moderns concrete. Modern concrete is much better The difference is that they didn't have rebar. And so they built gravity stable structures. Heavy and costly as fuck. A modern steel and concrete structure is much lighter and much cheaper to produce. It does mean a nodern structure doesn't last as long but also the roman stuff we see is what survived the test o…

We have modern architecture crumbling already less than 100 years after it has been built. I know engineering is about tradeoffs but we should also acknowledge that, as a society, we are so much used to put direct economic cost as the main and sometimes only metric.

Re: Slop is not necessarily the future

#54
post #45

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…

> 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 on their product faster. I am in both camps. Always have been. Code janitors about to be in high demand. We’ve always been pretty popular with leadership and it’s gonna get even more important. Treat code design an…

> My output is org velocity.

Amen, slow and steady and the feature fly wheel just keeps getting faster.

Re: Slop is not necessarily the future

#55

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…

That's fair!

> Facebook is a great example of this, there's some gnarly old spaghetti code under the hood just from the years of legacy code but those are largely invisible to the user and their experience of the product.

I'm sure that's the case in basically everything, it sorta doesn't matter (until it does) if it's cordoned off into a corner that doesn't change and nominally works from the outside perspective.

But those cases are usually isolated, if they aren't it usually quickly becomes noticeable to the user in one way or another, and I think that's where these new tools give the illusion of faster velocity.

If it's truly all spaghetti underneath, the ability to make changes nosedives.

Re: Slop is not necessarily the future

#56
post #51

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 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 useful things.

Re: Slop is not necessarily the future

#57

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…

There are other players in the game: the business and the market.

Good code makes it easier for the business to move fast and stay ahead of the competition while reducing expenses for doing so.

Re: Slop is not necessarily the future

#58

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…

> You treat your code as a means to an end to make a product for a user. It isn’t that though, the “end” here is making money not building products for users. Typically people who are making products for users cares about the craft. If the means-to-end people could type words into a box and get money out the other side, they would prefer to deal with that than products or users. Thats why ai slop is so prevalent — th…

Yeah, I'm not trying to defend slop.

I don't think all means-to-end people are just in it for money, I'll use the anecdote of myself. My team is working on a CAD for drug discovery and the goal isn't to just siphon money from people, the goal is legitimately to improve computational modeling of drug interactions with targets.

With that in mind, I care about the quality of the code insofar as it lets me achieve that goal. If I vibe coded a bunch of incoherent garbage into the platform, it would help me ship faster but it would undermine my goal of building this tool since it wouldn't produce reliable or useful models.

I do think there's a huge problem with a subset of means-to-end people just cranking out slop, but it's not fair to categorize everyone in that camp this way ya'know?

Re: Slop is not necessarily the future

#59
post #45

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…

> 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 on their product faster. I am in both camps. Always have been. Code janitors about to be in high demand. We’ve always been pretty popular with leadership and it’s gonna get even more important. Treat code design an…

>slop cannons

I am stealing that phrase haha

Re: Slop is not necessarily the future

#60

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 mostly agree with this. Part of the confusion with the discourse around AI is the fact that "software engineering" can refer to tons of different things. A Next.js app is pretty different from a Kubernetes operator, which is pretty different from a compiler, etc.

I've worked on a project that went over the complexity cliff before LLM coding even existed. It can get pretty hairy when you already have well-established customers with long-term use-cases that absolutely cannot be broken, but their use-cases are supported by a Gordian Knot of tech debt that practically cannot be improved without breaking something. It's not about a single bug that an LLM (or human) might introduce. It's about a complete breakdown in velocity and/or reliability, but the product is very mature and still makes money; so abandoning it and starting over is not considered realistic. Eager uptake of tech debt helped fuel the product's rise to popularity, but ultimately turned it into a dead end. It's a tough balancing act. I think a lot of LLM-generated platforms will fall eventually into this trap, but it will take many years.

Post reply on HN