Live data from Hacker News

Slop is not necessarily the future

greptile.com

71–80 of 512 posts

Re: Slop is not necessarily the future

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

Engineers don't build the cheapest bridge that just barely won't fail. They build the cheapest bridge that satisfies thousands of pages of regulatory requirements maintained and enforced by dozens of different government entities. Those regulations range from safety, to aesthetic, to environmental, to economic, to arcane.

Left to their own devices, engineers would build the cheapest bridge they could sell that hopefully won't collapse. And no care for the impact on any stakeholder other than the one paying them.

Re: Slop is not necessarily the future

#72
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…

> Treat code design and architecture as the thing that lets your slop canons (90% of engineers even pre-ai) move fast without breaking things

I'm currently of the opinion that humans should be laser focused on the data model. If you've got the right data model, the code is simpler. If you've got the relevant logical objects and events in the database with the right expressivity, you have a lot of optionality for pivoting as the architecture evolves.

It's about that solid foundation - and of course lots of tests on the other side.

Re: Slop is not necessarily the future

#73
post #51

Earlier quoted context omitted.

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

I think I fall in camp 1.5 (I don't fall in camp 1 or camp 2) as in I can see value in prototyping (with AI) and sometimes make quick scripts when I need them, but long term I would like to grow with an idea and build something genuinely nice from those prototypes, even manually writing the code as I found personally, AI codebases are an hassle to manage and have many bugs especially within important things (@iamcalledrob message here sums it up brilliantly as well)

> I think camp 2 would rather see one beautiful thing than ten useful things.

Both beautiful and useful are subjective (imo). Steve job's adding calligraphy to computer fonts could've considered a thing of beauty which derived from his personal relation to calligraphy, but it also is an really useful thing.

It's my personal opinion that some of the most valuable innovations are both useful and beautiful (elegant).

Of course, there are rough hacks sometimes but those are beautiful in their own way as well. Once again, both beauty and usefulness is subjective.

(If you measure Usefulness with the profit earned within a purely capitalistic lens, what happens is that you might do layoffs and you might degrade customer service to get to that measure, which ultimately reduces the usefulness. profit is a very lousy measure of usefulness in my opinion. We all need profit though but doing solely everything for profit also feels a bit greedy to me.)

Re: Slop is not necessarily the future

#74
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…

I agree and I like how you describe it. The phrase from Django, "perfectionists with deadlines", also resonates with me.

Re: Slop is not necessarily the future

#75

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.

If you have buggy software, people don’t use it if there are alternatives. They don’t care about the code but hard to maintain, buggy code will eventually translate to users trying other products.

Re: Slop is not necessarily the future

#76

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…

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 than business/product success?

Re: Slop is not necessarily the future

#77

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 think "make a product" is the important point of disagreement here. AI can generate code that users are willing to pay for, but for how long? The debate is around the long-term impact of these short-term gains. Code _is_ a means to an end, but well-engineered code is a more reliable means than what AI currently generates. These are ends of a spectrum and we're all on it somewhere.

You ever notice how everyone who drives slower than you is a moron and everyone who drives faster than you is a maniac? Your two camps have a similar bias.

Re: Slop is not necessarily the future

#78

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 very useful insight. It nicely identifies part of the reason for the stark bifurcation of opinion on AI. Unfortunately, many of the comments below it are emotional and dismissive, pointing out its explanatory limitations, rather than considering its useful, probative value.

Re: Slop is not necessarily the future

#79

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.

There are two reasons for this. One is that the people who make purchasing decisions are often not the people who suffer from your bad code. If the user is not the customer, then your software can be shitty to the point of being a constant headache, because the user is powerless to replace it.

The other reason is that there's no such thing as "free market" anymore. We've been sold the idea that "if someone does it better, then they'll win", but that's a fragile idea that needs constant protection from bad actors. The last time that protection was enacted was when the DOJ went against Microsoft.

> Sure, if you vibe code a massive bug into your product then that'll manifest as an outcome that impacts the user negatively.

Any semblance of accountability for that has been diluted so much that it's not worth mentioning. A bug someone wrote into some cloud service can end up causing huge real-world damage in people's lives, but those people are so far removed from the suits that made the important decisions that they're powerless to change anything and won't ever see that damage redressed in any way.

So yeah, I'm in camp #2 and I'm bitter about AI, because it's just accelerating and exacerbating the enshittification.

Someone on the HN wrote recently that everyone who's foaming at the mouth about how AI helps us ship faster is forgetting that velocity is a vector -- it's not just about how fast you're going, but also in what direction.

I'd go further and say that I'm not even convinced we're moving that much faster. We're just cranking out the code faster, but if we actually had to review that code properly and make all the necessary fixes, I'm pretty sure we would end up with a net loss of velocity.

Re: Slop is not necessarily the future

#80
post #45

Earlier quoted context omitted.

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

> Treat code design and architecture as the thing that lets your slop canons (90% of engineers even pre-ai) move fast without breaking things I'm currently of the opinion that humans should be laser focused on the data model. If you've got the right data model, the code is simpler. If you've got the relevant logical objects and events in the database with the right expressivity, you have a lot of optionality for pivo…

How do you even converge on the right data model without refining code? Elegant code and elegant data model are the exact same thing!
Post reply on HN