Live data from Hacker News

Slop is not necessarily the future

greptile.com

211–220 of 512 posts

Re: Slop is not necessarily the future

#211
post #207

> Markets will not reward slop in coding, in the long-term. Forgive my cynical take, but we're currently experiencing a market that doesn't appear to be rewarding anything specific in the long-term, as huge sums of money are traded on a minute-to-minute, day-to-day, and week-to-week basis. There's an explosion of uncertainty in today's markets and complete collapse of long-range planning echoing at many levels in soc…

Markets have always rewarded popularity in the short term. in the long term though it has always rewarded quality.

Re: Slop is not necessarily the future

#212

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

#213
post #181

Earlier quoted context omitted.

> obviously created by people the care deeply about the quality of the product they produce This obviously doesn't represent all of the billions of dollars spent on software like Salesforce, SAP, Realpage, Booking.com, etc. etc. (all notoriously buggy, slow, and complex software). You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the q…

SAP, Salesforce, Booking.com… all awful products. We use them because monopolies.

I couldn't book travel at a previous company because my address included a `.`, which passed their validation. Awful, awful software. I wouldn't expect slop code to improve it.

Re: Slop is not necessarily the future

#214
I'm optimistic that AI will actually increase the proportion of good code in the future.

1. IME AI tends to produce good code "in the small." That is, within a function or a file, I've encountered very little sloppy code from AI. Design and architecture is (still) where it quickly tends to go off the rails and needs a heavy hand. However, the bulk of the actual code will tend to be higher quality.

2. Code is now very cheap. And more tests actually results in better results from AI. There is now very little excuse to avoid extensive refactoring to do things "the right way." Especially since there will be a strong incentive to have clean code, because as TFA indicates...

3. Complex, messy code will directly increase token costs. Not just in grokking the codebase, but in the tokens wasted on failed attempts rooted in over-complicated code. Finally, tech debt has a concrete $$$ amount. What can get measured can get fixed, and nothing is easier to measure (or convince execs about!) than $$$.

Right now tokens are extremely cheap because they're heavily subsidized, but when token costs inevitably start ramping up, slop will automatically become less economically viable.

Re: Slop is not necessarily the future

#215

Earlier quoted context omitted.

Trying to describe craftsmanship always brings me back to the Steve Jobs quote: “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried…

Steve Jobs didn't really know anything about cabinetry, because using plywood / MDF in places where it won't be seen but which would benifit from dimensional stability is absolutely common and there's no reason it shouldn't be.

You might be missing the point of the quote. He's not talking about whether it is commonly done. He's talking about the mentality that justifies sacrificing the aesthetic and artistry, in favor of things like "dimensional stability". He is giving a reason why it shouldn't be done, and people can disagree about whether the reason is a good one.

Re: Slop is not necessarily the future

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

Garbage software that is slow as a dog has been winning. While we’ve been obsessing over our craft and arguing about what makes software beautiful, slow crappy software has taken over the world.

Quality of code is just not that important of a concept anymore for the average web developer building some saas tool. React code was always crap anyways. Unless you are building critical systems like software that powers a plane or medical equipment, then code quality just doesn’t really matter so much in the age of AI. That may be a hard pill to swallow for some.

Re: Slop is not necessarily the future

#217
post #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.)

Never considered that the mods of this site are literally discussing with the people heading yc companies how to game their hn-titles for better interaction. How naive I am.

Re: Slop is not necessarily the future

#218
post #36

Earlier quoted context omitted.

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.

You would be very unhappy if you had to live in a house as built 100 years ago. Back then electric lights were rare. even if you had them the wiring wasn't up to running modern life. my house is only 50 years old and it shows signs of the major remodel 30 years ago, and there are still a lot of things that a newer house would all do different that I sometimes miss.

Re: Slop is not necessarily the future

#219

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've learned in two years of unemployed hacking that there is a camp 3: you treat code like an evolving life form, requiring both ingenious introspective craft and utilitarian grit to survive and thrive. a product is a trajectory of software in time, and software is a trajectory of code in time; this is no different from how our genetic code determines our physical existence, which then shapes our lives. there is no spectrum between code vs product; if you want to remain relevant in software design, you must see them as layers of a larger whole (and there are many, many more layers once you go beyond the binary of code VS product).
Post reply on HN