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

481–490 of 512 posts

Re: Slop is not necessarily the future

#481

Post by raincole »

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…

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

The developers don't care that either. If developers cared the whole npm ecosystem wouldn't exist.

Re: Slop is not necessarily the future

#482

Post by 9rx »

bloppe wrote: post #60
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 mostly agree with this. Part of the confusion with the discourse around AI is the fact that "software engineering" can refer to tons of different things. A Next.js app is pretty different from a Kubernetes operator, which is pretty different from a compiler, etc. I've worked on a project that went over the complexity cliff before LLM coding even existed. It can get pretty hairy when you already have well-establishe…

> It can get pretty hairy when you already have well-established customers with long-term use-cases that absolutely cannot be broken

LLMs are often poor at writing tests that provide useful information to human readers and poor at writing tests that can survive project evolution. To be fair, humans are also poor at these tasks if done in hindsight, after all the information you normally want to capture in tests has been forgotten. That boat has been missed for the legacy code no matter how you slice it. But LLMs are quite good at writing tests that lock in existing functionality in the rawest way. It seems like LLM-generation is actually the best hope of saving such a project?

Re: Slop is not necessarily the future

#483

Post by cardanome »

advael wrote: post #379

At this point I can't help but conclude that to a certain class of writers, "economic incentives" are a form of benevolent god who will surely, inevitably make things better in directions they care about, and those who believe this also believe the overwhelming and constant evidence to the contrary of their position is just a temporary anomaly Whatever the hell economics was supposed to do, right now it seems to be c…

It also assumes free market competition which the AI space is already only in a very limited degree.

The whole business strategy for those companies is to be the one big monopolists that is left standing. That is why they are bleeding money offering token prices well beyond market rate so that they can grow.

Plus they can always lobby the state to ban foreign competition for security reasons.

Re: Slop is not necessarily the future

#485

Post by devin »

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 do both 1 and 2, because 1 is frequently served by some attention to 2 at times. This notion that it’s one or the other is unserious.

Re: Slop is not necessarily the future

#486

Post by deaux »

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.

Riot Games around 2014(?) had the most profitable (non-mobile?) game in the world with an infamously horrific codebase, even by game standards.

Re: Slop is not necessarily the future

#488

Post by deaux »

boplicity wrote: post #354
nocman wrote: post #84

Earlier quoted context omitted.

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

> There is no substitute for high quality work. That's where you get it wrong. The world is full of mediocre and low quality work in many, many fields. We all, in fact, depend on mediocre work in many ways. Many, many people would prefer a solution with mediocre or even bad code than no solution at all while they wait for "high quality work" that never appears. The magic of LLMs, especially as the technolgy improves,…

No, you see, this is impossible, as I've been taught here on HN by the wise elders over and over. As soon as a pristine codebase is tainted by even 1% of LLM-generated code, any chance at potential user value instantly disintegrates. Especially if it claims to do anything remotely novel!

But seriously, the denial is incredible to watch. Our product wouldn't exist without LLMs, and our users are vocally thankful that it does, saving them time and money and helping them reach their offline goals.

[0] https://news.ycombinator.com/item?id=47505428

[1] https://news.ycombinator.com/item?id=47476893

Among countless others

Re: Slop is not necessarily the future

#489

Post by tyingq »

kode-targz wrote: post #442
jimbokun wrote: post #322

Earlier quoted context omitted.

Now imagine how much they would make if their software was good. Google, Facebook, Apple clearly care deeply about the quality of their code. They have to because bugs, bad performance, outages, vulnerabilities have very direct and immediate costs for them. I know Amazon and Microsoft have their critics but I bet they are also better than we give them credit for. There are factors besides software quality that affect…

>Google, Facebook, Apple clearly care deeply about the quality of their code. Yea, idk about that one. They definitely did care in the past. They had to if they wanted to get users. But they've stopped caring a good while ago. Especially Microsoft. The costs that bad code would bring them is lower than the cost of developping good code, because they can mostly rely on monopolies and anti-competitive practices for use…

Is Google much better? I don't see, for example, the care that used to go into the quality of organic search results.

They seem fine with the output of the current hodge-podge of the original algorithm results plus massaging by many downstream ML pipelines that run one after the other without context of how each stop might affect the next.

Re: Slop is not necessarily the future

#490

Post by bitwize »

skydhash wrote: post #348
bitwize wrote: post #83

Earlier quoted context omitted.

It's called "systems analysis". Programmers are generally pretty terrible at it because it requires holistic, big-picture thinking. But it used to take up the bulk of the design activity for a new enterprise system.

And the result was usually a complex system that no one needed and could maintain. Successful refinement is needed when you try to accomplish something from the ground up, refining it as you're adding features. Not locking yourself in the ivory tower drawing UML diagrams and drafting requirements. Doing and thinking go in pair, not separately.

Research conducted by M. Bryce and Associates suggested that use of a structured systems analysis phase before programming began resulted in time and cost savings vs. just "hacking it together" like programmers want to do. Locking yourself in the ivory tower is an unfair way to characterize systems analysis. Systems analysts talk to people in the business to understand what the business requirements actually are, and then design an information system (NOTE: not a computer system or software system; if it cannot in principle be run on pen and paper it is not an information system) that meets those needs. Programmers only come in when the automatable parts of the system need to be implemented, and work from a detailed and precise spec.
Post reply on HN