Slop is not necessarily the future • Hacker News Board

Re: Slop is not necessarily the future

#421

Post by bootsmann » Wed, Apr 01, 2026, 9:39 AM UTC

Cthulhu_ wrote: post #415

Animats wrote: post #35

Meanwhile, the complexity of the average piece of software is drastically increasing. ... The stats suggest that devs are shipping more code with coding agents. The consequences may already be visible: analysis of vendor status pages [3] shows outages have steadily increased since 2022, suggesting software is becoming more brittle. We've already seen a large-scale AWS outage because of this. It could get much worse.…

I was curious about the claim about those vendor status pages, wondering if there's postmortems that actually single out AI. The source cited as [3] is a Reddit post with a poorly cropped chart, and it doesn't include any data from before 2022: https://www.reddit.com/r/sysadmin/comments/1o15s25/comment/n... I'm not saying it's wrong , because I haven't actually looked for alternative sources, just that the source isn…

Amazon holds engineering meeting following AI-related outages - Financial Times https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f77...

Re: Slop is not necessarily the future

#422

Post by modo_mario » Wed, Apr 01, 2026, 9:40 AM UTC

jimbokun wrote: post #328

delbronski wrote: post #216

Earlier quoted context omitted.

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

I believe a lot if large software companies like Google, Facebook, Apple, Netflix, Microsoft have very high quality code. Past a certain level of complexity, bad code will just collapse under the weight of its low quality.

I think you can scrap Microsoft there when it comes to their pc stuff and their mainly B2B stuff (dynamics and the like) As for the rest other than apple I think pageloads are an obvious metric to track and there's always going to be a contingent of their programmers incentivized to care about their code quality because slow code and the like runs on their machines at such scale that it often costs them a lot of money, same with uptimes of various services. Their amount spent on wages is comparatively very low.

Re: Slop is not necessarily the future

#423

Post by rainmaking » Wed, Apr 01, 2026, 9:55 AM UTC

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…

That's a fascinating way to look at it.

I've always found my self at the clean code end of the spectrum (which also means simple and flexible to me) because it makes it easier to be flexible for customer needs. So I like good code but it's a means to an end.

Re: Slop is not necessarily the future

#424

Post by marstall » Wed, Apr 01, 2026, 10:05 AM UTC

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…

| iterate on their product faster. i've run into a situation where it really slowed iteration down, because i wasn't able at some point to explain in english what I wanted it to do and had to go into the code, which, lo and behold, I didn't understand. Ended up scrapping everything that had been generated and starting over by hand!

Re: Slop is not necessarily the future

#425

Post by antonvs » Wed, Apr 01, 2026, 10:32 AM UTC

quantummagic wrote: post #78

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…

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.

> It nicely identifies part of the reason for the stark bifurcation of opinion on AI.

It might do that, if it had any basis in reality. Why do you believe it does?

Re: Slop is not necessarily the future

#426

Post by taatparya » Wed, Apr 01, 2026, 10:38 AM UTC

I believe this will inevitably happen due to this reason - economic.

And property testing is going to be an important way to validate.

Re: Slop is not necessarily the future

#427

Post by bdangubic » Wed, Apr 01, 2026, 11:15 AM UTC

couchand wrote: post #94

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…

I think camp 1 would rather see ten useless things than one useful thing.

100% not what Camp 1 is or does. Their #1 goal is make it work. It is your #1 priority. So quite the opposite, Camp 2 will spin and make 100 "useful" (not) abstraction with the slickest imaginable code doing things you go "OMFG, how on Earth did you come up with this, insane" while during that development Camp 1 shipped 37 new features for its customers

Re: Slop is not necessarily the future

#428

Post by zozbot234 » Wed, Apr 01, 2026, 11:27 AM UTC

pron wrote: post #319

zozbot234 wrote: post #274

Earlier quoted context omitted.

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

> Neither do people, yet people manage to write software that they can evolve over a long time

You need a specific methodology to do that, one that separates "programming in the large" (the interaction across program modules) from "programming in the small" within a single, completely surveyable module. In an agentic context, "surveyable" code realistically has to imply a manageable size relative to the agent's context. If the abstraction boundaries across modules leak in a major way (including due to undocumented or casually broken invariants) that's a bit of a disaster, especially wrt. evolvability.

Re: Slop is not necessarily the future

#429

Post by movpasd » Wed, Apr 01, 2026, 11:34 AM UTC

GuB-42 wrote: post #349

reese_john wrote: post #27

Why build each new airplane with the care and precision of a Rolls-Royce? In the early 1970s, Kelly Johnson and I [Ben Rich] had dinner in Los Angeles with the great Soviet aerodynamicist Alexander Tupolev, designer of their backfire Bear bomber. 'You Americans build airplanes like a Rolex watch,' he told us. 'Knock it off the night table and it stops ticking. We build airplanes like a cheap alarm clock. But knock it…

Soviet engineering wasn't sloppy. It was designed for robustness, loose tolerances and simplicity. It was well thought out design. In the same way that as much thought went into the cheap alarm clock than went into the Rolex watch, maybe even more so, the engineers just had different requirements. It takes a lot of work to make cheap, low precision parts work together reliably. The Rolex has it easy, all the parts ar…

There's a narrative that gets passed around in physics circles about how the Soviets were better at finding creative and analytical solutions than Americans, because of the relative scarcity of computing versus intellectual labour resources.

It would make sense to me that a parallel mechanism could apply to Soviet engineering. If material and technologically advanced capital are scarce, but engineers are abundant, you would naturally spend more time doing proper engineering, which means figuring out how to squeeze the most out of what you have available.

Re: Slop is not necessarily the future

#430

Post by mhitza » Wed, Apr 01, 2026, 11:37 AM UTC

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…

This is an often repeated reductionist classification, which I've yet to match with my real life experience.

Vibe coding will fill in more "new feature" checkboxes, faster, but the level of quality averages out, to something often mediocre, or worse (like all my OSS projects in which I experiment; because such projects are the training data). It skips liberally on maintainability, accessibility, security and privacy considerations.

Code is a liability, I want to have less of it at a higher abstraction level (for which natural language isn't a good fit due to inherent ambiguity). For products, simplicity and user utility is how I approach the problem when given wiggle room.

We are on HN, so there's bound to be many startup people that only need to bang out features to lure in users and then pass on that pile further onto someone else, when they cash out.

What I have seen however, are mid-managers+ that haven't coded in a decade or so, and now with LLMs they feel that they deliver equal quality results, whereas they have been so long out of the game and haven't picked up the modern skills on how to maintain and build applications.