There is an interesting pattern emerging in this thread. There are a lot of 'same here' and 'opposite for me' comments, but both sides are converging on the same point: people developing software to solve a problem.

Many who are considering a career shift away from software due to 'AI disgust' devoted their lives to developing software because they loved the craft. But with AI churning out cheap, ugly, but passable code, it's clear that businesses never appreciated the craft. I hope these folks find an area outside of SWE that they love just as much.

But once these folks find this area, it would be naive to think they won't use software to scratch their itch. In the same way that people who didn't pursue a career in SWE (because they felt under-qualified) are using AI to solve their problems, these folks will now find their own problems to solve with software, even if at first that is not their intention. They probably won't use AI to write the code, but ultimately, AI is forcing everyone to become a product manager.

Some are saying "finally, AI does all the busywork and we focus on the business domain"

But what if the business is soulless? As in what if the business you're working on is just milking value out of people through negative patterns which... is ... well a lot of tech businesses these days. Maybe the busywork enabled engineers to be distracted from the actual impact of their work which makes people demotivated.

Yeah, but I think there is a space in the market for people who don't want/know how to manage their own API keys. Anyway, IMO Tweeks is not for most of the HN audience [EDIT: because there are alternatives like Magix or even Greasemonkey itself].

I believe the best scenario is a language that gives an AI the best environment to train itself in a manner similar to the way a game like Go gave AlphaGo the opportunity to play innumerable times against itself and study the results.

I think the best programming languages of the future will come with their own LLMs, synthetically trained before release.

That's telling about CSS design. Folks here on HN are talking about how they purposely ask LLMs about APIs that don't exist, and they hallucinate with a better and more intuitive design that they would come up with on their own.

I don't know the best solution for the problem, but CSS is a very convoluted one.

It could also be that there is a dirth of high quality CSS training data in comparison to JavaScript et al.

I wouldn't be surprised if the negative developer sentiment toward CSS is reflected in training datasets.

My guess is it’s because CSS is so dependent on context. Especially layout styles only make sense for a specific structure of HTML elements, which might be stored in an entirely different file and directory.

Fun fact: In Portuguese, the em dash is often used to introduce direct discourse, much like double quotes are used in English, but only when the direct discourse opens the paragraph. So instead of:

"Hello," said John, "how are you today?"

You'd see:

— Hello — said John — how are you today?

Awesome idea! Just a thought, but a century version would be spot-on!

Thanks for the suggestion, will do! (I’ll also be open-sourcing it, as I probably should’ve done before posting)

How is the strategy for backups and redundancy in a setup like this?

I didn't talk about it in the article, but my strategy is:

1. Local time machine backup (for disk failure recovery)

2. All the Docker container mount in a particular directory, and I periodically sync that directory to an S3 bucket

3. Planning to have Backblaze for more disaster recovery

All of these would have downtime in the event of an issue, but that's ok with me.

People treat SPA and MPA as oposing teams, one is the right way and the other is garbage. But this is not how it must be seen.

What we have is the natural way to do things with web stack (the way it's is mean to be used), and the "hacky way" (the way that let us do what we want to do, even when the web stack doesn't support it yet).

SPA is the hacky way today, but before it we had CGI, Java applets, Flash... And the web purists were always very vocal against the hacky way.

But the hacky way is what pushs the envelope of what the natural way can do. Every feature cited in the article that makes an MPA competitive with an SPA today only exists because of SPAs.

I'm on the side of preferencially use the web the way it's meant to use whenever it's possible, but I love to see what can be done when we are a little hacky, and it's awesome to see the web stack adapting to do these things in a less hacky way.

i absolutely disagree that SPA should be considered hacky.

as i already wrote here:

https://news.ycombinator.com/item?id=42165046

i find SPAs a much cleaner way to write web applications.

In fact, the most valuable resource on the internet is finite: atention with the possibility of influence those who give it to you. This is already a question of national security.

Rust (the language) is rolling off the Volvo assembly (not the language) line