Hacker News Reader

Comment by gchamonlive | Hacker News Reader

If you took a bad but functional AI generated service and transported it back to 2018 it would have been at worst just mediocre. People do seem forget how dreadful devslop was in the past. I'd take an AI generated mess to disentangle every time over a spaghetti codebase that grew organically in the hands of careless managers.

View on HN

I don't like the idea of shaming people for making OSS vibe-coded tools for niche hobbies, so I don't want to name names, but there is ABSOLUTELY some stuff on Github now that can be used to get the job done but has UI/API/code performance, consistency, and quality issues, that would've been unfathomable for the average OSS project in 2018. Because it's the sort of stuff that only happens when there isn't a human in the loop to point out some very-obvious swings-and-misses. Like "you don't need a third button here doing the same thing as these other two" or "this button literally does nothing in 3/4 of the modes, but it's never shown as disabled" or "this takes 5 times longer than it needs to and blocks the main UI thread because work is all happening sequentially."

In the past it wasn't really common at all to add 10 features in an evening without actually trying to use those 10 features by hand yourself.

Personally I think it's wonderful that tools for these spaces exist when they didn't use to. But it's also ludicrous to say that anyone with Claude can replace even mediocre homemmade stuff in any dimension other than "being worth building even a bad tool" or "getting to semi-usable faster." Currently you still benefit massively from knowing what's going on behind the scenes, and from knowing "software engineering 201" type stuff around what sort of testing would be helpful where, vs accepting model-default-output everywhere.

> there is ABSOLUTELY some stuff on Github now that can be used to get the job done but has UI/API/code performance, consistency, and quality issues, that would've been unfathomable for the average OSS project in 2018

I will take time to address you comment fully, there are lots to unpack, but I'd like to stop here and point out that comparing "absolutely some stuff" from today to the "average 2018 project" might be unfair. If you are going to compare the bottom of the pile of synthetic code, you should do the same with organic code of back then lest you draw an unfair comparison.

> If you are going to compare the bottom of the pile of synthetic code, you should do the same with organic code of back then lest you draw an unfair comparison.

Make it the bottom 70% AI vs. the bottom 10% human if you want to. You're still going to be well within a sea of AI-slop because the volume is that large. The big thing about bad human code is that it tends to still be compact; I can read in some minutes the intention and what does(n't) work.

For each vibe-coded project I gotta do a tiny expedition just to get the basic idea of what's going on. let alone figuring out if things actually work as intended.

> The big thing about bad human code is that it tends to still be compact

I envy the environment you've worked before, because you definitely had a better experience than mine. My first job was working on a product -- not a prototype you see, an actual product with paying customers generating over 100k USD monthly for the company -- that was completely designed by interns from the ground up. Once we received a pull request on a part of the system that dealt with calculation reports that made snapshots of the relational db into MongoDB. This application was in PHP using an outdated CakePHP framework -- which was outdated for a good reason since it used to introduce breaking changes in minor releases (citation needed, but who's got the time these days...) -- and the merge request that once-employee left us to figure out how to merge was a single 400 lines function. You can extrapolate from it to infer the quality of the snapshots we were taking and you probably wouldn't land too far from the horrors we've seen.

So pardon me, but my experience shocks violently with your affirmation.I think you underestimate what the bottom 10% really is.

> People do seem forget how dreadful devslop was in the past.

It was dreadful, but the volume was a single-digit percentage of what you see now.

Even those develoeprs who made a living opying from SO *still needed to make that code work for their system!"

Volume has nothing to do with it, this is discussing code quality. But if you mind me saying so, blame this ridiculous amount of codeslop volume on greedy managers and corpocrats. Developers are artists, they usually ship shitcode when they're under pressure

> Developers are artists

I don't think this has ever, as a rule, been true.

Good to know your opinion my friend. I think they are, the incentives are for them to hide it and play the corporation ladder climbing game instead, if you think about it.

I certainly do believe that some developers are artists, see for example the IOCCC, and more who are or would like to be artisans, but by and large our colleagues' hearts are closed to the Muses.

Idk, I tend to look at this towards learned helplessness. There sure are the intelligent opportunists trying to ride the hype tides around tech, but we can't really say much when the environment don't foster creativity. How many brilliant devs are out there rotting away at meaningless jobs because they have debt?

volume has everything to do with this. We used to make fun of how overengineered projects can be with stuff like HelloWorld Enterprise Edition, and now we just shrug at that because it's made fast?

No it's because shrugging it off or not is the topic of another discussion. Code quality and noise ratio and absolute noise volume are completely orthogonal in a sense that you can discuss code quality separately to how you deal with a large volume of slop. This discussion is about the former and you are forcing it to be about the later, which is interesting but unrelated.

As far a I can tell, most didn’t bother to see if it worked for the system,p. They just needed to have it compile in their system and then they’d call it done.

If someone was a crappy developer it was also a coin flip if anything actually got shipped. AI will shove it out the door in whatever state it can.

That’s true. But there were also places with very high standards and good design. And the LLM slop is pushing in there as well.

Are the managers of these hypothetical places still interested in keeping the high standards and good design? Enshitification isn't inherent to the technology, if this is what you are deriving from the counterexample, it's a business strategy my dude.

It’s a combination of technical capabilities and human nature / incentives in big companies.

Concepts like good design, security, quality are abstract and hard to measure.

Time, cost, revenue etc are easy to measure. The “quality” people eventually get push aside by the money people.

This is not new, but LLMs further tilt the balance

> This is not new, but LLMs further tilt the balance

You speak as if llms had their own minds. Every time anyone talks about AI doing this or that they further reinforce this idea that there isn't a person behind all this. There's always someone watching.

With that said, when you say that llms tilt the balance, who specifically do you say that's driving llms to do that?

It means an ambitious manager can take on more work by having the team slop out. They move up (very effective leader!), standards fall, other managers have to match the changes. The bill comes due years later after they have moved on (and up).

And who pays that bill, actual or technical, is never who created them...

When someone says that something tips the balance of a situation, it is not ascribing a mind to that thing. For example, a bomb does not have a mind (nor does anyone think one does), but it is an undeniable fact that the atomic bomb tipped the balance of WW2. I think you are reading too much into the expression.

There's no anthropomorphizing warheads in nuclear warfare, so you can't really compare these two without the risk of ignoring the context and cultural relationship people have with these techs.

But as more and more things depend on increasingly deep software stacks, everything goes to utter shit if the individual systems don't become more reliable.

If you asked management they'd say that's "business risk"

That's a problem of customers stop paying for the product. If the don't then it's a philosophical discussion. I don't like the dilemma because I've been in a company that went bust from years of bungling it couldn't recover from and I wouldn't want to repeat the experience.

Reply on news.ycombinator.com