> whose labor does not produce >= $minimum_wage worth of value

Same thing we’ve been doing for other fields like software engineers - just pay them more.

I presume that was sarcasm, given how much trouble people are having finding software engineering jobs at the moment...

It’s not the ability to find jobs. It’s the ratio of pay to value delivered.

Nearly every app or website I use today is broken, slow or hostile to the user. Show me the value for the pay.

If bad software still generates revenue, that's the value. I'm speaking as someone who has used awful software that some ignorant boss bought for our organisation.

Abstractions are convenience. They’re not free, there is a cost to any work you ask the computer to do. Just staying at the surface level and never understanding what’s under the top level is why software is slow and bloated today. You’re supposed to move beyond the abstraction, understand what you need underneath and use what you really want to do the task.

No wonder we boot up entire browser engines to write simple text editors. But hey, we gotta be first to market to get that VC money, right?

I disagree.

Abstractions are not a convenience, they're a cognitive necessity, compressing large aspects of the problem space into easy to not think about blocks, allowing humans, with their limited working memory, to reason about larger problems. The only reason a seasoned developer can think at a high/system level is because of the abstractions/compressions they've formed in their heads.

Technology exists to make it so we don't have to think about/put time into low level things, so we can do more interesting things instead. Not thinking about banal things is the foundation of progress.

AI seems to be the give us an abstraction I've been waiting for: a method to write code at the level of libraries , with libraries working with/adapting to other libraries.

There are plenty of people who understand the stack and ship actually fast software. This might be a skill issue that you’re choosing to frame as a “best practice”, because you do not want to put in the work.

Our end users are who should benefit. You’re the pilot in the seat who doesn’t know what the throttle is and you’re telling the passenger it’s the plane’s fault it’s slow.

> that you’re choosing to frame as a “best practice”,

I don't follow.

> because you do not want to put in the work.

Yes, just as nobody wants to type opcodes, or write their own http clients, or etc. It's why most of us use higher level languages. Leave the solved things solved, and work on actually interesting/new things! That doesn't mean not understanding, it just means not wasting time on the same boilerplate/code duplicated by millions of developers.

If you think software performance is a solved problem today, there is nothing more I have to say.

Consumer software is slower than ever. And only getting worse.

Please reread this comment thread. I never spoke to software performance being solved.

> just as nobody wants to type opcodes, or write their own http clients

This is how you get faster software. You literally look “into” the code, see why stuff is slow, remove the extra work in the library that you do not need, and now your software has a faster server.

Abstractions make software “easy” to build. We’re not looking for done easily, we’re looking for done well.

No mention for them training on what we create (without our permission), just to sell it back to us?

Unless you’ve written one before, it’s the natural learning curve.

You can always generate one using LLM if you don’t care about how it actually works.

And if you have written one before, it might take five years. ;)

At least, that was my actual experience at a game studio. The engine team wanted to rewrite the engine but underestimated how much was there, how much was worth keeping, and how much work needed to be done. But that was a long time ago, and the studio’s now on Unreal.

> You can always generate one using LLM if you don’t care about how it actually works.

Lol, right. That might work for some of the runtime parts of a very simple engine, but not the other 90%, especially when you "don't care about how it actually works".

A game engine (like UE or Unity) easily exceeds the complexity of an entire desktop operating system (not necessarily in line count, but in number of features, their diversity and complexity).

I’m certain there’s enough actual game engine code in the datasets that with enough token spend, you could have a platform layer, basic renderer, entities moving around.

There would be absolutely no point in creating one over using one that exists and since there’s no learning that’ll come of it, it’s kinda wasting money.

Sure, but that part is only the "trivial 10%" of what's called a game engine these days. The actually important and much bigger part is the tooling.

Absolutely. tooling is very rest of the owl when it comes to building something rather than just working with debug data.

> Because these AI companies rent a lot of GPU to render the UI

What AI company is rendering websites for me on their GPUs?

> We’ll start seeing more optimized code.

No. We'll see more AI-generated code. AI-generated code is derived from human generated code. Most human generated code is slow (see: your own title).

So,apps like Lovable, V0 and similar tools use GPUs to render your UIs after generation. As for the second part, you said “no” most of these challenges can be easily tackled with prompting, fine tuning, code context, and a little human intervention. And the fact that in just five years of mainstream AI we have already reached the point where we can use LLM code generation for production apps is incredible. Just imagine what we will achieve in the next 5 to 10 years