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

431–440 of 512 posts

Re: Slop is not necessarily the future

#431

Post by Shorel »

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…

People do these kind of decisions every day, every second.

Shit bloated code is one of the reasons Epic Launcher is extremely behind in market share when compared to Steam.

Sure, they ship their product fast. They can iterate faster than Valve. They also add technical debt with each iteration.

Also: we are almost all using a Chrome derived browser instead of Firefox, old IE, old Opera, because of performance and quality. They just won the internet because of the quality of their code. Besides that, all browsers let you browse the internet.

When people can choose, they choose quality most of the time.

Re: Slop is not necessarily the future

#433

Post by mhitza »

tokioyoyo wrote: post #310
tabwidth wrote: post #288

Earlier quoted context omitted.

How long does that take though? Technical debt from sloppy code doesn't show up in the product until way later. By the time users notice, the team is already three features deep and can't back out.

All these arguments somehow disregards that we’ve all been adding technical debt left and right, every other day to every single codebase in existence. Humans also write sloppy code.

Same as when writing notes by hand, the information is internalized. When you pass the thinking to the LLM, you become the copilot that doesn't even know the code, and the minute decisions madd. Good luck rearchitecturing a bad decision in such a design, and prepare your double d6 for a full functionality reroll.

Re: Slop is not necessarily the future

#434

Post by pron »

zozbot234 wrote: post #428
pron wrote: post #319

Earlier quoted context omitted.

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

Agents just can't currently do that well. When you run into a problem when evolving the code to add a new feature or fix a bug, you need to decide whether the change belongs in the architecture or should be done locally. Agents are about as good as a random choice in picking the right answer, and there's typically only one right answer. They simply don't have the judgment. Sometimes you get the wrong choice in one session and the right choice in another.

But this happens at all levels because there are many more than just two abstraction levels. E.g. do I change a subroutine's signature or do I change the callsite? Agents get it wrong. A lot.

Another thing they just don't get (because they're so focused on task success) is that it's very often better to let things go wrong in a way that could inform changes rather than get things to "work" in a way that hides the problem. One of the reasons agent code needs to be reviewed even more carefully than human code is that they're really good at hiding issues with potentially catastrophic consequences.

Re: Slop is not necessarily the future

#435

Post by mememememememo »

sph wrote: post #223
mememememememo wrote: post #210

Earlier quoted context omitted.

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!

People use stupid metrics like those because more useful ones, like "productivity" or "robustness" are pretty much impossible to objectively measure.

And because the other easy one, revenue, is not so impressive.

Re: Slop is not necessarily the future

#436

Post by zozbot234 »

pron wrote: post #434
zozbot234 wrote: post #428

Earlier quoted context omitted.

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

Agents just can't currently do that well. When you run into a problem when evolving the code to add a new feature or fix a bug, you need to decide whether the change belongs in the architecture or should be done locally. Agents are about as good as a random choice in picking the right answer, and there's typically only one right answer. They simply don't have the judgment. Sometimes you get the wrong choice in one se…

> Agents are about as good as a random choice in picking the right answer, and there's typically only one right answer.

That's realistically because they aren't even trying to answer that question by thinking sensibly about the code. Working in a limited context with anything they do leaves them guessing and trying the first thing that might work. That's why they generally do a bit better when you explicitly ask them to reverse engineer/document a design of some existing codebase: that's a problem that at least involves an explicit requirement to comprehensively survey the code, figure out what part matters, etc. They can't be expected to do that as a default. It's not even a limitation of existing models, it's quite inherent to how they're architected.

Re: Slop is not necessarily the future

#437

Post by otabdeveloper4 »

hu3 wrote: post #414
otabdeveloper4 wrote: post #411

Earlier quoted context omitted.

Are you seriously claiming that technical debt doesn't exist?

I read it more like: Tech deb is over indexed by many and most money doesn't care as long as it works reasonably well.

It's called "debt" because you will be forced to pay it off eventually.

In other words, it "works reasonably well" until it doesn't. That point might break your business. Many such cases.

Re: Slop is not necessarily the future

#438

Post by raw_anon_1111 »

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…

This is provable false. First in B2B software the user is not the buyer. The reasons the buyer buys software is usually big because how well it performs but for a lot of other reasons.

Second, shitty electron apps are pervasive.

Re: Slop is not necessarily the future

#439

Post by alternatex »

jimbokun wrote: post #324
tokioyoyo wrote: post #307

Earlier quoted context omitted.

Have you seen large consumer products’ codebases?… Companies like Google are tiniest exceptions when it comes to code gatekeeping and quality.

Funny how the biggest, most profitable software companies emphasize code quality.

At Microsoft this totally depends on the org and team. I've seen the full spectrum of quality here.

Re: Slop is not necessarily the future

#440

Post by pron »

zozbot234 wrote: post #436
pron wrote: post #434

Earlier quoted context omitted.

Agents just can't currently do that well. When you run into a problem when evolving the code to add a new feature or fix a bug, you need to decide whether the change belongs in the architecture or should be done locally. Agents are about as good as a random choice in picking the right answer, and there's typically only one right answer. They simply don't have the judgment. Sometimes you get the wrong choice in one se…

> Agents are about as good as a random choice in picking the right answer, and there's typically only one right answer. That's realistically because they aren't even trying to answer that question by thinking sensibly about the code. Working in a limited context with anything they do leaves them guessing and trying the first thing that might work. That's why they generally do a bit better when you explicitly ask them…

Yes, and I think there's a fundamental problem here. The big reason the "AI thought leadership" claim that AI should do well at coding is because there are mechanical success metrics like tests. Except that's not true. The tests cover the behaviour, not the structure. It's like constructing a building where the only tests are whether floorplans match the design. It makes catastrophic strctural issues easy to hide. The building looks right, and it might even withstand some load, but later, when you want to make changes, you move a cupboard or a curtain rod only to have the structure collapse because that element ended up being load-bearing.

It's funny, but one of the lessons I've learnt working with agents is just how much design matters in software and isn't just a matter of craftsmenship pride. When you see the codebase implode after the tenth new feature and realise it has to be scrapped because neither human nor AI can salvage it, the importance of design becomes palpable. Before agents it was hard to see because few people write code like that (just as no one would think to make a curtain rod load-bearing when building a structure).

And let's not forget that the models hallucinate. Just now I was discussing architecture with Codex, and what it says sounds plausible, but it's wrong in subtle and important ways.

Post reply on HN