> It turns out, this is not the majority of software people are paying engineers to write.

The above are definitely the majority of software people are paying developers to write. By an order of magnitude.

The novel problems for customers who specifically care about code quality is probably under 1% of software written.

If you don't recognise this, you simple don't understand the industry you work in.

As it turns out - "just make this button green" - is not the majority of what people at FAANG are doing...

As it turns out - 4 years before LLMs - at least one of the FAANGs already had auto-complete so good it could do most of what LLMs can practically do in a gigantic context.

But, sure...

Less than 1% of software developers work at FAANG.

Contrary to popular opinion - the majority of engineers are not working at companies that have no revenue.

Anywhere the risk of something going wrong is high, a lot of what you're paying engineers for is to minimize that risk while getting shit done - not to "just do the thing" you might think you're paying for.

Wherever "this sort of works" is good enough, LLMs will excel. Wherever it doesn't, you'll still be paying a lot of money for humans.

Mostly because non-engineers cannot define what "working" is most of the time it's important.

You don't go to a surgeon and tell him to replace your heart in some way. You go to a surgeon to "fix" your heart. You wouldn't even know what that meant. No amount of WebMD LLM summarization is going to help the average person.

Almost 20 years ago, IBM was famous for the average engineer writing ONE line of code per day...

It's not like IBM was paying people to do nothing, contrary to what most people thought who worked there for 15 years.

It's almost as if lines of code don't have value and a working product and the ability to change it reliably does.

>at least one of the FAANGs already had auto-complete so good it could do most of what LLMs can practically do

Could you clarify what you're referring to? I'm interested.

Everyone has its own set of novel problems. And they use libraries and framework for things that are outside it. The average SaaS provider will not write its own OS, database, network protocols,... But it will have its own features and while it may be similar to others, they're evolving in different environments and encounter different issues that need different solutions.

Non-novel problem != non-novel solution

Most problems are mostly non-novel but with a few added constraints, the combination of which can require a novel solution.

Those are exactly the types of problems that LLMs excel at solving.

Actually the surgeon analogy is really good. Saying AI will replace programming is like saying an electric saw will replace surgeons because the hospital director can use it to cut into flesh.

It's so much faster too! How many meters of flesh have you cut this month, and how are you working toward increasing that number?

While I find your frequent use of 'it turns out' to remind me of https://jsomers.net/blog/it-turns-out .. I do think there may be supportive logic to be had. A lot of software previously wasn't simply hand done, it was done along with implementing libraries of code or using snippet libraries. So, software engineers had already abstracted away coding a lot of the reusable parts between projects they will be now in-house developing with AI.

If so, it might be true that in many cases writing code wasn't as big of the story as some people think for some other people in the industry. I imagine there were many people though who toiled by hand a lot of code they didn't need to before for lack of experience or awareness, and so for them this a big increase in speed.