Creating a high performance general purpose database is hard, but once it exists and is properly configured, the SQL queries are much easier. They'd better be or we wasted a lot of time building that database.
Yeah building a web app can become somewhat easy, but is distributed machine learning? What about low level kernel code?
Both are needed to do practical work, but they are orthogonal.
There is a nuance in what you say. You say it is "still easy" but it is not. It is not enough to take a course on operating systems and learn C to start contributing to the operating system kernel in impactful way. Apart from other software "courses" that you need to take such as algorithms, advanced data structures, concurrency, lock-free algorithms, probably compilers etc. the one which is really significant and is not purely software domain is the understanding of the hardware. And this is a big one.
You cannot write efficient algorithms if you don't know the intricacies of the hardware, and if you don't know how to make the best out of your compiler. This cannot be taught out of the context as you suggest so in reality all of these skills are actually interwhined and not quite orthogonal to each other.
If you take the skill tree you need to be a kernel contributor, it does not take much to jump over to database systems development, or writing GUI. You may argue that the barrier entry for web dev is lower, but that's because of all the foundational work that has been done to add guardrails. In kernel work, they are too expensive so there's no hand holding there. But in webdev, often enough, you'll have to go past the secure boundary of those guardrails and the same skill node like advanced data structures and concurrency will be helpful there.
Kernel dev is not some mythical land full of dragons. A lot of the required knowledge can be learned while working in another domain (or if you're curious enough).
It's difficult when you're first learning but there are definitely much harder skills to learn.
It's the easiest part because the hard parts of the job are everything else -- you're a knowledge worker so people look to you to make decisions and figure it out. You figure it out and make it work for whatever "it" happens to be.
If you thought coding was easy, wait till you see the competition for knowledge workers. You're in a spot now where the part that made you valuable (implementing business rules in software) can now be done by virtually anyone.
Doing all the non-coding parts (or, as you put it, "the hard parts") can now be done by almost any white collar worker.
"Knowledge worker" isn't a cutesy phrase, it means I don't get paid for my time, I get paid for what I know. Contrast that to, say, working retail where you are paid to staff the store from 8-6. It's not a value judgement (retail is hard work) it's a description.
We've already had years and years of predicting the death of software engineering to offshoring and that didn't happen for the same reason. India turns out plenty of fantastic engineers who can do my job. Those people also have better options than staffing some cut rate code factory, and you can't substitute the latter if you need the former. But nice try lol
What you appear to be missing is that (if AI coding is as good as we are told) there will considerably more people with the business knowledge to drive an AI to create their solutions.
The bit that made developers valuable was the ability to actually implement those business rules in software. You will be competing with all those laid off devs as well as those non-developers who have all that business knowledge.
In simple terms, there are two groups of people:
1. Developers, who have some business knowledge, and
2. White collar workers who have no development knowledge.
Previously (or currently, say) the supply of solutions providers came only from group 1. Now they come from both group 1 and group 2.
The supply of solutions providers just exploded, you can expect the same sort of salary that the people in group 2 get, which is nowhere close to what the people in group 1 used to get.
I'm not a code factory who occasionally talks to the suits. That isn't the job lol
The problem you are facing is that "person who talks to business" is a huge pool of talent, and now you have to compete with them. Previously your only competition was "person who talks to business and can code".
I do not get paid to write code. No software engineer does. The more senior the engineer, the less code they write.
I don't even really talk to the business folks, that's what a PM is for.
I already told you what I actually do, you're free to read it and learn. Or not, I ain't the boss of you
Nobody listens to someone who talks like this. Nobody learns from someone who talks like this. You're not a leader and you're not a very good software engineer and likely if you boss anyone around, they think you're a clown.
But the sad truth is that most software can be or it's done with shitty code that "kinda works" as long as the CPU it's fast enough.
But that doesn't mean there isn't some tricksy stuff. All the linear algebra in graphics programming takes awhile to wrap your head around. Actually, game programming in general i find a bit hard. Physics, state management, multi threading, networking...
Translating that into whatever language you chose is not that hard.
People love to lionize it, but honestly I can teach the basics of coding to anyone in a weekend. I love teaching people to code. It can be frustrating to learn but it's just not that difficult. I've mostly written Python and Ruby and Node for my career. They're not super hardcore languages lol.
What is hard is learning the engineering side. I don't get paid for the code I write, I get paid because I get handed a business wishlist and it's my job to figure out how to make that business reality and execute it, from start to finish.
I tell my boss what I'm going to be working on, not the other way around, and that's true pretty early in your career. At my current level of seniority, I can personally cost the company millions of dollars. That's not even a flex, most software engineers can do that. Learning to make good decisions like that takes a long time and a lot of experience, and that's just not something you can hand off.