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

311–320 of 512 posts

Re: Slop is not necessarily the future

#311

Post by tokioyoyo »

xienze wrote: post #297
jstanley wrote: post #56

Earlier quoted context omitted.

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…

> If it's harder to work with, it's harder to work with, it's not the end of the world. Yeah it just takes longer and makes you miserable in the process. No biggie!

We will still work ~8ish hours that day, and time will pass anyways.

Re: Slop is not necessarily the future

#312

Post by abelitoo »

steveBK123 wrote: post #191
skydhash wrote: post #159

Earlier quoted context omitted.

Unless you’re producing demos for sales presentation (internally or externally), it’s always worth it to produce something good. Bad code will quickly slow you down and it will be a never ending parade of bug tickets.

indeed, being on-call cleanses many developers of slopulist habits

That depends on how quick the feedback loop is for your decisions. If it takes weeks or months to find the impact of your changes, or worse, if you're insulated somehow from those changes, you may not be pushed toward improving the quality of your code.

Re: Slop is not necessarily the future

#313

Post by zer00eyz »

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…

> 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

The assumption that people CARE about your product is the most Silicon Valley, Hacker News, forgot what the world out side of tech looks like thing ever.

People CARE about their software as much as the CARE about their bank, or a new finance product... People excited over software is more of a historic footnote than any thing real people think in 2026.

The vast majority of Software is one of two things:

A) a tool

B) a source of entertainment

As a tool it either needs to provide value or it's something that is shoved on you by work.

The user experience of your average mobile game today is fucking awful. People put up with a massive amount of garbage for a trickle of fun. So much of the web looks like a mid 90's Hong Kong back alleyway --- biking ads, videos screaming at you, and someone trying to steal your wallet. And the majority of things people are forced to use for work... well... Show me someone who is excited about their ERP or CMS or Network drive... Show me someone who thinks that anything to do with Salesforce is something to be excited over.

> The general public does not care about anything other than the capabilities and limitations of your product.

A segment of our industry is screaming about the security of open claw. People dont care (because we have also made a mockery of security as well) - they are using it as a tool that will deliver them a solution. It strips away all the arcanea that made people think we were wizards and writes the dam spells for them. It's a dumpster fire, and people are thrilled about it and what its delivering them. And thats software not made by you or I.

Re: Slop is not necessarily the future

#314

Post by miningape »

jfreds wrote: post #201
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…

I think what matters more than the abstract class vs if statement dichotomy, is how well something maps the problem domain/data structures and flows.

Sure maybe its fast to write that simple if statement, but if it doesn't capture the deeper problem you'll just keep running head first into edge cases - whereas if you're modelling the problem in a good way it comes as a natural extension/interaction in the code with very little tweaking _and_ it covers all edge cases in a clean way.

Re: Slop is not necessarily the future

#315

Post by singpolyma3 »

farmeroy wrote: post #109
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…

I think developers fall into two camps: 1. you care about shipping working, tested code that solves a specific business/user problem 2. you care about closing tickets that were assigned to you

Some of us also care about craft and code quality instead

Re: Slop is not necessarily the future

#316

Post by Rapzid »

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…

I find there are two types of people.

People who think developers fall into one of two camps.

And people worth listening to.

Re: Slop is not necessarily the future

#317

Post by inetknght »

dcchambers wrote: post #30
simianwords wrote: post #29

People are not emotionally ready to accept that certain layers of abstraction don’t need as much care and effort if they can be automated. We are at the point where a single class can be dirty but the API of the classes should be clean. There’s no point reviewing the internals of a class anymore. I’m more or less sure that they would work as intended. Next step is that of a micro service itself. The api of that micro…

Does performance not matter? What if your AI uses an O(n) algorithm in a function when an O(log n) implementation exists? The output would still be "correct"

If it's not tested, it's not Engineered.

Test what you care about. If you care about performance, then test your performance. Otherwise performance doesn't matter.

Re: Slop is not necessarily the future

#318

Post by jimbokun »

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…

I would add to that for software that has scaled to the point that it needs to run in a distributed fashion, code quality will show up very quickly in dollars and sense.

High latencies, outages, memory leaks, security vulnerabilities, will be seen in your AWS bill or whatever hardware or service you deploy your software to. If your code isn’t clear enough to understand what it’s really doing, you have no chance at preventing or addressing the above.

Re: Slop is not necessarily the future

#319

Post by pron »

zozbot234 wrote: post #274
pron wrote: post #254

Earlier quoted context omitted.

Right, except even when the invariants are documented agents get into trouble. Virtually every week I see the agent write strange code with multiple paths. It knows that the invariant _should_ hold, but it still writes a workaround for cases it doesn't. Something I see even more frequently is where the agent knows a certain exception shouldn't occur, but it does, so half the time it will choose to investigate and hal…

Agents don't really know the whole codebase when they're writing the code, their context is way too tiny for that; and trying to grow context numbers doesn't really work well (most of it gets ignored). So they're always working piece-meal and these failures are entirely expected unless the codebase is rigorously built for modularity and the agent is told to work "in the small" and keep to the existing constraints.

> Agents don't really know the whole codebase when they're writing the code

Neither do people, yet people manage to write software that they can evolve over a long time, and agents have yet to do that. I think it's because people can move back and forth between levels of abstraction, and they know when it's best to do it, but agents seem to have a really hard time doing that.

On the other hand, agents are very good at debugging complex bugs that span many parts of the codebase, and they manage to do that even with their context limitations. So I don't think it's about context. They're just not smart enough to write stable code yet.

Re: Slop is not necessarily the future

#320

Post by Rapzid »

pm wrote: post #171
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…

It is possible to exist in both camps. The quality of the process affects the quality of the product, and the quality of your thought affects the quality of the process. It's a cycle of continual learning, and from that perspective, thought, process and product are indivisible. Treating code as a means to an end doesn't guarantee success for your product anymore than treating code as a craft.

It's not possible for two-camp believers to conceive of two-camp dwellers. That would be tantamount to a third, potentially superior camp.

The two-camp construct is a tool to establish the believer as a member of the supreme one camp group; apart from the lesser campers. Their entire identity and self worth is built around one-camp membership.

Post reply on HN