[seamossfet]

The public doesn't care about the code itself, they absolutely care about the quality and experience of using the software.

But you can have an extremely well designed product that functions flawlessly from the perspective of the user, but under the hood it's all spaghetti code.

My point was that consuming software as a user of the product can be quite different from the experience of writing that software.

Facebook is a great example of this, there's some gnarly old spaghetti code under the hood just from the years of legacy code but those are largely invisible to the user and their experience of the product.

I'd just be careful to separate code elegance from product experience, since they are different. Related? Yeah, sure. But they're not the same thing.

[almostdeadguy]

I have yet to meet anyone whose problem with AI is that the code is not aesthetically pleasing, but that would actually be an indicator to me that people are using these things responsibly.

My own two cents: there's an inherent tension with assistants and agents as productivity tools. The more you "let them rip", the higher the potential productivity benefits. And the less you will understand the outputs, or even if they built the "correct thing", which in many cases is something you can only crystalize an understanding about by doing the thing.

So I'm happy for all the people who don't care about code quality in terms of its aesthetic properties who are really enjoying the AI-era, that's great. But if your workload is not shifting from write-heavy to read-heavy, you inevitably will be responsible for a major outage or quality issue. And moreso, anyone like this should ask why anyone should feel the need to employ you for your services in the future, since your job amounts to "telling the LLM what to do and accepting it's output uncritically".

[seamossfet]

>But if your workload is not shifting from write-heavy to read-heavy, you inevitably will be responsible for a major outage or quality issue.

I think that's actually a good way to look at it. I use AI to help produce code in my day to day, but I'm still taking quite a while to produce features and a lot of it is because of that. I'm spending most of my time reading code, adjusting specs, and general design work even if I'm not writing code myself.

There's no free lunch here, the workflow is just different.

[blackbear_]

There are other players in the game: the business and the market.

Good code makes it easier for the business to move fast and stay ahead of the competition while reducing expenses for doing so.

[WarmWash]

That's true, but excel '98 would still cover probably 80% of users use cases.

A lot, and I mean a lot, of software work is trying to justify existence by constantly playing and toying with a product that worked for for everyone in version 1.0, whether it be to justify a job or justify charging customers $$ per month to "keep current".

[packetlost]

That's fair!

> Facebook is a great example of this, there's some gnarly old spaghetti code under the hood just from the years of legacy code but those are largely invisible to the user and their experience of the product.

I'm sure that's the case in basically everything, it sorta doesn't matter (until it does) if it's cordoned off into a corner that doesn't change and nominally works from the outside perspective.

But those cases are usually isolated, if they aren't it usually quickly becomes noticeable to the user in one way or another, and I think that's where these new tools give the illusion of faster velocity.

If it's truly all spaghetti underneath, the ability to make changes nosedives.

[slopinthebag]

Facebook.com is a monstrosity though, and their mobile apps as well are slow and often broken. And the younger generations are using other networks, Facebook is in trouble.