Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slop is not necessarily the future

greptile.com

Post reply on HN
Print view View original

201–210 of 512 posts

Re: Slop is not necessarily the future

#201

Post by jfreds »

jumploops wrote: post #153

“John Ousterhout [..] argues that good code is: - Simple and easy to understand - Easy to modify” In my career at fast-moving startups (scaling seed to series C), I’ve come to the same conclusion: > Simple is robust I’m sure my former teams were sick of me saying it, but I’ve found myself repeating this mantra to the LLMs. Agentic tools will happily build anything you want, the key is knowing what you want!

My issue with this is that a simple design can set you up for failure if you don’t foresee and account for future requirements.

Every abstraction adds some complexity. So maybe the PoC skips all abstractions. Then we need to add a variant to something. Well, a single if/else is simpler than an abstract base class with two concrete implementations. Adding the 3rd as another if clause is simpler than refactoring all of them to an ABC structure. And so on.

“Simple” is relative. Investing in a little complexity now can save your ass later. Weighing this decision takes skill and experience

Re: Slop is not necessarily the future

#202

Post by mikkupikku »

skydhash wrote: post #176
pron wrote: post #122

Earlier quoted context omitted.

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

It can be especially bad if the architecture is layered with each one having its own invariant. Like in a music player, you may have the concept of a queue in the domain layer, but in the UI layer you may have additional constraints that does not relate to that. Then the agent decide to fix a bug in the UI layer because the description is a UI bug, while it’s in fact a queue bug

Shit like this is why you really have to read the plans instead of blindly accepting them. The bots are naturally lazy and will take short cuts whenever they think you won't notice.

Re: Slop is not necessarily the future

#203

Post by Swizec »

joshmarlow wrote: post #72
Swizec wrote: 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…

> I 'm currently of the opinion that humans should be laser focused on the data model

yes. good programmers talk about data structures, bad programmers talk about code

Re: Slop is not necessarily the future

#204

Post by MrRadar »

mbesto wrote: post #198
MrRadar wrote: post #190

Earlier quoted context omitted.

> 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 quality of the product. They get real nice paychecks, benefits and put dinner on the table…

Which might be true, but is totally irrelevant to the OP's comment.

Users care about quality, even if the people buying the software do not. You can't just say "well the market doesn't care about quality" when the market incentives are broken for a paricular type of software. When the market incentives are aligned between users and purchasers (such as when they are the same person) quality tends to become very important for the market viability of software (see Windows in the consumer OS market, which is perceptibly losing share to MacOS and Linux following a sustained decline in quality over the last several years).

Re: Slop is not necessarily the future

#205

Post by mememememememo »

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…

Yes great so we sell shit. No one buys a ticket because ofnhow safe the 737 Max plane is or buys a post office franchise based on how good the software Fujitsu sold the post office is, but fuck lets take some pride in outselves and try to ship quality work.

Re: Slop is not necessarily the future

#206

Post by yabutlivnWoods »

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…

If code is craft and minimalism is hip then why ruby, and python, and go and... when it's electrical state in machines?

That's the minimalism that's been lost.

That's why I find the group 2 arguments disingenuous. Emotional appeal to conservatism, which conveniently also props up their career.

Why all those parsers and package systems when what's really needed is dials min-max geometric functions from grand theft auto geometry to tax returns?

Optimization can be (and will be) engineered into the machine through power regulation.

There's way too many appeals to nostalgia emanating from the high tech crowd. Laundering economic anxiety through appeals to conservatism.

Give me an etch a sketch to shape the geometry of. Not another syntax art parser.

Re: Slop is not necessarily the future

#207

Post by titzer »

> 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 society--particularly at the highest levels of governments. So I kind of don't want to hear about markets are going to reward.

But what exactly is "good code" (presumably the opposite of slop)?

I'd say that good code is terse, robust, suits its function, yet admits just the right amount of testability, performance, and customizability for the future. Good code anticipates change well. That means that if it has one job, it does that one job well, and not twenty others. If the job is going to stay the same, the code is going to stay the same. Good systems are made from well-factored pieces of code that have proper jobs and do their proper jobs without taking on jobs they shouldn't.

I for one think that AI code is going to reflect its training. If it's trained on just a random selection of everything out there, it's probably going to be pretty mediocre and full of bugs.

Re: Slop is not necessarily the future

#208

Post by Pxtl »

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…

As developers we have a unique advantage over everybody else dealing with the way AIgen is revolutionizing careers:

Everybody else is dealing with AIgen is suffering the AI spitting out the end product. Like if we asked AI to generate the compiled binary instead of the source.

Artists can't get AIgen to make human-reviewed changes to a .psd file or an .svg, it poops out a fully formed .png. It usurps the entire process instead of collaborating with the artist. Same for musicians.

But since our work is done in text and there's a massive publicly accessible corpus of that text, it can collaborate with us on the design in a way that others don't get.

In software the "power of plain text" has given us a unique advantage over kinds of creative work. Which is good, because AIgen tends to be clumsy and needs guidance. Why give up that advantage?

Re: Slop is not necessarily the future

#209

Post by myrak »

Xirdus wrote: post #148
ttamslam wrote: post #99

Earlier quoted context omitted.

> 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 quickly, and is obviously created by people the care deeply about the quality of the product they produce (you know, the kind that acutally read bug reports, and fix problems quickly). I would classify all of those as…

Good abstractions translate directly into how quickly the devs can fix bugs and add new features.

[dead]

Re: Slop is not necessarily the future

#210

Post by mememememememo »

jumploops wrote: post #153

“John Ousterhout [..] argues that good code is: - Simple and easy to understand - Easy to modify” In my career at fast-moving startups (scaling seed to series C), I’ve come to the same conclusion: > Simple is robust I’m sure my former teams were sick of me saying it, but I’ve found myself repeating this mantra to the LLMs. Agentic tools will happily build anything you want, the key is knowing what you want!

Yes. Which is why "I generated X lines of code" "I used a billion tokens this month" sound stupid to me.

Like I used 100 gallons of petrol this month and 10 kilos of rabbit feed!

Post reply on HN